Firewall Wizards mailing list archives
Re: Here is my plan for firewall implementation
From: "Marcus J. Ranum" <mjr () nfr net>
Date: Sun, 21 Sep 1997 18:11:09 +0000
The SMAP gateway is nice, but keep an eye on it. I have in the past had it go into a runaway loop and fill up some partitions with log messages and bounced mail. I do not know i the curent version fixed the problem which was related to a message not being requeued, or discarded after sendmail failed to send it.
These days I'd use qmail (Dan Bernstein's minimalist mailer) or sendmail running on a hacked kernel in a restricted environment. Smap was intended to be a place for hooking additional mail processing into a firewall, but nothing ever got hung on the hooks. By sendmail on a hacked kernel I'm talking about things like running sendmail chrooted w/o privs and a configuration that doesn't have sendmail calling external mailers. Then all it has to do is fork itself off - at that point you can jigger the kernel to allow a specific UID (under which mail runs) to chroot, but you check so a chroot cannot be performed twice.* Also, wire the kernel so that the mail UID cannot call any of the exec( ) family. 99% of sendmail's problems are because it tries to do much much more than just haul mail. .forward files and all that junk are the real reason it runs with too many privs. Easy enough to fix that. :) Another fun fix I'd like to see on firewall boxes (but this takes more kernel expertise than I have) is modifications to the memory management to make stack space protected so it's not executable. When someone tries to hit a buffer overrun, *poof* instant SIGSEGV. All these should be useful ideas to those of you who are my ex-competitors and ex-employers who want to build state of the art firewalls. :) mjr. (* add the following to vfs_syscalls.c in the chroot system call source: if (fdp->fd_rdir != NULL) { log(LOG_ERR,"WARNING! chroot when already chrooted!"); /* return EPERM or whatever */ } ) ----- Marcus J. Ranum, CEO, Network Flight Recorder, Inc. <A HREF=http://www.clark.net/pub/mjr>Personal</A> <A HREF=http://www.nfr.net>Work</A> <A HREF=http://www.clark.net/pub/mjr/websec>New Book!!</A>
Current thread:
- Here is my plan for firewall implementation Jim Raykowski (Sep 21)
- Re: Here is my plan for firewall implementation Marcus J. Ranum (Sep 21)
- Re: Here is my plan for firewall implementation Jyri Kaljundi (Sep 21)
- Re: Here is my plan for firewall implementation Bennett Todd (Sep 22)
- Re: Here is my plan for firewall implementation Jyri Kaljundi (Sep 21)
- Re: Here is my plan for firewall implementation Craig Brozefsky (Sep 21)
- Re: Here is my plan for firewall implementation Marcus J. Ranum (Sep 21)
- Re: Here is my plan for firewall implementation Craig Brozefsky (Sep 22)
- NCSA's RECON Service Adept (Sep 22)
- Re: Here is my plan for firewall implementation Joseph S. D. Yao (Sep 22)
- Re: Here is my plan for firewall implementation Adam Shostack (Sep 22)
- Re: Here is my plan for firewall implementation Paul D. Robertson (Sep 23)
- Re: Here is my plan for firewall implementation Alfred Huger (Sep 24)
- Re: Here is my plan for firewall implementation Marcus J. Ranum (Sep 21)
- Re: Here is my plan for firewall implementation Marcus J. Ranum (Sep 21)
- <Possible follow-ups>
- Re: Here is my plan for firewall implementation See, Matthew (Sep 22)
- Re: Here is my plan for firewall implementation Peter Jeremy (Sep 22)
- RE: Here is my plan for firewall implementation Tong, Aaron (Sep 23)
- RE: Here is my plan for firewall implementation Jim Raykowski (Sep 26)