"Clear and present danger" is most emphatically NOT a recognized exception to free speech. Schenck was overturned in Brandenburg v. Ohio. The standard is "imminent lawless action." Speech is not protected by the First Amendment if the speaker intends to incite a violation of the law that is both imminent and likely. This was further clarified in Hess v. Indiana, which found that Hess's words did not fall outside the limits of protected speech, in part, because his speech "amounted to nothing more than advocacy of illegal action at some indefinite future time."
Since enabling a non-violent rejection of someone else's point of view is the entire point of both free speech and freedom of religion. Seriously, what do you think free speech/religion/press/assembly is for if not expressing viewpoints that someone else finds grossly offensive?
So is anyone planning to park outside of the church and hold a "Bible Barbecue," cooking burgers on grills in the back of pickups replacing the charcoal with, well...
If you can explain to me how burning someone else's holy book qualifies as satire or parody then I'll accept the equivalence with Westergaard's case.
This situation is closer to a company like Rackspace choosing not to host the KKK's web site. Doesn't exactly make Rackspace a paragon of free speech, but there no shortage of service providers out there who are willing to host the site... most at a premium that covers the inevitable hack attacks.
Which things shall I avoid paying for? Shall I avoid paying for education so I have to deal with even more ignorance in my daily life? Shall I avoid paying for environmental protection and enjoy the poisons in the air I breath and water I drink? Shall I pay a toll every time I turn a corner, coordinated by a ticketmaster-like company that takes a huge chunk since even that's preferable to constantly stopping at a booth? Perhaps I should avoid paying for social security so that anyone who gets wiped out in the stock market can just hit the streets and die when they get old. Including me if I should pick the wrong stock. And who needs medicare? Surely I'll be better off living in a society with massive pockets of infestation just waiting to jump the fence and sicken me.
As it happens, I'm a proponent of small government and local government. I think we'd be better off if the federal government shrank to a quarter of it's current consumption and I think we'd be better off if state, county and city governments picked up no more than half of that shrinkage. But your Anarchist screed is a tired, disproven theory. While it's true that everything government does it does badly, most of what government does benefits you by improving the lot of everyone in the society of which you're a part, and most of it has been shown not to function consistently without government involvement.
the issue of why are we even taxed never gets brought up.
Why would it? Is there any taxpayer out there who doesn't understand why he's expected to pay taxes?
I don't want you walking naked down my street and TPing my trees. And I definitely don't want you waving a gun at me when I object. Not even that little member you call a "gun." Preventing you from doing so consumes a certain amount of resources and manpower... efforts which my taxes support with my gratitude.
It makes sense for a bootloader to place data and code outside of partitioned space. It makes more sense to place the code inside a partition, even if it's a one-track partition dedicated to the bootloader. If they collided with components of Windows' bootloader or FreeBSD's bootloader, or some pre-boot hard disk encryption software I'd have little sympathy for them.
On the other hand, user-level apps storing data on the hard disk outside of partitioned space is very bad mojo. They should not be doing that. Ever. Period.
You're welcome to think you're a clever network security guy and I'm sure you will, but until you account for the role mistakes play in your security process and mitigate them with additional depth your effectiveness won't grow beyond mediocre.
So if you compromise a box on the same LAN as the NAT's external interface AND an allow-all rule is fat-fingered into the NAT box then you can rig the compromised box to interact with the IP addresses inside the firewall and the misconfigured NAT firewall will happily route your packets. I concur; this is an accurate description of one way to circumvent a NAT after a mistake in the firewall configuration.
So, you make a mistake in the firewall rules and you also make a mistake on a DMZ host that let's someone hack in. Wait a minute, that's TWO breaches needed to get through that NAT and poke at the hosts behind it, not the ONE breach needed to get through the merely stateful firewall.
Nice try but no points. NAT isn't invulnerable. Neither is the merely stateful firewall. But the merely stateful firewall is breached from the outside in with just one mistake in the configuration. NAT has an additional layer of depth to its security. Got anything up your sleeve that gets you through the NAT box to a host you didn't intend to expose with only the one easily-made mistake with the firewall rules?
Problem with that example is - the source route option is disabled by default in essentially everything these days. More importantly: unlike an expansive allow, enabling source routing isn't in the typical mistake path. And even if you intentionally enabled it, someone would still have to guess or scan through a substantial amount of address space to even find your internal address since your internal address is not routinely revealed by your externally available traffic.
I'll give you credit for a solid try. Want to take another shot at it, with functionality you would reasonably expect to exist and be enabled on the firewall after mistakenly entering an allow-all rule?
Got an example of such a magic packet? 'Cause I think you're full of crap but I'm ready to change that opinion in the face of evidence or well supported analysis.
You never inserted a forward everything to your laptop rule in your NAT config?
No, I haven't. It's never on by default and doesn't find its target dynamically, so in order to make that mistake I first have to deliberately configure -something- to forward from outside to a particular inside address. And that forwarding is in a completely different part of the configuration than the regular security rules where there's essentially no chance of a mistake editing the normal rules causing it.
What's more, the scope of the consequences is that exactly one (1) host is exposed, not all of the hosts protected by the firewall.
What all this adds up to is that an error in configuring or programming a NAT firewall is far more likely to incorrectly restrict access than incorrectly allow access. Incorrectly expanding access from the outside is probably less than 1% of the mistakes. Meanwhile an error in configuring or programming a merely stateful firewall has about a 50/50 chance of incorrectly restricting access and a 50/50 chance of granting incorrectly broad access.
Another way to look at this is: how many distinct barriers have to be bypassed in order to breach the system's security.
With a stateful firewall you have to get past two security functions: the stateful connection manager that doesn't want to allow packets that aren't part of an established and authorized connection, and the host's security on the application ports it listens to.
With a NAT firewall, you have to get past three: the stateful connection manager, the translation matrix that lets the NAT firewall figure out where to send incoming packets to and the host's security.
Thus the NAT firewall has a greater depth of security than the merely stateful firewall. Everything else being equal, a system with a greater depth of security will tend to be better secured.
And in those situations where a temporary service disruption is more of a problem than the rare loss of security, NAT is the wrong tool whether we're talking about IPv4 -or- IPv6. For situations where NAT *is* the right tool, it isn't available yet in IPv6, and that's a problem.
Default policy doesn't matter. If you want to evaluate the efficacy of a security process, you figure out what kind of mistakes can be made and then you evaluate the result of each mistake to see if it leads to a breach.
One obvious mistake you can make when programming a firewall is entering a rule whose practical effect is "allow all." With a generic firewall the consequence of that mistake is total access. With a NAT firewall with a single IP address, the consequence is nil: although the firewall happily accepts the packet, it has no idea which internal host to send it to. Or at worst, there's a single internal host that it decides to send it to; the failure doesn't expose all of them.
As for most breaches coming from the browser/mail/other application, it didn't used to be that way. What do you think changed? That's right: wide deployment of NAT firewalls in "wireless routers" and "DSL routers" reduced the effectiveness of network-based attacks to the point where attacking the client apps indirectly was more fruitful. If we undo that with IPv6, we'll see network-based attacks rise again.
Perhaps I intercommunicated. See, I was talking about modern NAT in which there's exactly one external IP, not RFC 1631 remembered by few and used to next to none. Anything that NATs "blocks of IPs" on a 1 to 1 basis is out of scope and, of course, can suffer from fails-open.
Lets use the right tools for the right job, and lets use them properly
Right tool for the right job. I agree completely. And when securing eyeball networks to a level that doesn't justify elaborate amounts of process such as "peer reviewed change control," NAT is frequently a superb tool.
I was being sarcastic. I know the IPv6 NAT isn't in Linux yet. That was my point. IPv6 will be more deployable once NAT is not only possible at the technical level but also available in the products I routinely use.
And when you accidentally insert an allow any-any in front of the deny? That's what "fail" means. Yours fails -open-.
That same mistake in an address-overloaded NAT firewall has no impact. Interior hosts remain inaccessible from the outside despite the mistake because even with permission to move packets inside, the firewall has no idea where to send them. That's what it means to "fail closed."
Of course, you've never made a firewall configuration mistake that allowed more through the firewall than you intended and you never will, right?
Or if you fat-finger the allow 80 to allow all machines port 80. Or whatever. The point is, each mistake is as likely to create more access as it is to create less. While with nat, mistakes are very unlikely to create unintentionally broad access. It fails closed.
Slashdot Mirror
A tolerant society deals with intolerance by "farting in their general direction."
"Clear and present danger" is most emphatically NOT a recognized exception to free speech. Schenck was overturned in Brandenburg v. Ohio. The standard is "imminent lawless action." Speech is not protected by the First Amendment if the speaker intends to incite a violation of the law that is both imminent and likely. This was further clarified in Hess v. Indiana, which found that Hess's words did not fall outside the limits of protected speech, in part, because his speech "amounted to nothing more than advocacy of illegal action at some indefinite future time."
http://en.wikipedia.org/wiki/Imminent_lawless_action
Since enabling a non-violent rejection of someone else's point of view is the entire point of both free speech and freedom of religion. Seriously, what do you think free speech/religion/press/assembly is for if not expressing viewpoints that someone else finds grossly offensive?
So is anyone planning to park outside of the church and hold a "Bible Barbecue," cooking burgers on grills in the back of pickups replacing the charcoal with, well...
If you can explain to me how burning someone else's holy book qualifies as satire or parody then I'll accept the equivalence with Westergaard's case.
This situation is closer to a company like Rackspace choosing not to host the KKK's web site. Doesn't exactly make Rackspace a paragon of free speech, but there no shortage of service providers out there who are willing to host the site... most at a premium that covers the inevitable hack attacks.
NGC is what we in the business refer to as a "body shop."
http://www.realrates.com/bbs/messages/tips4.htm
Which is why you don't try to implement this broad an IT contract. Was a damnfool idea at the start.
Why would I do that? They probably have STDs.
Which things shall I avoid paying for? Shall I avoid paying for education so I have to deal with even more ignorance in my daily life? Shall I avoid paying for environmental protection and enjoy the poisons in the air I breath and water I drink? Shall I pay a toll every time I turn a corner, coordinated by a ticketmaster-like company that takes a huge chunk since even that's preferable to constantly stopping at a booth? Perhaps I should avoid paying for social security so that anyone who gets wiped out in the stock market can just hit the streets and die when they get old. Including me if I should pick the wrong stock. And who needs medicare? Surely I'll be better off living in a society with massive pockets of infestation just waiting to jump the fence and sicken me.
As it happens, I'm a proponent of small government and local government. I think we'd be better off if the federal government shrank to a quarter of it's current consumption and I think we'd be better off if state, county and city governments picked up no more than half of that shrinkage. But your Anarchist screed is a tired, disproven theory. While it's true that everything government does it does badly, most of what government does benefits you by improving the lot of everyone in the society of which you're a part, and most of it has been shown not to function consistently without government involvement.
What makes you think stealing and publishing someone else's writings is "journalism?"
the issue of why are we even taxed never gets brought up.
Why would it? Is there any taxpayer out there who doesn't understand why he's expected to pay taxes?
I don't want you walking naked down my street and TPing my trees. And I definitely don't want you waving a gun at me when I object. Not even that little member you call a "gun." Preventing you from doing so consumes a certain amount of resources and manpower... efforts which my taxes support with my gratitude.
It makes sense for a bootloader to place data and code outside of partitioned space. It makes more sense to place the code inside a partition, even if it's a one-track partition dedicated to the bootloader. If they collided with components of Windows' bootloader or FreeBSD's bootloader, or some pre-boot hard disk encryption software I'd have little sympathy for them.
On the other hand, user-level apps storing data on the hard disk outside of partitioned space is very bad mojo. They should not be doing that. Ever. Period.
You're welcome to think you're a clever network security guy and I'm sure you will, but until you account for the role mistakes play in your security process and mitigate them with additional depth your effectiveness won't grow beyond mediocre.
So if you compromise a box on the same LAN as the NAT's external interface AND an allow-all rule is fat-fingered into the NAT box then you can rig the compromised box to interact with the IP addresses inside the firewall and the misconfigured NAT firewall will happily route your packets. I concur; this is an accurate description of one way to circumvent a NAT after a mistake in the firewall configuration.
So, you make a mistake in the firewall rules and you also make a mistake on a DMZ host that let's someone hack in. Wait a minute, that's TWO breaches needed to get through that NAT and poke at the hosts behind it, not the ONE breach needed to get through the merely stateful firewall.
Nice try but no points. NAT isn't invulnerable. Neither is the merely stateful firewall. But the merely stateful firewall is breached from the outside in with just one mistake in the configuration. NAT has an additional layer of depth to its security. Got anything up your sleeve that gets you through the NAT box to a host you didn't intend to expose with only the one easily-made mistake with the firewall rules?
Good try.
Problem with that example is - the source route option is disabled by default in essentially everything these days. More importantly: unlike an expansive allow, enabling source routing isn't in the typical mistake path. And even if you intentionally enabled it, someone would still have to guess or scan through a substantial amount of address space to even find your internal address since your internal address is not routinely revealed by your externally available traffic.
I'll give you credit for a solid try. Want to take another shot at it, with functionality you would reasonably expect to exist and be enabled on the firewall after mistakenly entering an allow-all rule?
There's a firewall still in production that processes the source route option?
Got an example of such a magic packet? 'Cause I think you're full of crap but I'm ready to change that opinion in the face of evidence or well supported analysis.
NAT them with what? There isn't exactly a lot of IPv6 NAT software yet.
You never inserted a forward everything to your laptop rule in your NAT config?
No, I haven't. It's never on by default and doesn't find its target dynamically, so in order to make that mistake I first have to deliberately configure -something- to forward from outside to a particular inside address. And that forwarding is in a completely different part of the configuration than the regular security rules where there's essentially no chance of a mistake editing the normal rules causing it.
What's more, the scope of the consequences is that exactly one (1) host is exposed, not all of the hosts protected by the firewall.
What all this adds up to is that an error in configuring or programming a NAT firewall is far more likely to incorrectly restrict access than incorrectly allow access. Incorrectly expanding access from the outside is probably less than 1% of the mistakes. Meanwhile an error in configuring or programming a merely stateful firewall has about a 50/50 chance of incorrectly restricting access and a 50/50 chance of granting incorrectly broad access.
Another way to look at this is: how many distinct barriers have to be bypassed in order to breach the system's security.
With a stateful firewall you have to get past two security functions: the stateful connection manager that doesn't want to allow packets that aren't part of an established and authorized connection, and the host's security on the application ports it listens to.
With a NAT firewall, you have to get past three: the stateful connection manager, the translation matrix that lets the NAT firewall figure out where to send incoming packets to and the host's security.
Thus the NAT firewall has a greater depth of security than the merely stateful firewall. Everything else being equal, a system with a greater depth of security will tend to be better secured.
And in those situations where a temporary service disruption is more of a problem than the rare loss of security, NAT is the wrong tool whether we're talking about IPv4 -or- IPv6. For situations where NAT *is* the right tool, it isn't available yet in IPv6, and that's a problem.
Default policy doesn't matter. If you want to evaluate the efficacy of a security process, you figure out what kind of mistakes can be made and then you evaluate the result of each mistake to see if it leads to a breach.
One obvious mistake you can make when programming a firewall is entering a rule whose practical effect is "allow all." With a generic firewall the consequence of that mistake is total access. With a NAT firewall with a single IP address, the consequence is nil: although the firewall happily accepts the packet, it has no idea which internal host to send it to. Or at worst, there's a single internal host that it decides to send it to; the failure doesn't expose all of them.
Generic firewall fails open. NAT firewall fails closed.
As for most breaches coming from the browser/mail/other application, it didn't used to be that way. What do you think changed? That's right: wide deployment of NAT firewalls in "wireless routers" and "DSL routers" reduced the effectiveness of network-based attacks to the point where attacking the client apps indirectly was more fruitful. If we undo that with IPv6, we'll see network-based attacks rise again.
even block of IPs being NATted
Perhaps I intercommunicated. See, I was talking about modern NAT in which there's exactly one external IP, not RFC 1631 remembered by few and used to next to none. Anything that NATs "blocks of IPs" on a 1 to 1 basis is out of scope and, of course, can suffer from fails-open.
Lets use the right tools for the right job, and lets use them properly
Right tool for the right job. I agree completely. And when securing eyeball networks to a level that doesn't justify elaborate amounts of process such as "peer reviewed change control," NAT is frequently a superb tool.
I was being sarcastic. I know the IPv6 NAT isn't in Linux yet. That was my point. IPv6 will be more deployable once NAT is not only possible at the technical level but also available in the products I routinely use.
And when you accidentally insert an allow any-any in front of the deny? That's what "fail" means. Yours fails -open-.
That same mistake in an address-overloaded NAT firewall has no impact. Interior hosts remain inaccessible from the outside despite the mistake because even with permission to move packets inside, the firewall has no idea where to send them. That's what it means to "fail closed."
Of course, you've never made a firewall configuration mistake that allowed more through the firewall than you intended and you never will, right?
Or if you fat-finger the allow 80 to allow all machines port 80. Or whatever. The point is, each mistake is as likely to create more access as it is to create less. While with nat, mistakes are very unlikely to create unintentionally broad access. It fails closed.