You need to poke into places where only root can go now, when doing a security audit of a Unix system. Root is the worst choice in the world for security auditing. Unix needs a special user who can visit any file that root can, but whose ability to change things is sharply restricted.
The root cause is simple. Unix' basic design dates from a time when nobody, but nobody, thought of security as a real issue.
OMFG, this is sooooo important. Infosec is my bread and butter, and has been for about six years, now. You simply would not believe the shannigans you can catch wise to if you monitor your system, A/V, and firewalls on a daily basis.
Things like fast-spreading infectors that got past your A/V proxies because they got to them before the vendor's new pattern file did.
Attempts by employees to download things like Back Orifice for use as revenge tools.
Engineering failures.
Misconfigurations.
Vendor screwups.
Stealthy host sweeps that dribble one TCP/21 packet every 75 minutes into your Internet-facing DMZ. No, that last one totally blew by our worthless network IDS; we ended up blackholing the IP at the border router. No choice, our DMZ ftp server used wu-ftpd.
Porn download attempts.
Boxes in your trusted network infected by viruses.
I spent twenty months doing log monitoring. I caught all these event types and more. There is a whole wide, wacky wonderful World Of Hurt out there that you can duck or mitigate if you just monitor your logfiles. And most shops never really do.
"Building Linux and Openbsd Firewalls", by Wes Sonnenreich and Tom Yates. Published in February, 2000. Dated, both Linux and OpenBSD have gone through too many changes for this to be an "in the trenches" reference. It's a decent view from 30,000 feet.
"Absolute OpenBSD", by Michael Lucas. Published in June, 2003. Its ISBN is 1886411999. Covers OpenBSD 3.2, so it's relevance to 3.4 is high. Has a few typos which do not seriously mar the content.
As any decent book on OpenBSD should do, it walks you through an install. The coverage of pf is more than sufficient for most firewall applications. The appendices, with their exhaustive exploration of OpenBSD's maker-specific device prefixes, will save you a great deal of headache.
"Building Firewalls with OpenBSD and PF, 2"nd edition", by Jacek Artymiak. Published in November, 2003. Its ISBN is 8391665119. Covers OpenBSD 3.4, so it's essentially hot off the press. This will answer just about any technical question about PF that you care to ask. A must-read, if you want to get the most out of PF.
"But how do I _harden_an OpenBSD firewall?", I hear you cry. A good place to start looking for the answer to that question is at http://geodsoft.com/howto/harden/
Slashdot Mirror
Heh. Rat out a spammer. Get a free and legitimate copy of Windows.
:)
I call that one a win-win scenario.
Except for the spammer who got sold down the river. My piles bleed for that last.
Somebody at MS got really really smart this time.
You need to poke into places where only root can go now, when doing a security audit of a Unix system. Root is the worst choice in the world for security auditing. Unix needs a special user who can visit any file that root can, but whose ability to change things is sharply restricted. The root cause is simple. Unix' basic design dates from a time when nobody, but nobody, thought of security as a real issue.
Things like fast-spreading infectors that got past your A/V proxies because they got to them before the vendor's new pattern file did.
Attempts by employees to download things like Back Orifice for use as revenge tools.
Engineering failures.
Misconfigurations.
Vendor screwups.
Stealthy host sweeps that dribble one TCP/21 packet every 75 minutes into your Internet-facing DMZ. No, that last one totally blew by our worthless network IDS; we ended up blackholing the IP at the border router. No choice, our DMZ ftp server used wu-ftpd.
Porn download attempts.
Boxes in your trusted network infected by viruses.
I spent twenty months doing log monitoring. I caught all these event types and more. There is a whole wide, wacky wonderful World Of Hurt out there that you can duck or mitigate if you just monitor your logfiles. And most shops never really do.
Heh.
:)
I'll give you three. And a website to cap them.
"Building Linux and Openbsd Firewalls", by Wes Sonnenreich and Tom Yates. Published in February, 2000. Dated, both Linux and OpenBSD have gone through too many changes for this to be an "in the trenches" reference. It's a decent view from 30,000 feet.
"Absolute OpenBSD", by Michael Lucas. Published in June, 2003. Its ISBN is 1886411999. Covers OpenBSD 3.2, so it's relevance to 3.4 is high. Has a few typos which do not seriously mar the content.
As any decent book on OpenBSD should do, it walks you through an install. The coverage of pf is more than sufficient for most firewall applications. The appendices, with their exhaustive exploration of OpenBSD's maker-specific device prefixes, will save you a great deal of headache.
"Building Firewalls with OpenBSD and PF, 2"nd edition", by Jacek Artymiak. Published in November, 2003. Its ISBN is 8391665119. Covers OpenBSD 3.4, so it's essentially hot off the press. This will answer just about any technical question about PF that you care to ask. A must-read, if you want to get the most out of PF.
"But how do I _harden_an OpenBSD firewall?", I hear you cry. A good place to start looking for the answer to that question is at http://geodsoft.com/howto/harden/