Re: [fw-wiz] SANS Top Ten and Commercial Firewalls

From: Devdas Bhagat (dvb@users.sourceforge.net)
Date: 10/04/02 

From: Devdas Bhagat <dvb@users.sourceforge.net>
To: firewall-wizards@honor.icsalabs.com
Date: Fri Oct  4 12:10:16 2002

On 04/10/02 10:21 -0400, Paul D. Robertson wrote:
> On Fri, 4 Oct 2002, Devdas Bhagat wrote:
>
> > > (A) Project history- Postfix and Qmail have held up well, proftpd erm,
> > > hasn't. I haven't followed the other two, since FTP is on my list of "Horribly
> > > broken protocols I'll never support."
> > I'll agree wuith this. Proftpd has not had a showstopping bug except for
> > a DOS due to globbing (IIRC). There have been minor bugs, but none of
>
> Just after Flood dropped the project I seem to recall a spate of exploits,
> one after another[1]. Looking back, I count 3 definite root exploits, a
> couple of other issues that'd make me not want to put it in a hostile
> environment.
Aaah, I picked it up after the bugs were fixed. Not before that.
Wasn't required to (senior people were happy wuith wu-ftpd).

> Personally, I'd have looked at one I hadn't run before, or the BSD one,
> which has only had a couple of issues in the last few years, and I don't
> think any of them were unique to that instance.
I had very little experience then. Have a little bit more now.
 
> > them were the security kind.
> > I haven't runa ftpd for quite some time, and when I was looking (about
> > Nov/Dec 2000), proftpd was the best choice due to its easy config and
> > relative security. Current status is a wholly differnt issue.
>
> Personally, I'd look elsewhere given the history (and that's not saying it
> hasn't been fixed, it's saying I don't trust the original goal of security
> in the design given it's lack of compliance with that goal.) I'll give
> you "easy to config," bedause it met that goal quite well, but in Nov of
> 2000, it was just done with a raft of expliots, bugs and a change of
> maintainership- none of them particularly confidence insprining in my
> opinion.
Didn't know that at that time. I'll admit to being guilty on that count.
 
> > > (B) Look at the code.
> > This always works, but its a question of time on the security people's
> > part.
>
> Yes, but if you never do it, you'll never get time budgeted for it. I
> used to do per-protocol risk assessments for weeks before allowing or
> disallowing anything new- sometimes it wasn't overly necessary, it was
> *obvious* that the answer was going to be no, but doing some of those
> anyway got the organization in tune with "new stuff takes weeks of
> examination."
Not in todays world in a whole lot of places. Seems like marketing
drives the whole system. Sad but true.
 
> > > > (C) Developer history.
> > Good stance to go by for first filtering.
>
> People used to grep for "Vixie" to find exploits. Sad, but true.
I know. I saw a few posts somewhere for Bind 9's security saying that.

> > > (D) Developer's understanding of the protocol and its weaknesses.
> > Difficult to judge rapidly. Since the weaknesses are usually at the
> > boundaries. Also, the developers understanding of the language used.
>
> In that case use it in reverse, add points to those who can and do
> articulate it well.
You need to know what the developer says/does. Ahem.... DJB.

[OT] Can we please follow the LKML rule that if there is no specific
request for an offlist reply, then the reply should go only to the list?
I am on the list.

Devdas Bhagat.

Relevant Pages