Firewall Wizards mailing list archives
Re: A fun smackdown...
From: "Paul D. Robertson" <paul () compuwar net>
Date: Thu, 19 May 2005 15:11:20 -0400 (EDT)
On Thu, 19 May 2005, Chuck Swiger wrote:
On May 19, 2005, at 9:04 AM, Paul D. Robertson wrote:On Tue, 17 May 2005, Martin wrote:"Be liberal in what you accept; be strict in what you send."_All_ effective security controls break that tenet. The more liberal your controls, the more risk you assume.There is more to an effective security control than only denying stuff!
No, there isn't in terms of the mitigation of risk. Anything else isn't about the security properties of the control, but about its operational effectiveness. _What_ you deny, _how_ well it's implemented, and where you deny it is in fact the essence of security. From guards with guns to firewalls to anti-virus, default deny or default except- either one works by blocking stuff (what you know is bad, or what you don't know is acceptable.)
I think you're over-valuing the utility of "deep protocol inspection",
Um, what the heck does "deep protocol inspection" have to do with the fact that security controls are a denial technology? Where exactly did I say anything about deep protocol inspection?
Paul, and you seem to be ignoring the risks of denying legitimate connections which should have been permitted.
No, again- Security works by denying things. That's got nothing to do with falsely denying things, and everything to do with accepting risk. If I deny everything, my risk is lower than if I deny 90% of everything- but in either case, the security factor is about denying.
An effective security measure needs to implement the security policy. It needs to permit the types of access that legitimate users are allowed to have, for the system-- meaning the network, the firewall, and the server(s) or other equipment being used-- to work correctly.
That doesn't change the fact that it all works by denying things, not by liberally accepting just anything that might come over the wire.
This is just as important as denying access to stuff that is not permitted by the security policy.
That's not a security property though, it's an operational property. Now, you can argue that denying too much impacts business, and I'd agree, because it doesn't conflict with what I said- 1. Security things work by blocking stuff. 2. The less stuff you block, the more risk you assume. That's because once you're done getting rid of the "bad" stuff (or the "not good" stuff) you're simply left with bad actors doing permitted stuff, no matter if it's your browser, a rogue administrator, or some bad guy come to crack the nuclear launch codes[sic].
Has "fixup protocol smtp 25" actually done much to prevent a vulnerable M$ Exchange box from being owned, or helped control the flow of spammy/virusized traffic significantly? Does it help control outbound
I don't know what it does, since I don't field PIXes and have only worked on two in my entire life; but I _assume_ that it will block the Microsoft-only SMTP extension that popped up a couple of months ago as a vulnerability. Now, *if* it does, it *breaks* something that Microsoft Exchange Server does when talking- see- that's the point, protection comes at the cost of breaking functionality once you get to the point where you've knocked out the out-of-band stuff and you're just left with the in-band attacks.
malicious SMTP traffic? Has it ever happened that a firewall itself ends up with buffer overflow bugs in it's own code, trying to implement all the per-protocol stuff?
Again, my observation isn't about *how* things are blocked, implementations of blocking, or at what level things are blocked, it's simply that security flies in the face of liberal acceptance.
If you want to manage SMTP securely, blocking port 25 in both directions while permitting only your MX box(es) through would do a heck of a lot more good than the protocol inspection does.
At which point you're left shoring up against in-band attacks- that's the only risk left for that vector! But again, nowhere did I mention a particular method of blocking those attacks, just that the more you block[1] the less risk you assume. Paul [1] This of course assumes you don't introduce more problems, as complexity also increases risk. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions paul () compuwar net which may have no basis whatsoever in fact." _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- A fun smackdown... Marcus J. Ranum (May 13)
- Re: A fun smackdown... Joseph S D Yao (May 15)
- Re: A fun smackdown... Martin (May 17)
- Re: A fun smackdown... Paul D. Robertson (May 19)
- RE: A fun smackdown... Ben Nagy (May 19)
- Re: A fun smackdown... Chuck Swiger (May 19)
- Re: A fun smackdown... Paul D. Robertson (May 19)
- Re: A fun smackdown... Chuck Swiger (May 19)
- Re: A fun smackdown... Paul D. Robertson (May 19)
- Re: A fun smackdown... Devdas Bhagat (May 19)
- Re: A fun smackdown... Paul D. Robertson (May 19)
- Re: A fun smackdown... Marcus J. Ranum (May 20)
- Re: A fun smackdown... Chuck Swiger (May 21)
- Re: A fun smackdown... Marcus J. Ranum (May 21)
- Re: A fun smackdown... Chuck Swiger (May 21)
- Re: A fun smackdown... Marcus J. Ranum (May 21)
- Re: A fun smackdown... Chuck Swiger (May 21)
- Re: A fun smackdown... Martin (May 17)
- Re: A fun smackdown... Joseph S D Yao (May 15)