Firewall Wizards mailing list archives
Re: Securing a Linux Firewall
From: "Kyle R. Hofmann" <krh () lemniscate net>
Date: Wed, 24 Jul 2002 15:35:56 -0700
On Wed, 24 Jul 2002 00:13:52 -0400, Carson Gaspar wrote:
On Tuesday, July 23, 2002 4:01 PM -0600 John McDermott <jjm () jkintl com> wrote:This, I believe, presumes that you are *100% sure* that the given binary can grant no additional privs. I am seldom that sure about software.If it is not setuid, and not setgid, it _can't_ grant you extra privs (ignoring funky capability ACLs and the like).
This is not true. You assume that the attacker has already achieved shell access or something equivalent. This is not necessarily true. Suppose that your firewall has the option to run an outside program on a fixed event (e.g., it could run a program to page you if you get portscanned). Forget, for a moment, the fact that you personally may not want this feature (or misfeature), and assume that you must live with it. In the best case, there will be no problems--the firewall and the outside program will both be bugfree. There is also the possibility, however, that the firewall will not be bugfree, and the attacker will be able to execute an arbitrary program of his choosing. He may choose to execute /bin/sh, for example. He cannot execute it, however, if it's not there. So maybe instead he'll try to execute /bin/bash or /bin/ksh or /bin/csh or something like that. But if they're not there, either, he has to execute commands one at a time, and if the firewall crashes because he's, say, smashed the stack, then he only gets one command per restart of the firewall. Now, if you have enough programs on the firewall and he has enough chances, he may still be able to find a way in. He may try to get the output of "ls -laR /" and then search through it for shells or other useful programs that he can run when the firewall is rebooted. But if they aren't there, he can't use them. He may still be able to disable your firewall and get broader access, but he won't be able to use the firewall as a DDoS zombie or an IRC client. I admit that these circumstances won't always apply, and that in the usual case, having additional binaries on the system won't help or hurt your security. But you should already be protected from the usual case; it's the unusual cases that you need extra layer of paranoia for. -- Kyle R. Hofmann <krh () lemniscate net> _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- RE: Securing a Linux Firewall, (continued)
- RE: Securing a Linux Firewall Carson Gaspar (Jul 23)
- RE: Securing a Linux Firewall Paul Robertson (Jul 23)
- Re: Securing a Linux Firewall Brian Hatch (Jul 23)
- Re: Securing a Linux Firewall John McDermott (Jul 23)
- Re: Securing a Linux Firewall Marcus J. Ranum (Jul 23)
- Re: Securing a Linux Firewall Marcus J. Ranum (Jul 23)
- RE: Securing a Linux Firewall Carson Gaspar (Jul 23)
- Re: Securing a Linux Firewall Brian Hatch (Jul 23)
- Re: Securing a Linux Firewall Carson Gaspar (Jul 24)
- Re: Securing a Linux Firewall BORBELY Zoltan (Jul 24)
- RE: Securing a Linux Firewall Bill Royds (Jul 24)
- Re: Securing a Linux Firewall Kyle R. Hofmann (Jul 24)
- Re: Securing a Linux Firewall Stephen P. Berry (Jul 26)
- Re: Securing a Linux Firewall R. DuFresne (Jul 26)
- Re: Securing a Linux Firewall Gwendolynn ferch Elydyr (Jul 24)
- Re: Securing a Linux Firewall Stephen P. Berry (Jul 25)
- Re: Securing a Linux Firewall Gwendolynn ferch Elydyr (Jul 25)
- RE: Securing a Linux Firewall David Lang (Jul 24)
