Tear Down the Firewall

lousyd writes "'What's the best firewall for servers?' asked one Slashdot poster. 'Give up the firewall' answers Security Pipeline columnist Stuart Berman. Through creatively separating server functions into different, isolated servers, and assigning them to a three tiered system of security levels, his company has almost completely eliminated the need for (and headache of) network firewalls. "Taking that crutch away has forced us to rethink our security model," Berman says. The cost of the added servers is greatly minimized by making them virtual servers on the same machine, using Xen. With the new security-enhanced XenSE, this might become easier and more possible. What has you chained to your firewall?"

Comments

Band-aid

[egoriot]

Firewalls are such a band-aid solution to the problem of unknown processes running on your own computers. The right way to solve the problem of rejecting incoming and outgoing requests is to make it easy to see which processes are accepting and making connections on which port.s

Re:Band-aid

[Badanov]

Firewalls are such a band-aid solution to the problem of unknown processes running on your own computers. The right way to solve the problem of rejecting incoming and outgoing requests is to make it easy to see which processes are accepting and making connections on which port.s

Which is what netstat -at and firewalls do...

Re:Band-aid

[matth]

Ummm yeah I know what services are running.. some (like SSH) I only want me to be able to get to from certain IP addresses. Some (like on Windows) are needed for the machine to talk to Domain Controllers (but you certainly don't want joe-smith talking to your machine on port 139).. so yeah there are a lot of reasons to use firewalls!

Re:Band-aid

[Ingolfke]

You're looking at this from a server perspective. It's quite possible you don't want certain traffic on your NETWORK. I don't want people scanning my networks.

Re:Band-aid

[drsmithy]

Firewalls are such a band-aid solution to the problem of unknown processes running on your own computers.

Firewalls have nothing to do with processes running on computers. They are for filtering network packets.

The right way to solve the problem of rejecting incoming and outgoing requests is to make it easy to see which processes are accepting and making connections on which port.s

No, this is the right way of identifying which processes are sending and receiving information, not whether or not those packets are getting to and from the mahcine.

Re:Band-aid

[m50d]

But the point is, if you don't have any listening processes you don't need, then there's no need for a firewall. I do netstat -lnp to find out what's listening on my machine, and all there is is apache, giftd, xinetd just on the ident port, and a few other things, all of which are there because I use them and set them up to be listening. So a firewall would do me no good at all - I'd just have to knock holes in it for those ports, and at that point it's doing nothing different from what I already have. And if you have processes running and listening on ports that you don't want or need, why are you running them?

Re:Band-aid

[SillyNickName4me]

But the point is, if you don't have any listening processes you don't need, then there's no need for a firewall. I do netstat -lnp to find out what's listening on my machine, and all there is is apache, giftd, xinetd just on the ident port, and a few other things, all of which are there because I use them and set them up to be listening.

Firewalls ar a perimiter defence, not something that makes much sense on a server itself.

If you ever dealt with a somewhat sophisticcated compromise like I have quite a few times, you may have seen situations where a rootkit went to great length to hide itself. Hiding from obvious tools like netstat, ps and top is really just the beginning.

What a dedicated firewall allows for that is observing and blocking traffic to/from such a rootkit without being affected by the tricks used for hiding it.

What you setup yourself on your server is not the poinnt, it is what is innstalled and well hidden as rootkit that is what you have to worry about.

Re:Band-aid

[Golden_Eternity]

Firewalls have nothing to do with processes running on computers. They are for filtering network packets. What the poster is referring to is blocking off network traffic to those unknown processes. As an example, ZoneAlarm on a windows desktop... You may not realize the software that is running in the background trying to make outbound connections, but the firewall will catch those connections.

Or on the unix world, if you set up a default deny policy and only allow traffic to specific daemons, then if a new process starts unexpectedly, then you don't have to worry about unwanted connections to it.

If all you're doing is running a couple services that you want the world to be able to access, then yes, a firewall is just a bandaid against the potential for unknown processes running on the system.

Re:Band-aid

[Anonymous Coward]

The right way to solve the problem of rejecting incoming and outgoing requests is to make it easy to see which processes are accepting and making connections on which port.s

No. That requires user knowledge and attention, the failure case is that the human will make a mistake, and the failure case is likely to happen frequently.

Typical security mistake - you've ignored the human aspect of security and come up with a design that is less secure.

The correct model is one that prevents infections, not one that detects infections. An ounce of prevention...

Re:Band-aid

[bigman2003]

The number one reason I use firewalls...(instead of just IPSEC and good security practices..)

The Payment Card Industry Data Security Standard. Which you have to adhere to if you are a good sized credit card processor.

Our old security model was tight, very tight. But the PCI people didn't like the way we handled attempted intrusions. We just blocked all of the ports with IPSEC.

They needed the packets dropped in the way that a firewall handles them.

Same result, but they pretty much insist on firewalls.

So...if you are a big credit card processor, you need to have a firewall...even if it doesn't actually improve your security.

Re:Band-aid

[shmlco]

Sorry, not true. A good external firewall can examine packets moving into and out of your network and help prevent DoS attacks like SYN and ACK floods, IP spoofs, and so on. And extapolating your needs from your own personal machine to a major network is a bit... misleading.

Re:Band-aid

[kyouteki]

That's one thing a lot of people don't realize about financial institutions and their data infrastructures...we can't try anything new or novel because we always have to comply with those damn audit requirements.

Re:Band-aid

[m50d]

If you ever dealt with a somewhat sophisticcated compromise like I have quite a few times, you may have seen situations where a rootkit went to great length to hide itself. Hiding from obvious tools like netstat, ps and top is really just the beginning.

So is getting round a firewall. Of course I don't just trust the tools on the box, I'll nmap it from another one to check there's nothing extra listening. But it's not that hard to have your rootkit periodically connect outwardly, to a server listening on port 80, and even to send traffic that looks like http. If the rootkit's sophisticated enough that I can't detect it without a dedicated firewall, a firewall is unlikely to do any good.

Re:Band-aid

[dekemoose]

BS. You have no need for a packet filter. A properly designed proxy firewall can help prevent attacks against the services you do allow through.

Re:Band-aid

[SillyNickName4me]

If the rootkit's sophisticated enough that I can't detect it without a dedicated firewall, a firewall is unlikely to do any good.

I was talking about a dedicated firewall, not one running on the server itself.

If a dedicated firewall can detect it then it is obviously good for something, for as far as I am concerned you are contradicting yourself there.

Re:Band-aid

[Darkangael]

The correct model is one that prevents infections, not one that detects infections. An ounce of prevention...

Which, strangely enough, describes a band-aid. XParent post was technically right that it is a band-aid, he just underestimates the usefulness of band-aids!

Re:Band-aid

[SillyNickName4me]

Hmm, a more detailed response is in order I think..

First of all, very few servers have any need to make http connections, and if they do, it is very often known to what machines they will connect, when they will do so and why. Lacking this information already means that you are not implementing good security practises.

I'd go as far as saying that each and every connection initiated by a server must be known. There are valid reasons for servers to make outbound connections in certain cases, but those are limited, and should not be that difficult to document. You REALLY should document them.

Documenting this makes it relatively easy to detect and block the activities of such a rootkit.

A possible exception is a smtp server, but in that case there are other means to monitor its activity, and a dedicated firewall machine is still going to be helpfull.

At any rate, arguing that you don't need a firewall to protect your servers because they are properly locked down is like arguing that you don't need a guard at the gate of a military base since everything is in lockers.

Re:Band-aid

[m50d]

What I meant is that if the rootkit's sophisticated enough to avoid detection by my non-firewall measures, it's likely to be sophisticated enough to avoid detection by the dedicated firewall.

Re:Band-aid

[Anonymous Coward]

I work for a company that just received a PCI audit, and I'm amazed you got someone who actually knew what a firewall was, let alone IPSEC.

To give you an idea of the audit we just received: We run IIS (living in Redmond pretty much forces that down your throat), yet the auditors spent several hours running thousands of Apache and related exploits against our IIS servers. Never once did they try a single IIS exploit. WTF? Aren't they supposed to at least pretend they care about what they are doing?

They asked us if we had an IDS, which we replied that we did. That's all they cared about there, they didn't care what segments it was watching, what software it was running or what it was configured to watch for. Again, WTF?

Maybe we just got a shitty PCI audit firm, but it's the one VISA recommended to us.

Re:Band-aid

[SillyNickName4me]

I understood your point,

I have dealt with cleaning up servers that were compromised. Installing a version of netstat/ps/top etc that skip specific processes and connections is not unusual. Usually the compromise was detected due to the server trying to initiate connections while it should not.

The theory is that creating a single 'bottleneck' that sees all traffic allows for better control over that traffic and makes it possible to detect (and in many cases block) such traffic.

I have found this theory to match reality as long as good security practises are in place, and that includes documenting what a server should be doing, and configuring a firewall to only allow that and nothing else, and to log traffic that should not be there.

The problem is often that having a firewall makes people think they can forego locking down their servers properly. That is a mistake, but it is as big a mistake to think that locking down things properly eliminates the need for a 'guard at the gate'.

What has you chained to your firewall?

[Anonymous Coward]

Through creatively separating server functions into different, isolated servers, and assigning them to a three tiered system of security levels, his company has almost completely eliminated the need for (and headache of) network firewalls.

Not wanting to go what you went through.

Re:What has you chained to your firewall?

[wotevah]

What do you use to make sure your boxes do not make outgoing calls ?

Would you notice a new "app" that only accepts connections from a specific IP address ?

Re:What has you chained to your firewall?

[Shanep]

...my philosophy was "I'm running port scanning to make sure 22, 80 and 443 are the only ports listening on the boxes - why should I put a firewall in front of it to only let those ports through? ... But, unfortunately, you can't just throw the firewalls out even if you don't need them.

But you do need them. You should assume that your servers will get rooted, in which case they may soon be listening on any other ports and initiating connections to anywhere also on any port, or even DoS'ing the rest of your internal machines or worse still machines external to your network.

The power of a dedicated firewall, is that since it may be dedicated to tasks such as segmenting networks, packet filtering, prioritization and bandwidth shaping, but with no accessible service, it is highly unlikely to become rooted and thus is perfect for enforcement of rules or even damage control should a machine become rooted.

You can do so much with a dedicated firewall and whatever you do, it will not just get disabled once an externally reachable service gets rooted.

Re:What has you chained to your firewall?

[Danathar]

Just because you RUN a firewall does not mean it needs to be doing anything. Just turn it on and allow anything to access anything.

Next time the checkbox comes up on the compliance form and you see the box that says "are you running a firewall" you check the box and move on.

Re:What has you chained to your firewall?

[Anonymous Coward]

At my last company, we didn't have a firewall on the website, because my philosophy was "I'm running port scanning to make sure 22, 80 and 443 are the only ports listening on the boxes - why should I put a firewall in front of it to only let those ports through?"

You were and probably still are clearly not component to make security decisions. Please find a new line of work.

Re:What has you chained to your firewall?

[Anonymous Coward]

You were and probably still are clearly not component to make security decisions. Please find a new line of work.

Thank you, that was very informative and helpful. Your insights are breathtaking.

Virtualization is nice

[Anonymous Coward]

But it is still more expensive than a software firewall in terms of resources. Do I really need that expense for my webserver? Not if I'm someone who's not collecting money or other personal data.

Re:Virtualization is nice

[stuart_berman]

My point isn't to replace firewalls by virtualizing servers - it acknowledges that many shops are adopting server virtualization and this is able to provide another layer of security if the security implications are considered.

Nice logic, but

[gcnaddict]

obviously, if you can rethink your security model AND keep up a well-maintained firewall, you will likely be better off :) How hard can it be to do BOTH, not one or the other?

Re:Nice logic, but

[pete-classic]

I agree 100%.

If you were a police chief, and your officers behaved as if they were bulletproof because of their vests, would you take away the vests or retrain them?

Seems obvious to me.

-Peter

Re:Nice logic, but

[m50d]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

Re:Nice logic, but

[gcnaddict]

A firewall would make sure that unused ports that no applications are listening on are blocked The apps which are supposed to listen will keep listening on the opened ports. If there's nothing listening on a certain port, keep it closed :)

Re:Nice logic, but

[m50d]

But the port is already closed, so the firewall's just a waste of processing power and/or money, and time and money in terms of setting it up and making rules for new services you add. I suppose defense in depth, but to me they're more of a pain than they're worth.

Re:Nice logic, but

[Anonymous Coward]

That is the "if we keep everything perfect, then there won't be problems" mentality. Problem is, life and people are not perfect. Someone along the line will screw up at some point and have a port open etc. Think of the firewall as a backup line of defense, just in case somebody screws up.

Re:Nice logic, but

[SillyNickName4me]

2 checks are better then one, gives more chance to catch a compromise.

Re:Nice logic, but

[Master of Transhuman]

Yeah, but the problem is this: what if it's your firewall admin who screws up? Granted, it's better to leave a port open on ONE device than on twenty different ones, but it's still the same problem.

I admit I'm not impressed with their notion that the workstations should just be kept patched and users authenticated before allowing access to the servers.

Still, there is something to be said for this sentence from TFA:

"By accepting that our internal network isn't much safer than a hostile external network, we've created a more realistic security architecture."

And they also do this:

"We assign each user a central identity, which is authenticated and validated before accessing the internal DMZ. We use central directories to manage identity privileges and PKI certificates. Existing systems, such as Active Directory, allow for low-cost private certificate authorities where PKI isn't well-established. We also log and monitor the activity and enforce acceptable application behavior."

In other words, if the end users have to use PKI to get into the internal network, they're basically being treated like potential intruders themselves - which is how it should be, given that much hacking is done from INSIDE the network. If your end-users are treated the same as any script kiddie, you don't have any problems separating the two except via authentication. Although I still wonder if this layout would protect from a clever hacker who does manage to penetrate and fully compromise a workstation.

Still, it should be sufficient to keep the ordinary worms and viruses off the servers - as long the worm or virus can't take advantage of a flaw in the basic network infrastructure.

And if you really ARE monitoring your network servers for bad behavior - with real human eyes instead of an IDS - instead of just paying lip service to the idea - you have the equivalent of a fully monitored system which is probably the best way to prevent intrusion. In other words, human guards AND electronics are the best security, not either one alone.

Re:Nice logic, but

[ScrewMaster]

Yeah ... this does seem like a solution looking for a problem, doesn't it? Kind of like deciding that, well, if I just start eating right and exercising regularly, I won't need my health insurance anymore.

Re:Nice logic, but

[ScrewMaster]

Human eyes are fine but human reaction time is not. A breach can occur and be over with in a very short time, given the speed at which processing and communication occur nowadays. By the time your human eyes are even aware that there's a problem, the organization could be severely compromised.

Besides, good security is layered, because each layer exponentially reduces the risk of a successful breach. Assuming that an operating system is safe from attack on a given port just because the system claims the port is "closed" or that there are no active services monitoring that port is foolish. These guys seem like they're trying to make a statement rather than good security. I know, conventional wisdom says that conventional wisdom is often wrong ... but sometimes it's right. I'm sticking with my firewalls, thank you very much.

Re:Nice logic, but

[timeOday]

Not always - one strong defense might be better than the same defense plus a weak one. There's a diluting effect, both technical (because defenses can create more vulnerabilities) but more importantly the human factor, because people only have so much time and attention to devote to these things, to learning them and keeping them up to date.

Working in a bureaucracy, I've found that new rules are either ignored, or obeyed at the expense of attention to old ones. Time, attention, and willingness to comply are limited.

Re:Nice logic, but

[Hatta]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

Well you could control who the processes can listen to. There's no reason an internal web server should be visible to the entire internet. Or even for publicly accessible sites, if all your customers are in the US it may make good sense to deny connections from say, romania.

Re:Nice logic, but

[Vermifax]

Right up until:

1) Somebody doesn't follow proper procedure and opens it anyway
2) Your machine is compromized by some other means.

Re:Nice logic, but

[Cylix]

Addtionally, everyone keeps thinking about only protecting against attacks we already know about.

The scary ones are the attacks no one has seen yet.

So yeah, why not firwall your boxen and proxy your http requests and make sure you tidy up the incoming hits.

At the company my friend works for... they do this a great deal and have never been surprised by any unicode issues or other http based attacks.

Re:Nice logic, but

[NightHwk1]

Or even for publicly accessible sites, if all your customers are in the US it may make good sense to deny connections from say, romania.

Why would a company want to deny connections from foreign countries? Maybe it would make sense to block SMTP, but web traffic? I certainly wouldn't call it "good sense".

Re:Nice logic, but

[Anonymous Coward]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

A properly configured firewall will prevent the escalation of an expoit to own your whole network. It will prevent server A from talking to server B in the event that server A is compromised. Sure a router would do some of this, but there are ways around routes. Author and poster seem to misunderstand the reason for having firewalls.

From Wikipedia:
The ultimate goal is to provide controlled connectivity between zones of differing trust levels through the enforcement of a security policy and connectivity model based on the least privilege principle.
http://en.wikipedia.org/wiki/Firewall_(networking)

Re:Nice logic, but

[Anonymous Coward]

Nice when a customer usually in US is on vacation or business travel in say, Romania. Non-customer-friendly obscurity.

Re:Nice logic, but

[Anonymous Coward]

Like the poster said - if you only sell to US customers, then wasting bandwidth and possible support costs on foreigners is just not good business sense. Now, I would argue myself that a friendly message explaining the situation would be more helpful but the principle is sound.

Re:Nice logic, but

[Anonymous Coward]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

Plenty. I have apache servers in their own DMZ, mail servers in their own DMZ, a security R&D free-for-all DMZ and of course the safe office internal network.

The external internet facing interface on the perimiter firewall port forwards web and https to the apache-DMZ and smtp to the mail-DMZ. This firewall is configured such that none of the DMZ's can contact the other or the "internal" network and vice-versa plus the traffic to and from each network is only allowed on their appropriate ports. This firewall also performs flawless prioritisation, bandwidth limiting and spamd blacklisting.

If an apache server is compromised, that server cannot in any way exploit any machine on the other networks, etc. However if I had set these machine up like the story, the apache machines would be running local firewall processes which would likely get MODIFIED by the successful attacker, who would then move on to exploting other machines or even just performing DoS, flooding, etc.

That is the beauty of the perimiter firewall. It is dedicated and has "the final say". This guy thinks fancy network layout with local firewalls on each serving host or DMZ is enough. He is nuts. That may well be doable at a high level of security, but that is no reason to give up the absolute power of the perimiter firewall. I've beeb doing like he has for years, but with the perimiter firewall as the ultimate enforcer.

Security is about layers. This guy thinks it's a good idea to remove the strongest layer, which he considers a crutch. After 10 years on the job, maybe he has gone nuts and needs to retire.

Re:Nice logic, but

[SquadBoy]

Security is like ogres, onions, cake, and parafait.

It's all about layers. Far too often people do perimeter security and call it a day and far too often people argue that if your hosts are hard that you don't need to worry about the perimeter. You need both.

Now granted I didn't rtfa but the summary makes sense in some situations that we have where I work. I maintain 5 firewalls with up to 16 ports each. Most of those are internal and a great many of those firewalls/interfaces could be safely done away with using a model similar to this one. But you would be insane to rip out the perimeter. You would also be insane to ignore your middle. Far too many places do just that. So it's all about balance young grasshopper.

Re:Nice logic, but

[Desert Raven]

insightful?

OK, first issue. If you run any *significant* services, you have ports that need to be accessible by your machines, but nobody else's. The best example is database servers. My database runs on a separate machine. My webservers need to access it, but NOBODY else does. The database's access control is not enough, I don't even want anyone outside my network to see those ports, let alone try to muck with them.

Second issue. There are always new exploits coming up for the software you *do* have to expose (http, smtp, etc.) Firewalling unneeded ports (both directions) can prevent the exploit from becoming fully realized. Once upon a time, I had a machine get compromised through a web app. The trick is, the next step in it's script was to "phone home", which it could not do, because I don't allow outbound traffic for anything except what I *have* to, and them only on the exact ports and IPs necessary. I got alerted when suspicious outbound traffic was seen on the firewall.

Should you secure your apps? Hell yes. Firewalls can't help you if your allowed apps are insecure.

Should you be foolish enough to think this is as good as or better than a firewall? Um, what were your addresses again?

Re:Nice logic, but

[JoeMerchant]

This is all great theory. In practice, when our internal network went VPN for all wireless access, all service went downhill fast - more logins to enter, more things to crash, and more applications that suddenly don't work any more. Of course, we're on Win2000/XP, but unfortunately, that's life in the "real world."

Re:Nice logic, but

[Anonymous Coward]

Or even for publicly accessible sites, if all your customers are in the US it may make good sense to deny connections from say, romania.

And which IPs are in the US and which are not? (And resolving the IP is no guarantee of geography as well.)

Re:Nice logic, but

[nathanh]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

To catch mistakes; services left running that were overlooked, weren't documented, can't be disabled (common on Windows servers), or whatever.

The strongest principle in security is defence in depth. You turn off unnecessary services AND you run a firewall, just in case you missed one.

Re:Nice logic, but

[Anonymous Coward]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

Control outgoing connections?
Provide some protection against DOS attacks?

I mean you know, there's more to a firewall than opening and closing a few ports.

Re:Nice logic, but

[Dwonis]

The strongest principle in computer security is simplicity. When you get rid of a firewall, you get rid of a level of complexity and a potential vulnerability.

Re:Nice logic, but

[Master of Transhuman]

You are of course missing the point - I'm obviously not saying that human eyes have to watch every packet. I'm saying human eyes have to watch the monitoring facilities whatever they may be so they can catch the alert - instead of responding to an email ten minutes later.

Try not to read posts so literally.

Secondly, these guys ARE using layered defenses. They've simply layered them differently than the conventional wisdom because the conventional wisdom isn't working well.

"Assuming that an operating system is safe from attack on a given port just because the system claims the port is "closed" or that there are no active services monitoring that port is foolish."

This statement is just ridiculous. What do you think a "port" is? Some physical opening in the box? If the OS or an app is not listening to it, it doesn't exist. It's just a number out of 64,000 others which isn't mapped to any actual memory address. That's why DOS was far more secure than Windows as far as the Net was concerned because if you weren't running a telecom app, DOS didn't know telecom ports existed other than COM1 and COM2 and they were useless as a penetration point without something handling the interrupts.

Re:Nice logic, but

[reuben04]

MOD PARENT UP!!!

Re:Nice logic, but

[einhverfr]

"Assuming that an operating system is safe from attack on a given port just because the system claims the port is "closed" or that there are no active services monitoring that port is foolish."

This statement is just ridiculous. What do you think a "port" is?

Not nearly as foolish as you think. Various trojans, backdoors, etc. could be added to open up that port. A firewall will provide some protection in this case. Indeed a firewall should provide substantial protection for your DMZ servers in any event where any sort of unauthorized remote access is attempted. This includes outbound connectsions (why should your web server be able to make arbitrary outbound connections to the internet anyway?)

In other words, you are thinking of a static snapshot, not of the possibility of using a firewall to contain damage in the event of a security breach.

Maybe, but first, they *are* using firewalls (routers with acls are a form of firewall), and secondly, I still don't like their architecture. The fact is, most attacks come from outside the network. Internal cracking is as common as it is simply because our internal networks have to be more usable and hence have more security vulnerabilities. However, it is ultimately easier to track the attacker back in these cases and press charges, etc. Yes, people could do better in terms of securing the internal zones. Yes, it is probably a good idea to put your internal servers behind a firewall, even if it is only a router w/acls. But most businesses could better secure their internet-facing DMZ's too.

But that doesn't change the fact that firewalls are an important point of network security as even this guy uses them though he refuses to call a spade a spade.

Re:Nice logic, but

[Master of Transhuman]

"Various trojans, backdoors, etc. could be added to open up that port. A firewall will provide some protection in this case."

Again, this misses the points made in the article (although the article could have been clearer and more expanded about this.)

If your workstations are treated as suspect from the git-go, it doesn't matter if you have trojans or backdoors. The article stated that their workstations can only access "presentation servers", and stated that the end user cannot access the app servers, middleware servers, and one further layer in, the database servers. So a trojan is made irrelevant since it can't access any more data than happens to be in the buffer of the apps running on the workstation. So it's unlikely to be able to send anything out of interest anyway - even sending an end-users authentication key would be next to useless since the end-user keys only get them as far as a presentation server.

Also, if a workstation is compromised, it's not hard to engineer a trojan to bypass any firewall protection you have to get data out of the system. Which makes a firewall - even a hardware firewall - less than perfect security. I've been considering getting rid of my software firewall on my home system simply because it has been demonstrated to me how easily it is penetrated by various trojan techniques in use. A hardware firewall would be better, but it is probably possible for a trojan to pump data out piggybacked on another connection regardless. Not too likely on a home system, but quite possible as a result of a well-engineered hack of a corporate system.

Especially since apparently an amazing number of sys admins, especially of small companies, leave the default passwords on even hardware firewalls unchanged.

I agree that the use of ACLs on Layer 3 switches and routers is essentially the same as using a firewall, but that is a semantic argument not relevant to the point of the article, which was not to rely on a single external firewall or, going further, even on perimeter security in the normal sense. Don't read the article or the headline too literally.

While it may be easier to track an insider attack to the guilty party, that is not relevant to preventing or detecting and containing the attack in the first place. More specifically, it is not relevant to preventing the SUCCESS of an attack in the first place. All a firewall does is keep out the riffraff; once an able attacker penetrates it, he's on even better ground than an internal user because he can piggbyback on internal users while being undetected himself. If you treat internal users as the main threat, you are at least halfway to dealing with the hacker who has penetrated your perimeter security.

Again, the point of the article was that perimeter security is not enough - to the point that it MAY be better not to bother with it in the first place.

"Internal cracking is as common as it is simply because our internal networks have to be more usable and hence have more security vulnerabilities."

This was exactly the point of the article. By going to the architecture they did, and leaving the workstations more exposed to the realities of the Net, they reduce the threat of internal cracking, because their own end users are essentially treated as a threat - which they are.

At the same time, the article explicitly stated this made the end users MORE effective in using the Net because on the one hand, they didn't have to be shut off from it by a firewall, and OTOH, they had to be locked down as much as they would be if they had to use a laptop outside the company firewall. So they had to get used to operating in an insecure environment.

Meanwhile the REAL security was applied to the targets of attacks - the servers.

Again, I'd like to see their architecture tested against a good pen-test and compared against a similar architecture with and without an external perimeter firewall. That would be revealing as to the real pros and cons of this architecture.

Re:Nice logic, but

[einhverfr]

So a trojan is made irrelevant since it can't access any more data than happens to be in the buffer of the apps running on the workstation. So it's unlikely to be able to send anything out of interest anyway - even sending an end-users authentication key would be next to useless since the end-user keys only get them as far as a presentation server.

I would hardly say it doesn't matter.

First, if many of the apps are web-based, you can still access any data in the browser cache.

Secondly, the key would only be the beginning of the attack process. Once the key is compromised, it opens up additional forms of attack, such as attacking the services in the presentation servers, etc. Remember that the servers need to be administrated somehow, and there is a strong possibility that with all this virtualization, that much of the administration is remote.

BTW, I do agree that treating workstations as suspect is a good idea. I just don't think it is the panacea that the article seems to think.

Furthermore, reading the article, I am not entirely sure that the author is recommending this approach to everyone else. He seems to justify it saying that his business decisions required balancing usability and security this way. But that is his decision and at least for my business, I would not lightly dispose of the firewall.

Finally the reason why perimeter security is important in most cases is that you usually require some functionality from within the network that you don't outside it. Due to the fact that most attacks (successful or not) originate from outside (even if many successful attacks originate from within), it makes sense to provide some shielding for these services.

So while I think that the article has many good points, the dispensing of the the perimeter security is not one of them.

Re:Nice logic, but

[papaskunk]

Did you read the article? If they're using ACL's, they probably also thought about who can access web resources. Really, blocking IP blocks does no good when attacks are spoofed anyway, PLUS they are probably originating from zombie US machines in the first place.

Re:Nice logic, but

[rs79]

What he said. Enough hasn't been said about physical securuty either. Much easier than hacking in.

Anybody old enough to remember back during the DNS wars when CORE had it's two servers stolen from a locked cage in a major colo with cameras in broad daylight? Unsolved to this day.

As a profession we need to do better. Look at all the identity and CC # thefts so far.

Always assume your computers will all be stolen. How much information can they get when (not if that happens?

Re:Nice logic, but

[pipacs]

The strongest principle in computer security is simplicity.

True, but read the article. Firewalls are much simpler concept than what the author proposes: three layer architecture, ACLs, tickets, virtualization, strong clients, smart admins etc. etc.

Re:Nice logic, but

[Xugumad]

For example, we firewall off MySQL and SSH ports on most of our systems, so they can only be accessed from the LAN. If someone needs to access either from home, there's an unfirewalled box they can SSH into, and on to the destination system from there.

Re:Nice logic, but

[Anonymous Coward]

I think that the nasty part that they've (properly) gotten rid of is the Nazi restrictions on outbound traffic. (You wanna do SSH outbound? Fill out these 45 forms, then go beg at the feet of The Holy Network Admin.). For the most part, the damaging aspect is the presumption of absolute safety on the inside of the firewall. ("Passwords??? We don't need paswords. We're inside the firewall!")

On my network, I allow just about anything outbound (except for some obviously nasty ports that usually evidence infection). Inbound is mostly restricted by the fact that I'm NATted -- but even the one IP that's associated with a real machine (I have two -- one for NAT, the other is 'live') has obviously nasty ports blocked -- both at the firewall and at the live machine.

Security is supposed to be in depth... I would never presume that a firewall means that the inside network is safe -- especially when I have visitors using the inside boxes.

Re:Nice logic, but

[Anonymous Coward]

...The Bush campaign did exactly this during the election campaign last year, preventing any non-US locations from accessing the site. http://news.bbc.co.uk/1/hi/technology/3961557.stm

Re:Nice logic, but

[WWWWolf]

Recently, I've noted a lot of Linux proggie developers have done things like "uh, Unix domain socket, what the hell is that? TCP/IP is all you ever need!" ... All programs suddenly want to open ports for mysterious reasons!

For example, I so far have had no idea how to use many of the PostgreSQL tools without enabling the PostgreSQL's TCP/IP service, which is ridiculous because I don't need it to be enabled - all of the programming languages can use it just fine with local socket, and command line client, psql, doesn't need tcp/ip either!

PostgreSQL isn't the only one either - GNUstep applications seem to be really, really fond of opening ports. Fire up Terminal.app and you get three mysterious ports open for some damn reason or other. If I didn't have firewall, I'd be kind of sweating =)

Re:Nice logic, but

[SillyNickName4me]

Not always - one strong defense might be better than the same defense plus a weak one.

Not if the strong defense does not depend on the weak one. Seperation is good.

Re:Nice logic, but

[typidemon]

I'm no expert when it comes to iptables, but couldn't you (shouldn't you) set the internal web proxy to only accept packets from computers on the internal network anyway?

Re:Nice logic, but

[m50d]

True, but that has to be weighed against the inconvenience a firewall causes to people trying to actually use the network.

Re:Nice logic, but

[m50d]

1)I don't think anyone's dumb enough to open something just because. If they're opening something they're going to want it usable, so they would open it in the firewall as well.

2)Anyone smart enough to do that is easily smart enough to get past any firewall.

Re:Nice logic, but

[m50d]

What does server B have that would let you compromise it? If it's not something necessary, why is it running? If it is something necessary, you can't firewall it off.

Re:Nice logic, but

[Vermifax]

The person opening the port on the machine (in the corporate world) is almost never the person opening the port on the firewall. There is a separation of responsibility.

As for #2, we're talking about an age of root kits where someone with 0 knowledge of firewalls could comprosmise a given system without being able to compromise any host his kit doesn't know about.

Re:Nice logic, but

[m50d]

The external internet facing interface on the perimiter firewall port forwards web and https to the apache-DMZ and smtp to the mail-DMZ. This firewall is configured such that none of the DMZ's can contact the other or the "internal" network and vice-versa

Sounds more like a router to me. Are the networks physically separate? If so, you don't need a firewall, just don't have anything route between them. If not, how are you sure the firewall can't be bypassed?

plus the traffic to and from each network is only allowed on their appropriate ports

This is the part I'm criticising. Why is that necessary? Presumably the only think listening on the apache server is apache, so it wouldn't matter if you allowed traffic to other ports because they'd be nothing listening. Ditto allowing non-25 traffic to the mail servers, it wouldn't matter because there's nothing else listening on them.

This firewall also performs flawless prioritisation, bandwidth limiting and spamd blacklisting.

All useful things, but the device doing them doesn't have to be a firewall.

However if I had set these machine up like the story, the apache machines would be running local firewall processes which would likely get MODIFIED by the successful attacker, who would then move on to exploting other machines or even just performing DoS, flooding, etc.

How would the apache server help them "explot" other machines? As for DoS, you're only any better if your firewall can handle a DoS better than the other machines. If so, why not spend the considerable cost getting beefier other machines?

Security is about layers. This guy thinks it's a good idea to remove the strongest layer, which he considers a crutch.

It is all too often a crutch. It may appear the strongest layer but it isn't, it's merely the outermost layer. People think it's security by itself, you don't need any more layers. Of course adding a firewall to a network won't make it any less secure, but often the effort spent on the firewall would be better placed elsewhere.

Re:Nice logic, but

[Metzli]

I completely agree with you. IMHO, the best setup is the classic "onion" configuration. The perimeter router and firewall log traffic, allow only certain inbound (and outbound) traffic, etc. Web proxies and hardened mail gateways sit in the DMZ, while the firewall only allows minimal traffic to & from them. The application servers, database servers, etc. are inside the corporate network with unnecessary services/processes disabled, regular patching, and minimal user access. Personally, I think the server farm should also be firewalled off from the user networks. This helps to prevent a compromised user machine (be it in a building, connected via VPN, or whatever) from attacking the critical internal machines.

I agree with the columnist that the internal network must be viewed as hostile, especially with VPN access, mobile laptops, hand-helds, wireless access points, etc. However, ditching the hardened perimeter because of these internal threats seems to me like "throwing out the baby with the bathwater." Dumping a good network config because it's not perfect just seems ridiculous to me. His ideas of hardening the client, etc. is absolutely needed, but ignoring the usefulness of perimeter defenses to help mitigate exploits (such as CheckPoint's Active Defense and ISS' SiteProtector RSKill) just seems like a bad idea.

Re:Nice logic, but

[m50d]

Control outgoing connections?

Why? That will only inconvenience legitimate users. Any hacker smart enough to get into a secured system can easily get past any firewall you try.

Provide some protection against DOS attacks?

Better done on an application-by-application basis. You can use a separate device, but doing it in specialist fashion on each application server is probably going to be more effective.

Re:Nice logic, but

[Anonymous Coward]

you CAN however firewall it off from the rest of your network and let it only talk to the outside world, or only the inside. The point remains that firewalls can be used to ENFORCE network security. Note I never said you shouldn't update your boxen (up2date, yum, w/e). You can't just disable ALL services in case they get compromised. Something on your box will eventually be exploited before there is a patch or even a vuln notice. But go right ahead and disable your firewalls if you like. No skin off my back.

Re:Nice logic, but

[stuart_berman]

Not sure I follow where you are going on this...

We use N-tiers within our network (not just the DMZ).

Let's say we have a presentation layer with a web server that is responsible for serving up content to end users (those end users may be on the LAN and on the Internet - the network firewall wold permit TCP 80 traffic from any to the web server).
Then we use ACLs to limit exposure of that server to any other systems except as explicity needed: perhaps J2EE access to a application layer server; access to domain servers; access to back up hosts.
Then the application layer server have ACLs around it to allow J2EE access from the web server; maybe TCP 1433/ODBC to a back end database server, etc.

Since we will be using RFC internal addresses, as well as ingress/egress filters and do not permit source routing - then very little chance of IP spoofing internally.

Re:Nice logic, but

[stuart_berman]

I am not saying that we ditch the perimeter.

But the hardened perimeter is becoming harder to maintain since business requirements require that we continually 'soften' it up.

Consider your example of DMZ based systems, why not move them inside to an internal DMZ and treat all users as untrusted?

Right now your DMZ sites between external untrusted users and internal trusted users - how about flipping the logical positions of DMZ and internal users?

Re:Nice logic, but

[stuart_berman]

Nice set of comments throughout - unfortunately my article is more of a Reader's Digest version of the situation - check out my post earlier today.

There is a lot of real value in monitoring that seems to finally be getting the attention of IT. There is a wealth of information in our firewall logs alone - but we haven't really applied good data mining tools yet.

A lot of the new event correlation tools look promising. Prelude is a nice open source framework. OpenService.com makes some interesting tools with good reporting and alerting capabilities - an approach they take that looks promising is to rate groups of events by risk rather than individual vulnerability.

Websense has done this rather successfully with their EIM product. Categorize activity by business effect (legal liability, productivity loss, etc) and then subcategorize into classes (spyware, hacker sites, etc). The serious stuff makes itself obvious in short order - the noise is separated out.

Re:Nice logic, but

[Master of Transhuman]

Thanks for the references. I'll look into them.

I hope to be doing HIPAA compliance work for health providers in my tech support business, and this sort of thing is going to become more important as identify theft rings start penetrating networks and compliance laws make it expensive to get penetrated.

Firewalls are good for keeping out the riffraff and script kiddies and the odd worm, but real security has to deal with stealth penetration by competent crackers for the purpose of acquiring information rather than system damage.

I'm not 100% convinced that external Net firewalls are useless, but I can see the point of the article, unlike many others on Slashdot. It's a valid concept as long as it's done right.

Re:Nice logic, but

[m50d]

How? If you're going to do it by making all traffic pass through the firewall, you could do it more easily and securely by physically isolating the server. Though I still don't see how not being to access server B from server A is a risk when server B is publicly accessible.

Re:Nice logic, but

[Anonymous Coward]

Wow. I simply outsourced everything. That way if something happens, I can simply CMA and blame the vendor for all the problem. Solution will be to replace the vendor and boom - management recognition that I took preventive action and exhibited leadership skills by firing the vendor. Of course I will post this as an AC.

Re:Nice logic, but

[Anonymous Coward]

Sounds more like a router to me.

Well modern firewalls are smart routers. They decide where to route and if to route at all based on sometimes some complex rules.

Are the networks physically separate? If so, you don't need a firewall, just don't have anything route between them. If not, how are you sure the firewall can't be bypassed?

I'm rarely sure of anything, because I'm always willing to accept extreme or unforeseen conditions may change things.

They're logically seperated by the firewall. The firewall can and does deny traffic between certain interfaces for example. I don't see how this is any less secure than networks which are physically seperate but logically connected. And there is obviously no point in talking about networks which are both physically and logically seperated (talking in absolutes here, no firewalls required).

plus the traffic to and from each network is only allowed on their appropriate ports

This is the part I'm criticising. Why is that necessary? Presumably the only think listening on the apache server is apache, so it wouldn't matter if you allowed traffic to other ports because they'd be nothing listening. Ditto allowing non-25 traffic to the mail servers, it wouldn't matter because there's nothing else listening on them.

You should account for the worst case. Especially when it is so cheap to do so. Consider the apache case. You have apache in a DMZ but don't bother restricting traffic to being between it and the external interface or restricting to ports apache is likely to use. This apache machine gets rooted and then the hacker decides to use that as a spring board to attack your other machines by traversing beyond the apache DMZ and into the private network. This possible due to not blocking traffic from the apache DMZ to the internal network and this problem also made worse by the fact that the attacker can now attack using MS Windows ports at his leasure. Maybe the network admin tried to be smart by giving all machines behind the perimiter firewall no internet routable addresses and thought this would be enough. This might appear to protect the internal office network machines since they only make stateful outgoing connections, but if traffic can be routed between the private IP addressed apache machine sitting in it's own DMZ, to the private addressed office desktops or other servers (their own DMZ or not), then you have effectively allowed what appeared to be secured networks to be exploitable. All because you did not bother taking the very quick, cheap and simple route of only allowing traffic which is expected.

Knowing that you only want the apache server to see the internet and that you only want the internet to see the apache server on the expected ports, this should be enforced because it is so cheap and easy to do so. The important point being that when someone successfully attacks the apache server, they have control of it and thus this machine which you expected to only be listening on particular ports is now doing all manner of nasty things. Behind your firewall no less and quite possibly within reach of your other "protected" machines. If the rest of your network and machines are protected with such assumptions (only listening on on certain ports, ignoring that the machine may get hacked), then you have given the hacker the key to your entire network and all because you did not add such a simple layer of security.

This firewall also performs flawless prioritisation, bandwidth limiting and spamd blacklisting.

All useful things, but the device doing them doesn't have to be a firewall.

Of course, I did not say it did. But putting these on the perimiter firewall allows for ultimate enforcement. The perimiter firewall is the last line between all your other machines and the internet, as such this is where I would expect to place these things. It adds value by the fact that the firewall is at the gateway, has the final authority and is very unlikely to be

Sigh...

[EQ]

Let me try selling THIS to my boss, with the Cisco guys whispering sweet nothings in his ear about PiX Firewalls and all this wonderful "solution in a box".

Or is this another Flavor of the Month event?

Re:Sigh...

[cazbar]

Just remind your boss that Cisco has one goal, and it isn't to secure your network. They are there to sell you stuff. Cisco, like most big companies, will try to scare anybody who doesn't know much into buying their stuff when it really isn't necessary.

And for those of you who think Cisco is really reliable, I'm only 6 months out of college and I've seen 3 Cisco switches die (none of which I was responsible for).

Re:Sigh...

[Anonymous Coward]

So long as Cisco & friends's sales guys have a bigger lunch budget to wine & dine your CEO in strip clubs than you, you'll be buying Cisco firewalls even if they merely sit on the shelf next to your servers.

And if you think I'm kidding, that's what our company does with SQLServer. Microsoft's a wonderful business partner, introducing us to most of our larger customers; so we ship our "sql server based" version of our product to them. However SQLServer merely contains a practically unused copy of the working set of data in our postgresql database that the application runs off of. (posting as AC, because I very very much appreciate their customer introductions, and wouldn't want to get them mad)

Re:Sigh...

[pyite]

I'm only 6 months out of college and I've seen 3 Cisco switches die (none of which I was responsible for).

The number 3 is unrepresentative of anything without saying how switches that's out of. In the past six months, I've probably seen more than three Cisco switches fail. However, that's in a deployment of close to two thousand Cisco devices... from the cheapest of the cheap to the most expensive of any. That said, devices usually fail for a reason. Maybe the closet has poor cooling (common) or maybe there's a lot of power spikes and dips (also common), or maybe you're just unlucky (you do have a service contract, right?).

Cisco, like most big companies, will try to scare anybody who doesn't know much into buying their stuff when it really isn't necessary.

As with anything, if you don't know what you're buying, you have no business purchasing it.

Re:Sigh...

[ewg]

Don't you think you'll get caught eventually?

Say, for example, PostgreSQL-specific error messages appear on a user's screen, or maybe some future version of the operating system breaks PostgreSQL but not SQL Server.

Or a non-technological leak, such as a loose-lipped staff member saying the wrong thing in front of the wrong person. Or worse yet a disgruntled ex-employee turning you in.

Seems like an incredible risk to take.

Re:Sigh...

[Anonymous Coward]

The first problem is that your boss talks to vendors directly instead of researching hardware specs himself or having others beneath him do the research and talk with the vendors and then bring the facts to him. Persons making a purchasing decision should actually not talk with sales vendors but at least second hand through coworkers.

This minalmilizes people falling for "sales bullshit" and hype.

That said even I sometimes fall for snazzy powerpoint presentations so I don't let them be shown in my presence by vendors or show videos. If we want something we contact the vendors and don't listen to their advice is at all possible unless a service contract is included.

Re:Sigh...

[lousyd]

Cisco has one goal, and it isn't to secure your network. They are there to sell you stuff.

Right. And the security of your network has nothing to do with the stuff they sell...

If they *don't* make securing your network their goal, then they aren't going to make much money in the long run are they? Either you have a point and you've failed to make it, or you're outsourcing your arguments to the debate equivalent of a second hand store, relying on worn out, half-assed mantras devoid of intellectual content.

Re:Sigh...

[niteguy]

In the Cisco line, the GSR is not the most expensive of any.

That honor would belong to the Cisco CRS-1...

http://www.cisco.com/en/US/products/ps5763/

Re:Sigh...

[pyite]

I had a feeling someone would say that. They're not exactly widely available at the moment. That said, I would like to have a CRS-1 to play with, but I don't see it happening. 12000s with long range OC-48 optics are expensive enough.

Re:Sigh...

[Cramer]

A new Cisco anything is f'ing expensive. ALL their shit is overpriced, however neat and all. Go look at their financial reports... they made (profit, not revenue) Four. Billion. Dollars. last year. And that's after accounting for R&D, staff, etc.

Re:Sigh...

[Cramer]

Indeed... they are, in fact, too stupid to secure a network. I refer everyone to IPS signature #4514...

<entry nda="false" dontDelete="true">
<var name="SIGID" default="4514" protected="true"></var>
<var name="SigName" default="SNMP Community String Public" ...</var>
...
<var name="Protocol" default="UDP"></var>
<var name="SigStringInfo" default="0406Public"></var>
<var name="SigVersion" default="S118"></var>
...
<var name="RegexString" default="\x04\x06[Pp][Uu][Bb][Ll][Ii][Cc]" protected="true"></var>
<var name="ServicePorts" default="53"></var>
</entry>

Re:Sigh...

[Pete]

As opposed to not taking advantage of the networking (in the business connections sense) possibilities that a (duped) Microsoft appears to be offering them?

Hell, the thing I'd be most worried about is if his clients found out they were unnecessarily paying for a Microsoft SQL Server license. Microsoft themselves probably wouldn't give a damn, but I can easily see the AC's actual customers getting more than a little annoyed at that sort of deception.

But given the vagaries of business in general, I'd have to say that this is one of the least evil things I've heard of a company doing. In fact, in some cases (eg. if AC's company pays for the (unused) SQL Server licenses) it may not be evil at all - just playing Microsoft for a fool. And that's hardly evil, that's almost a public service. :)

paranoid

[Anonymous Coward]

only paranoid people use host based firewalls. the corporate checkpoint firewalls is enouth network protection

Re:paranoid

[Master of Transhuman]

You obviously didn't even CONCEIVE of reading the F'ing article, right?

Good /. reader, good boy.

Nothing - not using one

[maxrate]

For my servers (mostly W2K & RedHat) I do not have them on a physical firewall. I restrict what can be done by blocking ports that aren't needed. I keep the boxes up-to-date.

Realistically, I'm not sure there is much more I can really do other than logging in a checking things out when ever I can (which is often).

It's worked well for me (so far), and I've had server directly on the internet since 1999. I got hit with code-red on a server once.

Re:Nothing - not using one

[Anonymous Coward]

I set up all my servers, internal and DMZ, as if they were in a hostile network (close ports, shut off all services that are not needed, have iptables running on each one) but I still like having a firewall at the gate for a couple of reasons.

1) Central logging point to see what is going into and coming out of the company.

2) Protect Windows machines on the network ,( I don't care how much you patch and try to configure properly, I just don't trust the windows machines to be secure.)

3) NAT. I like to have external services NAT'ed to DMZ servers. That way I can move services around from machine to machine any time it is convenient.

Re:Nothing - not using one

[Anonymous Coward]

I restrict what can be done by blocking ports that aren't needed.

Uh, so you use a firewall? (whether or not it's on the same machine is irrelevant)

Realistically, I'm not sure there is much more I can really do other than logging in a checking things out when ever I can (which is often).

Or run a solid firewall and not have to worry about all the individual machines behind it (virtual or not).

"Simple" ACLS

[wcdw]

By defining simple ACLs, we further isolate our backend servers.

Personally, I've never found ACLs as easy (or as flexible) as other firewall solutions. But in any event, ACLs are firewalls, call them what you will....

Re:"Simple" ACLS

[andykuan]

Sure, but ACLs come free with your router. Why buy another piece of hardware? Firewalls are another network component that can break and another device you have to train your staff to use.

If you know what's behind your firewall (and if you're running a bunch of web servers, you better know what's there) then there's no need for a firewall.

Re:"Simple" ACLS

[PornMaster]

And router ACLs in most (all?) cases aren't stateful, so you need to allow access in both directions as opposed to one direction with state retained.

If you can't set the source port for an application, and only the destination port, you might be leaving much bigger holes than you would by throwing a firewall into the mix between subnets.

Re:"Simple" ACLS

[Anonymous Coward]

They are firewalling on their layer3 switches. Hence they are routing, switching, and controlling on a switch.

Last time i checked the routers, switches, and firewalls could all perform those functions, however, each device is specialized and performs best when doing a certain chore.

Routers slow down when they do too much switching and access controlling.

Switches slow when they do too much routing and access controlling.

Firewalls slow down when they do too much switching and routing.

Firewalling and routing on a switch works just fine for small offices and home offices, but be prepared for problems on an enterprise level.

Re:"Simple" ACLS

[Anonymous Coward]

ACLs DO NOT compare to what any modern firewall does. Using TCP as an example (since that's what most traffic is), an ACL lets you check the source and destination IP, and a source/destination TCP port. If a packet matches what's allowed, the packet is allowed through.

What an ACL doesn't do that any reasonable "stateful" firewall does is keep track of what sessions are active and then ensure that incoming traffic is part of an existing session, contains valid TCP headers, and is not just a rogue user trying to do a DoS attack. Firewalls will track sequence numbers, look for SYN attacks, sometimes do reverse-path checking to give some level of automatic anti-spoofing prevention.

That being said, a firewall is only ONE level of security, and sometimes gives companies and users a false sense of security. A firewall does no good if you allow a connection to port 80 on an unpatched IIS-Windows NT 4.0 box (unless the firewall is looking for attack signatures, but even then you're not 100% protected).

Any good security solution requires disciplened design of a network and maintenance of hosts, with multiple levels of protection (anti-virus, firewalling, shutting down unnecessary services, patching, etc.)

Also, security is very different for different applications - Google will have different security needs from the DoD's private systems, so please remember this before all you network administrators out there go and remove your firewalls.

Re:"Simple" ACLS

[jon3k]

Because routers are routers, and I don't want them wasting time trying to do things like NAT and stateful packet inspection?

Re:"Simple" ACLS

[wcdw]

I don't disagree that ACLs are a piss poor firewall solution. However, they are a method to prevent intrusion, and hence, at least in my book, meet the qualifications as [an attempt at] a firewall.

Frankly, ACLs suck, at least in the Cisco world. That doesn't stop a lot of organizations from relying on them.

Re:"Simple" ACLS

[andykuan]

That's why you wouldn't do NAT and stateful packet inspection. Just ACLs. And this is only in a server environment where you know what's going on your web servers. I wouldn't recommend ACLs-only for an office environment where you would have no idea what's going on behind your firewall/acl-router/whatever.

Re:"Simple" ACLS

[Metzli]

What about a site-to-site VPN with a business partner? Would you rather configure your routers with ACLs for the unencrypted traffic or would you prefer to configure your firewall for a site-to-site VPN with NATs? For a business that doesn't require encrypted communications with another business, then going w/o a firewall may be doable. For a business that must have secure access to a partner's network (think some healthcare organizations), going w/o a firewall just isn't that feasible.

Of course but

[ravenspear]

How is that not already easy?

netstat -lp --inet --numeric-ports

I'm sure there's a Windows equivalent if you use that.

Re:Of course but

[NeoThermic]

And for windows:

netstat -v -o -n -b -a

(you can ommit -v for a quicker display)

NeoThermic

Re:Of course but

[secolactico]

netstat -lp --inet --numeric-ports

Actually, it would be more along the lines of "lsof -i -n"

Just knowing the ports won't tell you which process is responsible for them.

I'm sure there's a Windows equivalent if you use that

Sysinternals has some very nifty freewares that give this info and more.

Still, I'd rather keep the firewall. I like granularity. What if I want to limit access to certain source ips? Limiting them on application level might still leave open to buffer overrun kind of vulnerabilites.

Re:Of course but

[ravenspear]

The -p switch to netstat that I included in that command shows the program and pid. lsof would work too but that's more common for BSD.

Re:Of course but

[strikethree]

the -v and -b options fail for me in windows xp. what version of windows are you using and having those options as valid?

Re:Of course but

[Badfysh]

Or you can use a nifty little freeware app called Active Ports.

Re:Of course but

[secolactico]

Doh! You are right, of course. I'll plead guilty to ignorance. I'm so set in my ways that sometimes several versions go by before I find out a particular utility has gained new capabilities.

Whenever I want to find the open ports, I just do "netstat -na | grep LISTEN" or "lsof -i -n". It's almost automatic. So much that one of the first thing I install in windows machines are "unixutils". Can't live without good old grep, cat, ls and company.

Re:Of course but

[Ravatar]

C:\>netstat /?

Displays protocol statistics and current TCP/IP network connections.

NETSTAT [-a] [-b] [-e] [-n] [-o] [-p proto] [-r] [-s] [-v] [interval]

-a Displays all connections and listening ports.
-b Displays the executable involved in creating each connection or
listening port. In some cases well-known executables host
multiple independent components, and in these cases the
sequence of components involved in creating the connection
or listening port is displayed. In this case the executable
name is in [] at the bottom, on top is the component it called,
and so forth until TCP/IP was reached. Note that this option
can be time-consuming and will fail unless you have sufficient
permissions.
-e Displays Ethernet statistics. This may be combined with the -s
option.
-n Displays addresses and port numbers in numerical form.
-o Displays the owning process ID associated with each connection.
-p proto Shows connections for the protocol specified by proto; proto
may be any of: TCP, UDP, TCPv6, or UDPv6. If used with the -s
option to display per-protocol statistics, proto may be any of:
IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
-r Displays the routing table.
-s Displays per-protocol statistics. By default, statistics are
shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6;
the -p option may be used to specify a subset of the default.
-v When used in conjunction with -b, will display sequence of
components involved in creating the connection or listening
port for all executables.
interval Redisplays selected statistics, pausing interval seconds
between each display. Press CTRL+C to stop redisplaying
statistics. If omitted, netstat will print the current
configuration information once.

Both -v and -b are on the list for Windows XP SP2

Re:Of course but

[NeoThermic]

As per Ravatar's reply above mine, XP SP2 is what I'm running, and both the options are there for netstat.

NeoThermic

Re:Of course but

[strikethree]

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
Displays protocol statistics and current TCP/IP network connections.
NETSTAT [-a] [-e] [-n] [-o] [-s] [-p proto] [-r] [interval]

-a Displays all connections and listening ports.
-e Displays Ethernet statistics. This may be combined with the -s
option.
-n Displays addresses and port numbers in numerical form.
-o Displays the owning process ID associated with each connection.
-p proto Shows connections for the protocol specified by proto; proto
may be any of: TCP, UDP, TCPv6, or UDPv6. If used with the -s
option to display per-protocol statistics, proto may be any of:
IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
-r Displays the routing table.
-s Displays per-protocol statistics. By default, statistics are
shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6;
the -p option may be used to specify a subset of the default.
interval Redisplays selected statistics, pausing interval seconds
between each display. Press CTRL+C to stop redisplaying
statistics. If omitted, netstat will print the current
configuration information once.

those must be sp2 only options. my organization is still sp1.

strike

Re:Of course but

[AvantLegion]

And for windows:

netstat -v -o -n -b -a

Vonba?

C'mon-shake-yer-body-baby-do-the-Vonba
I-know-you-can't-control-yerself-any-longa

Re:Of course but

[Wolfrider]

+1 Funny

Firewalls aren't totally expendable

[cerberus4696]

It's one thing to give up the firewall if all you have behind it is servers. It's quite another to give it up if you're protecting user workstations. While it's certainly possible to carefully arrange your external services such that they are secure, it's really only possible if you have absolute control over every single device behind the firewall.

Re:Firewalls aren't totally expendable

[Master of Transhuman]

The article discusses that. They deliberately leave the workstations exposed to the Net. The SERVERS are protected and application-level firewalls are also used. The advantage is that they don't have users continually frustrated at being unable to access various services on the Net due to the firewall blocking everything, and their admins have less work to do opening and closing ports for end user special purposes which presumably results in less configuration errors and less security holes.

The overall effect sounds good, but I'd need to see more evidence along the lines of EXACTLY how they're set up and also whether they have withstood SIGNIFICANT hacker attacks with this configuration rather than just script kiddie scanning.

Re:Firewalls aren't totally expendable

[texroot]

The article seemed pretty vague to me about how they're making the workstations more secure. A brief bit about keeping the OS patched, anti-virus, pki, Active Directory and such. Didn't sound like anything unusual, or not done by most larger companies.

They just are more exposed due to the lack of a firewall. How this is better I'm not sure. Of course even with a firewall we have lots of virus attacks at my place of employment, but some protection from a firewall is still better than none.

Re:Firewalls aren't totally expendable

[Master of Transhuman]

The point is they INTEND for the workstations to be more exposed to the Net. This reflects the reality that perimeter security isn't working well. If you treat the workstations as if they're NOT secure, your security actually gets better because now you're dealing with the reality that most hacking is done from INSIDE the network - whether from internal users or compromised workstations doesn't matter.

Their security is reserved for the server tiers. The workstations are protected as well as possible using the usual means, but they are NO LONGER TRUSTED.

Re:Firewalls aren't totally expendable

[Anonymous Coward]

The point is they INTEND for the workstations to be more exposed to the Net. This reflects the reality that perimeter security isn't working well. If you treat the workstations as if they're NOT secure, your security actually gets better because now you're dealing with the reality that most hacking is done from INSIDE the network

Treating the workstations as if they're not secure is well and good, no doubt. Why does doing that require the company to needlessly risk the security of those workstations by exposing them to the net, though?

Their security is reserved for the server tiers.

That is just absurd. Why "reserve" the security for the server tiers only? It's not like they can't do their best to secure both.

The workstations are protected as well as possible using the usual means, but they are NO LONGER TRUSTED.

No, the workstations are not protected "as well as possible" at all. If they were, all access to the net would limited to strictly that required for business operations, and all such access would be through an application layer proxy. And that's at a minimum.

What is XenSE?

[Lemming Mark]

I was present at the XenSE meeting (that's me at the bottom of the list ;-) I'd like to clarify exactly what XenSE is and what it isn't:

What XenSE isn't:
* it's not Xen's "security issues team". It's not for patching exploits, etc.

What XenSE is:
* the "virtual machine monitor" equivalent of SELinux
* mandatory access control for virtual machines
- e.g. you might enforce some sort of information flow between virtual machines (e.g. "Top Secret" only talks to other "Top Secret")
* enforced from the very lowest levels of the system, so should be very trustworthy

The goal is that the complete XenSE system achieve a higher security rating than currently possible with SELinux alone. The initial prototype of the mandatory access controls has been supplied by IBM and is in the 3.0-testing tree right now. Fully achieving the project's security goals will take considerably longer (Xen 4.0 timeframe).

Re:What is XenSE?

[Anonymous Coward]

Fully achieving the project's security goals will take considerably longer (Xen 4.0 timeframe).

Could I expect some time in the future, to be able to run XenSE on my laptop, with OpenBSD/pf facing the internet while protecting Windows XP Pro?

I would love to be able to deny XP direct network access and only be able to go through OpenBSD/pf on a highly restricted basis.

Re:What is XenSE?

[Lemming Mark]

Yes but not on your existing hardware: running Windows XP will require hardware virtualisation support. Intel and AMD will be releasing this shortly (Q2 this year for Intel, Next year for AMD).

You won't need to wait for XenSE to achieve this, though - one of the Xen 3.x series will probably be able to do everything you want. A number of people are running a firewall in a separate virtual machine using Xen 2.0 (which can't run Windows). You're able to assign the network device directly to the firewall domain for better performance: no need to "double virtualise" the network card :-)

OpenBSD, whilst doable, probably wouldn't be the best choice for the firewall virtual machine: a native Xen-aware OS such as Linux, NetBSD or FreeBSD would be better[*].

[*] assuming there isn't a port of OpenBSD by that stage.

Right now...

[CapnGrunge]

I know it's a rhetorical question, but let's say some script kiddie is trying a dictionary attack on ssh. The firewall will be useful to block that IP. Of course it is just _a_ tool, not _the_ tool for the job.

I'm not giving up iptables anytime soon ;)

Re:Right now...

[sumdumass]

Iptables isn't realy a firewall. It can be used as a firewall though.

The only problem i have with getting rid of the firewall is that the conection from the script kiddie os still being serviced by the server. If a firewal is present i have eliminated that conection form the server. One script kiddy in't a real concern but hundereds of zombie machine trying to conect can basicaly cause a denial of service attack for that server. (or at least slow it down.) Right now my firewall only lets certain ip's thru to managment services.

I wonder if a firewall would be usefull if for nothing else, to take care of somethign like this?

Re:Right now...

[plierhead]

I know it's a rhetorical question, but let's say some script kiddie is trying a dictionary attack on ssh. The firewall will be useful to block that IP. Of course it is just _a_ tool, not _the_ tool for the job.

This mindset doesn't work in a real, large, datacentre, which is the kind of environment this guy is talking about.

If your ssh traffic is business critical, then shutting it off to an IP is not an option just because some script kiddy is mucking with you. You can't let him degrade your business.

You should have already had a plan for dealing with this before it happens. After all, if he's serious, it won't be one IP attacking you, it will be a zombie farm.

And if your ssh access is not business critical, or is only intermittently required, then you should not have it sitting there in the open waiting to be attacked.

Yes I know we don't run our home or small business machines like this but big boys do.

I keep my OpenBSD firewall up

[Krankheit]

I have some Debian Linux desktops and and NetBSD/FreeBSD servers on my network, along with a 133 MHz Windows 2000 machine with 32 MB of RAM for compiling my source in MinGW. (I didn't want to put Windows 2000 on my 300 MHz PII machine, that is for my FreeBSD server). I can tell you that I need to keep my firewall. As a lazy admin, I can't worry about the adverse effects of not keeping up on the latest vurnerbilities on securityfocus. And no one should run a regular desktop machine (even Linux or *BSD) directly on their broadband connection. That makes it too easy for the malicous. I think ISPs should require all users have at least a software firewall. Maybe if you aren't a lazy admin like me, you can afford the risk of running your server without a firewall in between.

Firewalls are needed only for leaky systems

[KiloByte]

In general, firewalls can be compared to a tarpaulin stretched on four sticks above a house. It has an effect only if:

• the roof is leaky
• you want to make your yard free of rain
• you own a number of houses, and want to ensure they will be free of rain even if the houses' caretakers are idiots

In other words, firewalls are of any use only if:

• you're defending a grossly insecure system (Windows?)
• you have unprotected communication on a network
• you want to enforce a policy

The tarp does nothing for a sturdy roof. There is no way to attack bare kernel (ok, ping of death), and firewalls do nothing to protect services which are already visible to the network. And if you want to use the firewall to block off unneeded services, why in the hell are you running them in the first place?

Re:Firewalls are needed only for leaky systems

[Anonymous Coward]

It is called defense in depth. Why throw firewalls
anyway, doesn't anyone have any common sense
anymore?

Re:Firewalls are needed only for leaky systems

[Anonymous Coward]

And if you want to use the firewall to block off unneeded services, why in the hell are you running them in the first place?

Some services is meant for local users but not for the world. Examples is license-servers and file-servers.

Some services can configure this. But ask your self how long will it take to know for sure that none outside your organisation can access this services? Check a the list of rules in the firewall or check each and every application?

Keeping up with security is usually best with someone in charge. Very seldom have the same person responsibility for every service run.

Re:Firewalls are needed only for leaky systems

[linzeal]

Firewalls can be bypassed if mismanaged as well as any leaky layer of the whole tcp/ip protocol. Ipv6 is better than many other encrypted layers that you can purchase commercially like Cisco VPN's and the like because most script kiddies do not have Ipv6 cracking tools (obscurity) and to mount an effort from a hacker's perspective eventually comes down to the processing power needed to crack a VPN is not easy to come by.

Re:Firewalls are needed only for leaky systems

[Ingolfke]

You argued against yourself.

you're defending a grossly insecure system (Windows?) - Adequately securing a system and then replicating that security policy across a disparate group of servers all serving different functions is not an easy task. On top of that, systems and software have bugs, Windows, Linux, BSD, *nix, all have exploits released at some point in time. With a firewall you can start by reducing your risk by limiting the traffic ON YOUR NETWORK and may be able to do some packet inspection or logging to figure out where the attack is originating from so you can quarantine it. Firewalls can provide day-to-day protection and also can act as a valve to stop specific attacks during a crisis situation (virus spreading, DoS attacks, etc.)

you have unprotected communication on a network - Great point, because I know I encrypt all of my data that flows across the network. We run point-to-point VPNs for every single connection ever made on the network and then run SSL on top of that. Right.

you want to enforce a policy - Who doesn't want to enforce a policy? A policy like, I don't want any unnecessary traffic on my network. Or I don't want it to be EXTREMELY easy to scan my network. Or if I do have a vulnerability on one of my systems or the software running on those systems I want to limit my risk by limiting the traffic I allow to that box?

The point is that having layers of security is a good thing. Don't just rely on your firewall, it servers a purpose to protect your network and provide a general policy (ACLs, as the article described can play a roll here as well).

Re:Firewalls are needed only for leaky systems

[That's Unpossible!]

There is no way to attack bare kernel (ok, ping of death)

OK, so then why did you mention that point if you are going to subsequently shoot it down with one example?

firewalls do nothing to protect services which are already visible to the network

Yes, higher-end firewalls can also scan the traffic on those open ports looking for exploits (ala IDS firewalls).

And if you want to use the firewall to block off unneeded services, why in the hell are you running them in the first place?

Are you serious? I have tons of services running on various servers that I do not want made available to the public, yet need to be available to (a) the other servers behind the firewall, and (b) trusted users that connect over our VPN... which, incidentally, is another function of a good firewall.

The article and your post are pure lunacy. It is not that hard to maintain a firewall, and as long as you plan your internal networking with the assumption that the firewall will not stop a really good hacker, it is just one more layer of security.

Re:Firewalls are needed only for leaky systems

[pla]

the roof is leaky

Sometimes (ie, with Windows), you already know the roof leaks, and can't do a hell of a lot about it. Sometimes (ssh vulnerability, for example), the roof leaks in places you don't know, and you'll only find out when you go to look at those irreplaceable and now water-destroyed family photos you kept in a corner of the attic.


you want to make your yard free of rain

Yes, I occasionally throw summer parties (a (legit) visiting laptop connecting to my WAP). Though I have a wonderful umbrella for my own use, I would prefer the rain not affect the comfort of my possibly umbrella-impaired visitors.


you own a number of houses, and want to ensure they will be free of rain even if the houses' caretakers are idiots

You don't have a (non-geek) SO, do you?

For that matter, you also apparently don't have any coworkers who just lurve having those cute little mouse pointers, enhanced IM smileys, and "need" to know the weather on a second-by-second basis. Yeah, I could lock down every one of their machines - Or I can just block the relevant sites at the firewall. Which takes less work if a similar new annoyance appears?


And if you want to use the firewall to block off unneeded services, why in the hell are you running them in the first place?

Watch your gateway traffic from a normal, healthy, secure XP network (pretend all of the above don't count as an oxymoron). It might surprise you (and scare the hell out of you) to see how many totally legitimate programs phone home for no good reason (XP itself not the least of the offenders).

Re:Firewalls are needed only for leaky systems

[fermion]

To push the analogy, let's look at a patio house. What I mean is a house in which is enclosed by an outer wall, but the interior is open onto a garden. There are realy no 'inner doors'. Often one will enter through the outer door, proceed through a hallway, and emerge into the garden area. The garden may have a some minor covering.

Now, in this architecture there is a danger that someone could scale the wall and enter the house. it is really no more dangerous than someone breaking a window, and since there are often no outer windows, it is in fact somewhat safer. However, and this is the point, much of the time all doors are built as exterior doors so they may be locked securely from the inside of the room.

So this is what I see. There is some savings, and some security, to using more expensive door and walls at each room instead of enclosing the whole house, but there are other costs. Now, if one wants the ablity to isolate each room from the rest of house, like the people in the house are untrusted, then the additional cost is well justified. Certainly in a bussiness one does not want everyone to have access to everything on the network, so one is naturally going to isolated bits of the network, as in the patio home. OTOH, most of us also put a real roof on the house.

It kind of reminds me of the old joke about the leakey roof. When it rains it is too wet to be working on it, and when it is dry the roofs works just as well as anyone's.

Re:Firewalls are needed only for leaky systems

[KiloByte]

For unprotected communication: of course, in many cases the cost of encrypting everything is huge. That's why I said "if", not including any chastising. scp can clog a 300Mhz box on a 100Mbit connection, in many cases you can't afford to encrypt that -- and this is exactly what firewalls are for.

For enforcing a policy: If you control all the hosts, why would you care about people scanning you? An unsuccessful scan is an uninteresting thing due to the very fact of being scanned, and a successful one is one that will get you down anyway. And if you have boxes running services you don't need -- then you don't control those boxes, do you?

[A sibling post]: For having a box accessible only to the inner network: Why does that box have a route to the outside world in the first place? A SQL server ought to have just ssh and SQL, accessible _only_ from the hosts that are supposed to be able to connect anyway.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

Apparently the problem for some admins is that firewalls become a security hazard in themselves because they have to be constantly adminned by opening and closing ports for special end user purposes, which tends to introduce configuration errors and security holes. And if they don't do this, they get endless complaints from the end users that they can't access things they need (or think they need) on the Net.

And this also applies to the problem of connecting with business partners, contractors, etc., as well as supporting new apps like Skype.

By dumping the end users on the Net themselves and protecting the servers only, the admins eliminate this problem.

I'd say it remains to be seen if completely dumping the firewall is feasible, since the article doesn't address whether they've survived SIGNIFICANT hacker attacks using this model. THAT is the real test.

Re:Firewalls are needed only for leaky systems

[Anonymous Coward]

I'm writing this from a machine that's not firewalled (and hasn't been for some years now). Since it runs an operating system that plenty of people would be happy to deploy _as_ a firewall I have trouble with the hand-waving argument that a firewall somehow automatically makes things more secure.

People have overlooked several important things in this thread, things which suggest that for them security is about the warm cosy feeling and not about really making things safer.

Firstly several people have suggested that firewalls make up for users inside the firewall who act as innocent dupes, or even as active and malicious attackers. Bzzt. The "Conspiracy" problem kills you in this case. Software on either side of the firewall can use remaining open channels to conspire to bypass the firewall altogether.

Secondly many people seemed to think that it would be OK to mix "guests" with other systems inside the firewall. That's not going to work either, this is the "Epidemic" problem. One sick computer is physically carried inside the firewall, and it infects all the others even while they remain protected from the other infected machines that are outside.

Now it so happens that I work for a large institution with not one by many firewalls. Officially they exist only to make it safer for users. In practice of course they do three things...

1. Make us marginally safer against some casual attacks, trivial vandalism etc.
2. Enforce arbitrary and harmful policies off-handedly invented by management, which must then be struck out through long winded discussion when they should never have existed at all.
3. Provide a false sense of security which enables hugely damaging worms & other problems to propagate through the site without hindrance.

Oh, and I forgot a fourth thing: Cost us a hell of a lot of money.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

"higher-end firewalls can also scan the traffic on those open ports looking for exploits"

And why? So you know there are exploits being run against you? And this helps how? Your goal is to prevent exploits from being SUCCESSFUL, not from being run against you, since they will be run anyway. Check your firewall logs long enough for a big enough company, you'll see every exploit there is. So what?

"I have tons of services running on various servers that I do not want made available to the public, yet need to be available to (a) the other servers behind the firewall, and (b) trusted users that connect over our VPN... which, incidentally, is another function of a good firewall."

You didn't read TFA, right? They deal with this as follows:

"This begins with separating our servers from our clients. We can do that now, thanks to layer-3 data center switches that allow for the low-cost creation of subnets. By defining simple ACLs, we further isolate our backend servers.

The servers and their respective applications sit in their own DMZ, protected by an Application-layer firewall. We organize servers into three tiers: The first tier consists of presentation servers such as Web and e-mail servers--these are the only servers accessible to end users. The second tier, made up of application and middleware servers, is in turn only accessible to the presentation servers. Finally, the third tier, consisting of the database servers, is only accessible to the application and middleware servers."

They also specifically took this approach because it allows them to connect with business partners and also allow their end users, visitors and contractors to use their laptops more freely without compromising security by treating EVERYBODY as if they were a potential script kiddie - which is how security should be since most hacks occur from INSIDE the network.

That deals with your issues. The only issues I have with the concept is that I don't see where it has been TESTED against a significant hacker attack where workstations have been thoroughly compromised and used to attack the servers in an island-hopping attack. I'd like to see these people do a high-quality pen-test from some pros.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

"Yeah, I could lock down every one of their machines - Or I can just block the relevant sites at the firewall. Which takes less work if a similar new annoyance appears?"

I'd saying locking down the user so they can't install ANYTHING. You're going to update your firewall rules for every oddball Internet site? You have lots of time on your hands for a sys admin. You ARE a sys admin, right? If not, well...

This makes no sense.

As for phoning home, the point of the article is that nothing the workstations do can (supposedly) compromise the SERVERS which are on their own internal network. Now I'd like to see that point TESTED but the concept has been put forward before since perimeter security has been proven to be extremely difficult to do.

Re:Firewalls are needed only for leaky systems

[Monkelectric]

Your analogy is good, but your logic is flawed. Here's a proper analogy: On a long enough time line your roof is BOUND to spring a leak. Knowing this, do you wish to have a tarp?

Re:Firewalls are needed only for leaky systems

[JamesTRexx]

Locking down users might just be much more difficult than denying everything but allowed traffic through a firewall.
Unless your users only run software that can be run as a user (talking about MS of course) you'll have a hell of a time getting every bit of (legitimate) software running in user mode (and "runas" is not an option).
I manage pretty secure terminal servers, but we still keep them nice and safe behind a proxy and a firewall.

Re:Firewalls are needed only for leaky systems

[jav1231]

And how good is patching the workstation? Just this week I had 2 servers infected with a virus that were a) up to date on all M$ patches and b) were running only 2 days behind current AV patches.
Granted, they very well likely were infected internally, but who knows?

Re:Firewalls are needed only for leaky systems

[That's Unpossible!]

And why? So you know there are exploits being run against you? And this helps how?

Sorry, I guess I have to spell it out for you. The firewall scans for known exploits, and if found, shuns the host sending them for X amount of time, thereby thwarting their planned attack 99% of the time.

They also specifically took this approach because it allows them to connect with business partners and also allow their end users, visitors and contractors to use their laptops more freely without compromising security by treating EVERYBODY as if they were a potential script kiddie - which is how security should be since most hacks occur from INSIDE the network.

Wow, thanks for the newsflash! We have the same advantages and security practices in effect, with the added security of an outer firewall!

Re:Firewalls are needed only for leaky systems

[pla]

The point of the article is that nothing the workstations do can (supposedly) compromise the SERVERS which are on their own internal network.

I would respectfully disagree... The "point" of the article appeared to suggest that server admins do the same things they've always done (functional isolation? Differing security levels for less/more critical/sensitive servers? Sandboxing? Whoah, radical stuff there!), and then turned into an advertisement for Xen.

However, the submitter unwisely chose the title "Tear Down the Firewall". Regardless of server administration, real-world networks have servers and workstations (with human, non-IT users of those workstations). Thus, I took exception to that idea. As for the specific points I responded to - Well, #1 says it all... "The roof is leaky". If you can show me a system, that has NO bugs or vulnerabilities, I'll show you the next system from which we'll hear about a major customer information leak occurring.



I'd saying locking down the user so they can't install ANYTHING

1) More difficult to do that it sounds - Someone will always find a way around any level of restriction, and once one person finds it, they all know it. Not to mention, this leads to an interesting HR paradox - You want employees to have computer skills, but not enough to potentialy circumvent security "casually" (as in, not maliciously, but breaking the rules to get the job done more efficiently).

2) My "users" include people above me in the corporate food chain. I can't tell them not to lick the outlets, but I can quietly put little plastic widgets in the socket to keep curious tongues out.

3) Simply put, happy workers get more done. Telling people that you consider them idiots unworthy of trusting with access to their own desktop machines, whether true or not, does not make them happy - Quite the opposite. OTOH, as a well-studied example, giving them dummy thermostats that let them think they have some control over the climate makes people far, far happier, even though the central HVAC stays set at 72F year-round.


I've worked in environments with the sort of policy you suggest, and they simply don't work. They crush morale, breed resentment against IT, and perhaps most important, don't accomplish the desired goal (namely, having a 100% controlled environment to work in - Even cooperative users make such a goal impossible, nevermind those who will deliberately try to get around restrictions).

Compare that to my current situation, in which people appreciate my presence. They call to ask for my help, not to complain that blind-policy-X has once again blocked them from doing their job. When I send out an email telling people about a new threat, I get concerned reponses asking for clarification so no one accidentally exposes themselves at home, either; not people second-guessing me about whether the threat really exists or just threatens my fascist control of their access.



You're going to update your firewall rules for every oddball Internet site?

No. AV and anti-spyware software takes care of 99.9% of the problems automatically. I only need to worry about the "legitimate" software deciding to phone home to mom to tell it all about what it did today. The "cute" software that poses only a marginal threat (perhaps just checking for updates with a frequency that would saturate a T1) yet may readily lure users into installing it. Microsoft's update site (my users update when I decide to SUS one out, damnit!).

As for actual websites, I don't particularly care what web sites people visit... They run FireFox in a reduced privelage context, thereby limiting any damage to depriving themselves of surfing the web until I get around to fixing it for them (a low priority, as they all know).



You ARE a sys admin, right?

Depends what you mean by that

Re:Firewalls are needed only for leaky systems

[tftp]

And if you have boxes running services you don't need -- then you don't control those boxes, do you?

And why that would be impossible? Contractors bring their own notebooks and PDAs, employees do their best to circumvent the policies (so that they can run their MSN Messengers, for example) etc. etc.

As long as you have more than a handful of computers in the business, you can not honestly guarantee that all these computers are always secure.

Also, once a new vulnerability is discovered all your computers become instantly insecure. If you are behind the firewall you take your time to test the patch and push it to the workstations. If you have no firewall.. I pity that sysadmin.

Re:Firewalls are needed only for leaky systems

[KiloByte]

There is a difference between a web/SQL server setup -- where some machines are visible to the world, and some are not, and a wild network.
In the first case, it's better to do things at the routing (preferably _physical_) than to add a firewall. In the second one, a firewall is of course needed.

What I'm advocating, is not letting your server farm wide open. I just really prefer vacuum wall over a fire one.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

You've missed the point of the article entirely.

They're not pointing out that doing layered defenses of the server is something new. Nor did they mention Xen - the submitter did.

They're pointing out that perimeter security doesn't work well and retreating to the servers is more cost and security effective. They're saying perimeter security leads to lax security on the internal network. If that doesn't apply to some companies in your opinion, fine, but it DOES apply to quite a few companies based on what I've read in the trade press.

Secondly, my suggestion to lockdown users only applies to those who think reconfiguring the firewall to block some Web site is an easier maintenance solution. In fact, the article indicates that once you treat ALL users and workstations as suspect, you can let end users do what they want (within some rational reason, of course) because you've concentrated your security on the servers where the "meat" of the company actually is.

Users SHOULD be prohibited from installing anything that needs *system privilege* to run. If your users need some app that some idiot programmer set up to require system privilege to run, then either you are not providing the apps your users need, or you do not have enough time and resources to support them properly when they need to ask you to install something. In either case, it's your problem. It should be company policy that if an end user NEEDS an app to do their JOB (as opposed to following the baseball scores while at work), they get it from the company, not some random Web site. YOU get it, YOU test it, YOU install it. If you can't do that, then obviously you don't know what your users need to do their jobs. It's that simple.

"AV and anti-spyware software takes care of 99.9% of the problems automatically." Which is exactly what the article says they do. Which is opposite to the notion that reconfiguring a perimeter firewall is the better solution.

As for programs phoning home, note that the article's users are using "presentation servers" to access their applications - which means there's nothing to phone home ABOUT unless the trojan can read the app buffers. The end users aren't running applications from their workstations and storing potentially compromisable data on their hard drives. So it doesn't even matter if a trojan phones home - as long as it doesn't put a keylogger on and get the server authentication. That's what the AV and anti-trojan and anti-spyware stuff is for.

And even then, if the trojan compromises the user's authentication, the articles users can still only access a *presentation server* - the REAL data is stored two more layers in on the database servers which cannot be accessed by anything but the app and middleware servers. Which means a trojan is useless - only a live hack can possibly get deep enough into the app or middleware server to compromise the data.

At least, that's the THEORY. As I say, I'd like to see their setup pen-tested with trojans and live hacks to see how it withstands a real-world attack.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

"The firewall scans for known exploits, and if found, shuns the host sending them for X amount of time, thereby thwarting their planned attack 99% of the time."

Yeah, right. One of my five thousand zombie systems gets shunned, so I immediately shift the attack to one not on that subnet. So much for your firewall. Also, what do you do if the host sending them happens to be a business partner you can't afford to just drop packets on? I'd get on the phone to them if I were you rather than relying on the firewall to just dump them, or they'll be calling you.

Also, what the hell difference is it between scanning for known exploits and "shunning the attacker so the attack doesn't work" and preventing the attack from working in the first place and thus not giving a damn about the firewall - which was the point of my comment?

The point of the article is that your "added security" from the outer firewall is probably unnecessary and therefore nonexistent if your internal security is good. Your comment gets modded "redundant."

This is the ultimate reason why corporate computer security sucks - smart-asses who think they've figured it all out and are perfectly safe "because we got a firewall - and a few tricks."

Re:Firewalls are needed only for leaky systems

[asdfghjklqwertyuiop]

And why? So you know there are exploits being run against you? And this helps how? Your goal is to prevent exploits from being SUCCESSFUL, not from being run against you, since they will be run anyway. Check your firewall logs long enough for a big enough company, you'll see every exploit there is. So what?

I think that's what he meant. There are firewalls (checkpoint for example) that look at the application layer traffic and will make sure it conforms to a certain protocol (HTTP, SMTP etc) and can look for suspicious activity like a bunch of '../'-es appearing in query parameters (possible directory traversal) or look for SQL commands, shellcode, etc... it can/will break off the connection or just report it like an IDS.

Re:Firewalls are needed only for leaky systems

[Danathar]

If more end users cared about there systems there would of been more accountability on the part of OS and application vendors.

It's been the one the greatest snow jobs ever. The ability of the OS and application vendors to put the onus on networks (and network admins) to protect their products from bad engineering.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

Nice feature, but my point was if your systems are protected against known exploits, what's the point of the firewall detecting them? After all, they have to be KNOWN for the firewall to detect them, right? If they're known, you'd best already be protected against them, rather than relying on the firewall which becomes a single point of failure. If the firewall has a flaw, those exploits will then get through and have a field day on your internal systems.

If you're going to advocate defenses in depth, relying on the firewall does not support that practice. And if you're already defended against known exploits by other means, the fact that a firewall can detect them is no longer relevant.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

I agree with that, but OTOH it doesn't change anything. You still can't rely on vendors to do proper engineering to make yourself secure. That will always remain the sys admins (and security officers) job.

It would be nice if that job were easier due to proper engineering on the part of vendors, you're absolutely correct about that.

Re:Firewalls are needed only for leaky systems

[Danathar]

It will eventually. At some point I expect software engineering (and becomming a programmer) of systems that are critical (like bridge engineering and building construction) to be a type of job that requires some sort of a certification like an architech or civil engineer. Of course that will not mean you can't program, just if you want to sell something without being liable you'll probably have to be licensed.

Of course this will not happen anytime soon. But it probably will eventually.

When it does...software innovation will slow, but overall quality of end product will probably increase dramatically.

Re:Firewalls are needed only for leaky systems

[einhverfr]

Apparently the problem for some admins is that firewalls become a security hazard in themselves because they have to be constantly adminned by opening and closing ports for special end user purposes, which tends to introduce configuration errors and security holes. And if they don't do this, they get endless complaints from the end users that they can't access things they need (or think they need) on the Net.

Simpler just to say "If you want the port open, here is the process. It may take a few weeks and we may say no, but you have to justify the business need..." If you add the right number of hoops to jump through you can weed out the unreasonable requests and have to deal with a much smaller set of those which really have to be done.

And this also applies to the problem of connecting with business partners, contractors, etc., as well as supporting new apps like Skype.

There is nothing that says that business partners, contractors, etc. can't bypass the firewall. You can use your firewall for things like termination of IPSec tunnels and allow unrestricted traffic into your internal network from trusted networks. Furthermore this can be closed off in the event of a problem.

BTW, if someone from a partner's site was trying to attack my servers (replying to another of your posts), you bet I would use the firewall to drop the connection in a heartbeat. I would also get on the phone with them as soon as I was made aware of this and tell them they have a serious problem... Then we would decide what to do. BTW, the same would be said for IDS firewalls in the internal zone (say internal DMZ's that protect, say, accounting data).

Firewalls are partly useful for damage containment. And ideally, partners should be made aware of this policy *before* they are allowed to connect to one's network.

By dumping the end users on the Net themselves and protecting the servers only, the admins eliminate this problem.

Sure, and presumably they create more.

I'd say it remains to be seen if completely dumping the firewall is feasible, since the article doesn't address whether they've survived SIGNIFICANT hacker attacks using this model. THAT is the real test.

I agree with your skepticism but I take it a step further. The measure of a security policy is not only how well you can survive attacks of a given severity if everything is going well, but how badly one's security is compromised if things go wrong and one important patch is, say, missed because that one computer has been off for three months while the user was on a leave of absense...

The second question is how much damage can a malicious user and/or attacker do to continuing operations if they take control of one of the workstations. This is the real test.

I.e. one can always survive significant attacks if they are the attacks you planned for, but what if your plan is not followed and an attack is successful. How much damage is done?

For example, the ultimate in models for brittle security is the security in our nations airports. Any security breach *cripples* the airport for an extended period of time. If you compare this to the way the security infrastructure is implimented in airports like Teipei or Singapore, the damage is far less simply because it is less centralized, so a breach compromises a smaller set of resources. Even the airports in Indonesia and Ecuador have better security architectures (even if the humans manning them may be more susceptible to corruption).

It is nice that he has protected his servers well (imo something everyone should be doing) but I am not sure that this provides adequate protection for continuing operations in the event of a security breach.

If anything we need more firewalls rather than less. Most servers and special-purpose networks should be behind firewalls (as this guy is doing). But an external firewall is still an immensely powerful tool that should not be thrown away lightly.

Re:Firewalls are needed only for leaky systems

[asdfghjklqwertyuiop]

Nice feature, but my point was if your systems are protected against known exploits, what's the point of the firewall detecting them? After all, they have to be KNOWN for the firewall to detect them, right?

No, not neccessarily. It can look for the patterns of known, specific attacks, or it can look for general issues. For instance, as I mentioned it can look for shellcode for various platforms occurring in connections, enforce conformance to protocol standards, look for telltale signs of directory traversal and SQL injection in web apps, etc.

If you're going to advocate defenses in depth, relying on the firewall does not support that practice. And if you're already defended against known exploits by other means, the fact that a firewall can detect them is no longer relevant.

I'm not advocating relying on the firewall for all your security... not at all. But it can be a nice addition to help catch your mistakes. Maybe you forgot to fully verify the input of some particular field. Maybe you accidentally hit the wrong option while installing something and it started a network-listening service which shouldn't have been. Maybe you didn't get something patched quickly enough...

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

Again, I got no sense from the article that the firewall was thrown away "lightly". From the into, they obviously got fed up with the concept over time and decided to migrate to a system they feel is more economical and at the same time more effective.

I agree with most of your points, but I don't see them being necessarily arguments against using an alternative to the firewall.

I'm not convinced firewalls are useful for damage containment. If a hacker gets into your internal network for the purposes of removing data, he's going to have a plan for bypassing the firewall outward-bound - and since he's already got past it somehow INWARD-bound, I don't think that's going to be a significant problem for him (unless he screws up, of course, but the right security measures and monitoring the network is what the article recommends for that anyway.)

As for trojans and other automated malware, whatever system you have in place to prevent them getting in in the first place should be sufficient to prevent them getting anything out even if they fail to stop the penetration. They really are not a significant security threat overall - they're more of a nuisance threat. While a lot of trojans these days can penetrate a software firewall, and a hardware firewall is much better at stopping them, I don't see common malware as adequate justification for the hardware firewall in the absence of other security measures - which is the point of the article.

Finally, your points about workstation compromise seem to me to be exactly why the author did what he did - to concentrate security on the servers so that whatever happens to the workstations is less a risk than simply encircling the wagons with a firewall and hoping for the best. The point of contention is whether an external firewall itself adds any FURTHER SECURITY (not other features) on an economic basis to justify its existence on anything other than the theory that "more is better" (or perhaps the SubGenius theory that "too much is not enough.")

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

My point about "known attacks" includes "known patterns". Anything a firewall can detect can be detected and dealt with elsewhere - or better yet, as I pointed out in my first post, PREVENTED in the first place elsewhere.

Granted, if you fail to do it correctly elsewhere, you get a vulnerability. But the same is true in firewall configuration, so the issue is just moved from one to the other when adding the firewall. Also, if you DON'T do the checks in BOTH places, you're relying on only one device anyway.

I think the article deals with all this by pointing out that they use application firewalls and Level 3 switches with ACLs to handle the situations you outline. It's whether an EXTERNAL Net-facing packet filtering firewall is needed to do this that they don't buy.

You have to balance the administrative cost of a firewall and the "moat mentality" mindset it tends to create with the minimal additional security it adds once you've eliminated that mindset by eliminating the firewall and replacing its security features with more effective ones closer to the targets of an attack.

To those who say "more is better", I (and the SubGenius) say "Too much is not enough". That is, if you add security resources at the wrong place, you're not enhancing your security, you're actually WEAKENING it because you're wasting resources protecting not what NEEDS to be protected but a lot of other less important stuff AND you're creating another avenue of attack into the system if that security resource fails because it's not effective due to being too general.

The White House has a fence around it and security guards on the fence. But that's just to keep out the riffraff. Sure, it serves as first line of defense - but really only as a tripwire to alert the INSIDE staff of an attack. They RELY on the internal Secret Service posts INSIDE the White House (and their bunkers) to secure the President.

A firewall can do the same as the White House fence - but only to keep out riffraff. An effective hacker IS going to bypass the firewall since he knows he HAS to if he's going to get anywhere. While this may cause him some time lost, most hackers don't view that as a problem. You don't get to BE an effective hacker without having LOTS of time on your hands to screw around learning how to do it and developing your methods. Since you're not physically present at the point of entry, the White House fence analogy to a firewall breaks down. The hacker can take his sweet time bypassing the fence and there will BE NO alert to the inside staff. Any security profile should ASSUME the firewall will fail without giving an alert. The firewall in almost all organizations really is just to keep out the riffraff (worms and script kiddies).

The article simply says that if that's the case, then dump the firewall, harden the workstations to a degree adequate to keep out the riffraff, but don't worry about them, worry about the servers and spend the resources you'd spend on an external firewall to harden the servers. Concentrate your limited defensive resources on the real targets of a hack.

To some degree, you have no choice but to do this when adding layers of security, but the point of the article is that the layers have varying costs and benefits, and an external Net-facing packet filtering firewall doesn't add enough security over OTHER means to justify its existence.

In martial arts, you're taught not to waste movement defending against attacks that aren't going to actually hit you or do damage if they do.

Re:Firewalls are needed only for leaky systems

[einhverfr]

If I compromise a workstation, can I ping flood or UDP flood a server such that I use up all the server's bandwidth thereby knocking it offline and disrupting all the other users? You can't do this from the internet because your internet bandwidth is likely to be less than the server's bandwidth.

Now, the answer to the above question may depend on a lot of things. If the switches that connect the workstations are 10MB/s and the backbone is 100MB/s that would likely prevent such saturation.

More troubling is the idea that arbitrary ICMP packets could be allowed in from the internet. This could provide a much more interesting set of attacks on the application-level firewall including source quench attacks etc. These could come from inside the network but again although most successful hacks happen from within, most attacks come from outside. Note that these attacks have only recently been discussed, but a firewall might prevent one from waking up to a bad surprise one morning. Having a gateway point where once can controll these sorts of packets is quite useful.

My point is that a firewall should be one tool in the box. Not the panacea that many people have seen it as. It is a very useful tool.

A good analogy is this. If you want to secure a building where do you put in cameras, locks, etc?

You start by securing the perimeter. Cameras and locks are put there. Then you look at other critical areas (at Microsoft, these included the library, server rooms, etc) and you put cameras and locks there.

Firewalls function as cameras and locks. You start by securing your perimeter, and then focus on your critical resources (and put them behind internal firewalls just as this guy did, in an internal DMZ). The internal users are sort of in an "internal untrusted zone" where you don't assume that the traffic is safe. This allows you to place about 20% of your effort on protecting the workstations (via the firewall) while focusing your main time and energy on the servers.

The problem is that usually security has historically been given a second place to usability and this has lead to a large number of bad security practices such as relying on the firewall too much.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

I agree with your last point completely. That's one reason I suggest the article is not out of line in recommending that hardening begin from the inside out rather than the perimeter in.

As for internal DoS attacks from compromised workstations, that sort of thing should be easy to detect and eliminate with the right monitoring. If the workstation is compromised, you probably have worse problems than some pointless DoS.

I'm not concerned about those scenarios or with ordinary malware (once systems are in place to deal with them, of course) - I think the real attention should be on stealth hacks that are going for information rather than system damage. With the compliance laws now in place, these things are potentially much more damaging due to law suits and the like than anything that can bring down the network.

We're not dealing with ordinary script kiddies as the primary threat anymore - we're dealing with organized rings of identity thieves run by the Russian Mafiya and the like. Guys who don't mind knocking over a van carrying bank backup tapes and then phishing for customer SSN numbers using the data from the tapes - that's apparently what's been going on in the last few months according to one article I read the other day. While there is no network penetration being done in that sort of thing, penetration for the acquisition of large numbers of credit card info and SSN and privacy-related info is going to be the main threat from now on.

ACLs are firewalls?

[StupidKatz]

Nooo, ACLs are Access Control Lists are ACLs. Firewalls are routers. Use each tool where applicable.

Re:ACLs are firewalls?

[Anonymous Coward]

Nooo, Firewalls are Firewalls are Firewalls. A Router is a Switch.

Re:ACLs are firewalls?

[Aeiri]

Nooo, ACLs are Access Control Lists are ACLs. Firewalls are routers. Use each tool where applicable.

Routers are firewalls, but firewalls are NOT necessarily routers. All a firewall is is a packet filtering system.

I don't understand this "fear" of firewalls that people seem to have nowadays... firewalls are not a bandage, they are a layer of security that should not be removed. Say you want to access SSH from only computer X, well, having the service open to the world and just rejecting logins from other computers still leaves it vulnerable to buffer overflow problems if there are any discovered.

Another really good use for firewalls are egress filtering, egress filtering can essentially create a second layer of IDS, and prevent your servers from propagating viruses to mass amounts of computers if your computer gets infected.

Re:ACLs are firewalls?

[Anonymous Coward]

Routers are firewalls

Routers are not firewalls.

Re:ACLs are firewalls?

[Anonymous Coward]

Nooo, a switch is a hub with dedicated communications channels. Firewalls are routers.

Re:ACLs are firewalls?

[PepeGSay]

In the sense of what he says, they are. If you consider a firewall as a packet filter, then a router can do just that. At its core, a firewall is a packet filtering router, with a management app to make it workable as a firewall.

Re:ACLs are firewalls?

[wcdw]

Finally, a voice of reason.

In point of fact, my [local] firewall is a Linux box ---- acting as as 'advanced router', and running iptables. Whoah! It's a router AND a firewall. What a concept.

Sounds a helluva lot like ACLs to me.

Re:ACLs are firewalls?

[jon3k]

Calling your linux box an "advanced router" is like calling a Yugo a "sports car". A 12000GSR is an "advanced router", not your whitebox pc running redhat.

Re:ACLs are firewalls?

[wcdw]

On the other hand, most /.'ers will likely recognize that "Advanced Router" refers to a kernel compilation option, and was not intended as a adjectival reference.

Particularly since my firewall box, in particular, is old and slow. And why not? It only moves 10/100 traffic for a modest number of boxes across its 5 installed NICs.

The 'Advanced Router' option, however, does provide more ability to play games with the routing tables than the stock linux kernel.

Why not have both?

[ravenspear]

I agree that firewalls should not be implemented as a crutch in lieu of a good security model for your servers, but why not have that and a firewall. TFA makes a good point but most sysadmins who have any experience with good security already know it. Only run the services needed on the servers dedicated to those services.

But it seems to me that rejecting all other traffic with a firewall is a good added measure of security that can only improve the overall security of your setup. It also makes you less visible to attackers and wastes there time.

Re:Why not have both?

[Hamstij]

wastes THEIR time. :-)

Re:Why not have both?

[ravenspear]

What a waste of time that post was. ;)

Re:Why not have both?

[datajack]

Your point is completely correct.

When you design a system, you place security in at as many levels you can. This is called 'Defense in Depth' and has been practised for many hundreds of years (castles were built upon the same principle).

If you can, stip your system to the bare minimun, run a network firewall and a local firewall, protocol analysis, IDS and host level solutions such as PaX all add up.

It's good to work on the idea that no systetem is undefeatable, so arranging a few different security systems can only gain you more security than just one method.

Firewall, specifically provide a good advantage over just stripping a system. FOr one, they typically slow an attackers discovery of available services on your system, A network firewall can hide that a system is there (and therefore leave doubt when things say there's nothing there), they provide a nice central point for detecting attacks against a network, and also give a good choke-point to defend against known attackers.

Re:Why not have both?

[Master of Transhuman]

The article makes the point that it costs money and time to "reject all other traffic" because the end users often need to access things outside the system, new applications such as Skype also need to have new ports opened, and outside visitors need to connect to the network internally which leads to security risks as firewalls are administered.

By treating EVERYBODY outside the server ring as a potential risk, you eliminate these problems and take a more proactive, paranoid approach to the security of the internal network rather than relying on perimeter security which is hard and expensive to do. At the same time, you make the network outside the server ring more useful to end users.

I can see the point - I'd just like to see it TESTED against a good-quality pen-test using compromised workstations against the server ring to see if Layer-Three switches with ACLs and PKI authentication and application firewalls are sufficient to protect the servers against island-hopping attacks by a good hacker.

Re:Why not have both?

[bfields]

I agree that firewalls should not be implemented as a crutch in lieu of a good security model for your servers, but why not have that and a firewall.

Because the existance of firewalls everywhere breaks lots of useful tools (ping) and forces all sorts of stupid behaviour, like using port 80 for all new services, since that's the only one you can count on to get through all the firewalls....

In 10 years port 80 will be the only port anyone uses, and some genius will no doubt start selling http-level firewalls that look inside the http requests to decide what to let through. Rinse, lather, repeat.

--Bruce Fields

Re:Why not have both?

[bfields]

It's good to work on the idea that no systetem is undefeatable, so arranging a few different security systems can only gain you more security than just one method.

Well, not necessarily. Additional layers of code can also expose additional (exploitable) code complexity. There's no reason your IDS or firewall themselves can't have buffer overflows.

I also wonder time spent setting up and configuring another layer of defenses wouldn't be better spent making sure that what you've got works as designed. Administrators don't have infinite time, and it's important to spend what you have on the stuff that's most important.

--bruce Fields

Re:Why not have both?

[ravenspear]

Because the existance of firewalls everywhere breaks lots of useful tools (ping)

I agree with this and it's why I allow most icmp traffic through my firewalls.

like using port 80 for all new services, since that's the only one you can count on to get through all the firewalls

I don't really get why people do this. If you start up a new service on a server, then hopefully you would be a competent enough server admin to know how to open another port to use the service. If you start up a service on a home system or another kind of client machine, then you're probably not running a web server on that machine anyway, so port 80 is really not that different from the others. I don't really see what always programming to port 80 gets you.

The only way I really see it being useful is if someone wants to run unauthorized stuff. Like if the server admin refuses to open a port for x service so the person just decides to run it on 80 since that's already open. In that case I don't really see it as a problem since that person shouldn't be running the service anyway.

Re:Why not have both?

[bfields]

like using port 80 for all new services, since that's the only one you can count on to get through all the firewalls

I don't really get why people do this

The firewall may be run by someone's ISP, or by some distant IT department, neither of which necessarily answer to the person who actually wants to use whatever application it is that needs a port opened up.

More likely, in fact, someone's just firing up an application, finding that it doesn't work, and complaining to the software company that their application is broken, not realizing the failure is due to a firewall someplace. So if you're in the business of selling software that uses the network, you just use http if possible and avoid having to troubleshoot people's firewall setups.

The only way I really see it being useful is if someone wants to run unauthorized stuff.

Yup. But in a large organization I imagine it's easy for the IT department to get out of touch with what individual groups actually need to use the network for. "Unauthorized" isn't really the same as illegimate.

Re:Why not have both?

[Danathar]

Many people seem to be missing the point. IF your security configuration (IE firewall) is keeping you from doing your biz then you've failed. Security in and of itself adds NO VALUE. It does not make your workers more productive, it does not add profit it does not make your network faster.

So when evaluating when/if to deploy a firewall you need to ask yourself if implementing the firewall is going to restrict your ability to do what you need to do. If so is it an acceptable reduction? If not then maybe the firewall is'nt such a hot idea.

Brilliant!

[Anonymous Coward]

Brilliant! You can save money by sacrificing security! Now why didn't I think of that?

Re:Brilliant!

[Master of Transhuman]

You did't have to.

Bill Gates has already done it for you.

See why you buy Microsoft products?

PCI, CISP, ISO 17799, SAS-70

[dracocat]

PCI, CISP, ISO 17799, and SAS-70 are just 4 reasons I have to have not one, but two firewalls. I have to say, I think it is overkill. Yet, I sleep well at night knowing that it should be much easier for someone to move on to another company's servers than to get through the layers of security put in place.

The premise is simple. Multiple layers. Sure you could probably build a box that is very difficult to get into, but do you really think anything is 100% safe? If somebody wants in, I have a belief that they will find a way. That is why you have multiple layers that a would be attacker must traverse. Have an IDS/IPS along the way, and monitor the logs.

Bottom line, is even with all this, it isn't 100%.

If I had my way, I would just use iptables on my outside machines and drop any packets I didn't like. But the powers at be have decided this isn't good enough, and so I have to jump through the hoops to make everybody happy.

Re:PCI, CISP, ISO 17799, SAS-70

[Aeiri]

Having one firewall is one thing, but TWO firewalls is a waste of resources.

ONE firewall with the same config that both have is the EXACT same thing. The second firewall is doing absolutely nothing if the rules are the same.

Unless you are trying to prevent vulnerabilities in iptables, the hardware firewall, or the kernel you are using, in which case, I would have firewall A be BSD or Linux, and firewall B be the other one.

Re:PCI, CISP, ISO 17799, SAS-70

[lactose99]

One significant reason for a dual setup is HA/redundancy. Unless I'm on a platform with redundancy built-in, two firewalls are a must as hardware on one will inevitably fail. This has been a requirement on every corporate network I've supported.

no firewall?

[Anonymous Coward]

from the article:

The servers and their respective applications sit in their own DMZ, protected by an Application-layer firewall.

So every server running an application has its own firewall? A network firewall was to just that, but on a central place. Of course a good network hierarchy helps, but clients need to get to connect to the servers, which is not in the proposed setup.

Re:no firewall?

[Master of Transhuman]

What part of TFA didn't you read? This one?

"The first tier consists of presentation servers such as Web and e-mail servers--these are the only servers accessible to end users."

What part of "presentation" didn't you understand? The clients access their apps via these servers. Everything else is in a (two tier)protected server ring accessible only from the presentation servers themselves. Thus, clients do NOT need to access the critical application, and especially the database (where the corporate data hacking targets actually are), servers.

Now I'd still like to see that the presentation apps can't be compromised, but that's what the Application firewalls and application monitoring referenced in TFA is supposed to accomplish.

He's only giving up the border firewall...

[stefanlasiewski]

It's a rather sensationalist headline. He's not really ditching his firewall, he's replacing the one border firewall with multiple firewalls in the internal network, and is keeping the production environment isolated from the non-production (Office & Development) networks.

He removed the firewall between the Production Environment and the Internel, and is replacing it with several firewalls on the internal network. I count 4 firewalls-- One between the Webservers & Application server, a second firewall between the Application server and DB server, a third firewall between the production environment and non-production environments; and he discusses using ACLs to isolate subnets -- that's conceptually the same thing as a firewall.

But that's not a very new concept, and even with his plan, it still seems like you'd be more secure if you have an external firewall on the added network.

What's the harm in adding one more firewall and only allowing traffic on the HTTP port, HTTPS port and possibly VPN? It's cheap insurance just in case someone made a mistake and left some services running on one of the machines.

Re:He's only giving up the border firewall...

[QuietLagoon]

He's not really ditching his firewall, he's replacing the one border firewall with multiple firewalls in the internal network,

Security consists of layers of protection. By removing his perimeter firewall, he is removing one layer of protection. Now, he can provide all the argumnents that he wants, trying to justify the removal of the perimeter firewall. But the fact remains, he has removed one layer of protection, and has made his internal protection requirements more complex because of it.

Re:He's only giving up the border firewall...

[BobSutan]

This is news how? People have been using tiered network zones for years now.

Re:He's only giving up the border firewall...

[Master of Transhuman]

The "harm" is described in the article:

"Perimeter security was originally intended to allow us to operate with the confidence that our information and content wouldn't be stolen or otherwise abused. Instead, the firewall has slowed down application deployment, limiting our choice of applications and increasing our stress.

To make matters worse, we constantly heard that something was safe because it was inside our network. Who thinks that the bad guys are outside the firewall and the good guys are in? A myriad of applications, from Web-based mail to IM to VoIP, can now tunnel through or bypass the firewall. At the same time, new organizational models embrace a variety of visitors, including contractors and partners, into our networks. Nevertheless, the perimeter is still seen as a defense that keeps out bad behavior. Taking that crutch away has forced us to rethink our security model."

I can see the point. However, as always,YMMV. If you can't devote the resources to doing decent monitoring of your applications and servers, and keeping the workstations patched, then you might need a perimeter firewall.

The point of the article is that a perimeter firewall - a "moat mentality" - leads to lax security on the internal network. And it's NOT "cheap insurance" because it requires much more maintenance to secure an entire perimeter of thousands of workstations AND still provide Net access to those systems (and visitors) than it does to secure an inner ring of a few hundred servers and to treat EVERYBODY outside that ring as a threat - including your own users.

Re:He's only giving up the border firewall...

[Shawndeisi]

I think you hit slightly upon why I would never get rid of my border firewall in your last paragraph.

Sure, it's all well and good to have your individual servers firewalled instead of a border firewall. But what happens when one of them gets cracked? I enjoy my egress filtering, and it will limit the amount of damage that an attacker can do with a proper ruleset. My network will not become a staging point for attacks on other networks. His will.

Re:He's only giving up the border firewall...

[lousyd]

But the fact remains, he has removed one layer of protection, and has made his internal protection requirements more complex because of it.

That's. The. Point. He has purposelly removed one layer of protection, accepting the increase in complexity of the more internal layers because of the benefits the removal brings. Most of the comments made to this story ignore the fact that this guy's motivation was the benefit associated with the detriment. Yes yes yes there are negatives. But the guy is saying that the negatives are outweighed by the positives, i.e. decreased hassle with user applications needing to get through the firewall, and a more realistic security target. That's his point.

Re:He's only giving up the border firewall...

[QuietLagoon]

But the guy is saying that the negatives are outweighed by the positives, i.e. decreased hassle with user applications needing to get through the firewall, and a more realistic security target. That's his point.

That may be his point, but so far as I am concerned, it is just an assertion and I'm not buying it. Naturally the Vice President and CTO a manager of a Fortune 500 corporation is not going to say that his new pet project did not meet its goals. Indeed, going public with the "improvements" may be one of the best ways to make a failed project look successful.

I use a firewall to isolate networks

[StupidKatz]

I'm running all kinds of crud on the intranet that I don't want exposed to the Internet, such as NetBIOS on Windows and some permissive SAMBA shares on assorted servers.

So, the services are running so that I can use them from the inside (with any device on the inside, without mucking with ACLs, additional equipment aside from a switch, etc.) without having the services exposed to the outside.

Now, if you're running services which aren't being used by legitimage users at all... ;)

Re:I use a firewall to isolate networks

[TeknoHog]

I'm running all kinds of crud on the intranet that I don't want exposed to the Internet

I thought this would be done by NAT, with an internal network of nonroutable addresses. While a firewall box may also do NAT, they are quite separate functions.

Re:I use a firewall to isolate networks

[Osty]

So, the services are running so that I can use them from the inside (with any device on the inside, without mucking with ACLs, additional equipment aside from a switch, etc.) without having the services exposed to the outside.

I think the original poster was asking why you're running these services bound to your publicly accessable IP? Bind them to your private, non-routable intranet IPs, not your public IP, and then you'll have nothing to firewall for that service because it has no public-facing presence. This doesn't work for everything (notably, services spawned by inetd, since inetd a) binds to all IP addresses, and b) is not granular enough to specify which sub-service of the super-daemon is private and which is public), but it will definitely work for your Samba scenario.

Side-note: You are using NAT to keep your Windows machines private, yes? If your Windows box is sitting right on the internet, you must have a firewall. Behind a NAT (especially without a UPnP Internet Gateway Device that allows internal clients to automatically request port forwarding), you just need to be able to trust your internal machines and users (since I'm the only user on my internal network, I think I can trust me).

Re:I use a firewall to isolate networks

[Master of Transhuman]

The article deals with that:

"The servers and their respective applications sit in their own DMZ, protected by an Application-layer firewall. We organize servers into three tiers: The first tier consists of presentation servers such as Web and e-mail servers--these are the only servers accessible to end users. The second tier, made up of application and middleware servers, is in turn only accessible to the presentation servers. Finally, the third tier, consisting of the database servers, is only accessible to the application and middleware servers."

Only problem I have with that is what happens with "island hopping" attacks. I suppose their use of Layer-3 switches and ACLs to protect the second and third tier servers is adequate, as long as there are no exploits for the switches - but then again, one could say that about firewalls as well, since there have been known flaws in various firewall products.

Re:I use a firewall to isolate networks

[StupidKatz]

Since I've been given a single publicly-visible IP address, yes, I am personally using NAT/PAT. OTOH, I could segregate the intranet further and isolate the intranet servers from the Windows machine, but considering that I'm the sole user of said Windows machine, it would be far more trouble than it would be worth, all things in my situation considered.

I do like ACLs, but few applications I use explicitly support them. On top of that, they lack, as you stated, greater control over such things as source and destination ports, varios packet types and conditions, etc.

Without the Windows machine, yes, I could do away with the firewall and maintain a secure network. However, considering that the firewall is easier to operate and maintain by atm least a degree of magnitude and has the added bonus of preventing direct contact with any of the systems behind it, I find the idea of doing away with firewalls faddish at best.

Re:I use a firewall to isolate networks

[Osty]

Without the Windows machine, yes, I could do away with the firewall and maintain a secure network. However, considering that the firewall is easier to operate and maintain by atm least a degree of magnitude and has the added bonus of preventing direct contact with any of the systems behind it, I find the idea of doing away with firewalls faddish at best.

Again, missed point. Being on Slashdot, and that you said you're using NAT and running Samba, I'm assuming you're using Linux or *BSD on your public IP. Samba (and many other services like apache, sendmail/qmail/postfix/exim, bind, etc) gives you full control over what IP address the services bind to. I'm not suggesting that you get rid of your firewall. All I'm saying is that if you're firewalling because you're concerned that Samba will leak out to the internet, that just means you haven't properly configured Samba. Bind it to your private IP only, and you won't have any open Samba ports on the public IP that need firewalling (you only need to firewall ports that have services behind them, since requests to ports that aren't currently served will do nothing).

Binding your services to the correct IPs (with the exception of inetd that I already called out -- you're not running Samba from inetd, are you? That's not been recommended for at least five years) is just considered "good sense" while configuring a service. If you don't bind Samba to your public IP and you still firewall those ports, that's not a problem (your firewall will essentially be a no-op). If you did bind Samba to your public IP and that's not the desired behavior, you're better off fixing Samba's configuration than slapping up a duct tape fix of a firewall. ACLs are a different concept than IP binding, and as I mentioned above most services people want to use support binding to specific IPs.

Finally, your NAT configuration (assuming again no UPnP service running that would allow clients behind the NAT to automatically request forwarded ports, as I mentioned in my first post) is enough to prevent direct access to any machines behind it. In that sense, I'll agree your NAT setup is something of a firewall.

Re:I use a firewall to isolate networks

[mi]

I'm running all kinds of crud on the intranet that I don't want exposed to the Internet, such as NetBIOS on Windows and some permissive SAMBA shares on assorted servers.

So, you qualify for a need of firewall under the grandparent's system:

...

• you're defending a grossly insecure system (Windows?)
• you have unprotected communication on a network

...

Re:I use a firewall to isolate networks

[LarsG]

If by 'firewall' you mean a network device that only allows through traffic according to a set of rules, then a NAT is a firewall. The rules that a regular NAT implementation enforces is to only allow through TCP sessions and UDP pinholes initiated from the internal network.

Re:I use a firewall to isolate networks

[stuart_berman]

My point is - what will it take to get that environment changed? (Unless it is a totally trivial set of systems that can do no outbound harm).

Why are you tolerating NetBIOS and permissive shares?

part of a larger security solution

[eth00]

Firewalls are still important in the entire security model. I do a lot of working on shared servers that host websites and have found a firewall can stop a lot of headaches. When some users script gets compromised and a script kiddies goes to send out a DOS of some sort the firewall can block it. I have found that the firewall is more important for exgress monitoring for this type of market but it is very valuable.

While it is true people have the wrong image of a firewall they are still very useful when used correctly. Security is not just a single thing you do to a system but many different layers and the firewall plays into that field. It is also a lot easier to just block some script kiddie at a firewall if they keep trying to brute force a server. I think I am going to keep my firewall for a little longer :)

Summary

[Zarhan]

This article shows that the guy is now realizing that you also need network design besides only putting a firewall at the border and hoping it magically makes everything ok. He's quoting "innovative" networking desings, like

- Segmenting your network to
- Workstations
- Internal servers
- Internal databases etc (accessed by servers)
- DMZ
- Setting up stringent ACLs to only permit specific traffic between segments.

C'mon, this is pretty much elementary stuff. Any network adming should know to design his network like this even in small companies where you have 2 workstations and a single server.

Then he makes a claim that you don't need firewall because only things accessible to Internet (Workstations and stuff in DMZ, like your public website) are running secure OSs patched constantly. I guess they are running OpenBSD with default config then... ...except there are mentions of "Active Directory", so I guess not.

Only real "innovation" comes at the end: The article states that they are running some sort of IDS/IDP system in their network, presumbaly monitoring for any wormlike packets. This is nothing too interesting, anybody can set up Snort and have it running at your switch's monitor port. Only thing is that if it is running only as a logger, it cannot really react fast enough if one of your boxes gets infected with the latest worm from the completely unsecured Internet connection.

If it is running in some sort of transparent bridging mode, where it blocks those packets too on detection, it is pretty much like any...you guessed it...FIREWALL.

He DOES have a point on the fact that numerous applications require intelligent firewalls, the most basic case of course being active FTP. However, almost any commercial firewall (and Linux kernel iptables) supports numerous protocols. Most recent additions are SIP. P2P protocols are prominently missing so far, but I'm guessing that at least Bittorrent will be added soon (at least to Cisco IOS/PIX and Checkpoint).

Still, I wouldn't give too much credit for this article until he provides us with a detailed network diagram and more specifically states what are the exact benefits.

Re:Summary

[ravenspear]

He DOES have a point on the fact that numerous applications require intelligent firewalls, the most basic case of course being active FTP.

I would say Passive FTP is more difficult to firewall on the server than active. Passive puts the responsibility of accepting an incoming connection on an arbitrary high port on the server. Active puts it on the client.

Now some FTP servers let you specify a range of passive ports to announce to the client, but that can break compatibility with some clients.

Re:Summary

[Zarhan]

I would say Passive FTP is more difficult to firewall on the server than active. Passive puts the responsibility of accepting an incoming connection on an arbitrary high port on the server. Active puts it on the client.

I was naturally talking about outbound connections..the usual case is that your workstations need to access services on the Internet, but Internet only needs to get through to your DMZ.

If running a stateful firewall also for incoming connections (instead of just an ACL) the servers can use SOCKS4 or 5 or similar to notify the FW if they need something opened.

Re:Summary

[MegaFur]

I don't know nearly enough about network design to... well, design one or administor one, but I had a feeling this article was bogus--or you know, pseudo-bogus at least.

The clue was, first it starts out making an extraordinary claim about throwing away the firewall, then when you actually read the brief, it starts backpeddling. Like: "Well, er, you can't *quite* get rid of the firewall, but you *almost* can! really! almost. well, er maybe... ok, *sort* of at least..."
---
Now that I think about, assuming your summary is correct (and for the moment, I feel safe making that assumption), the guy saying "throw away your firewall", but really he just discovered network configuration, reminds me a lot of Steve Gibson (http://www.grc.com/

Re:Summary

[dago]

Umh bittorrent is already recognized by IOS (in fact, most p2p protocols except skype are).

Search cisco.com for NBAR.

Re:Summary

[Zarhan]

Ok, thank you. I only checked the nearest router running 12.4 IOS and the ip inspect ? only gives me

(...)
appleqtc Apple QuickTime
bgp Border Gateway Protocol
bliff Bliff mail notification
bootpc Bootstrap Protocol Client
bootps Bootstrap Protocol Server
cddbp CD Database Protocol
cifs CIFS
(...)

Kazaa is listed, though.

Re:Summary

[dago]

trough NBAR.

Altough bittorrent is included in the last 12.4 release only, you could add specific (custom or cisco) definitions to previous versions as well.

Re:Summary

[Zarhan]

Are you sure this is related to *firewall* functionality (ie. start up a bittorrent client inside your network and the firewall allows incoming connections for that client)?

The document seems to talk only about traffic classification, related to qos and traffic shaping. A feature which is probably quite useful for those network admins that wish to limit the bandwidth hogging of P2P applications, but I'm not seeing any firewall (Ip inspect) references.

(Altough you probably could set up a hack by marking bittorrent protocol with some nice diffserv tag and then allowing those tagged packets through...)

Thanks for the information though.

Re:Summary

[dago]

Indeed

Oh, btw, other than that I agree with your original poster, it's more a play on words to say there's no firewall.

But, according to him, this is required to escape the actual mentality of the almighty firewall.

i'll give up my (openbsd) firewalls...

[pgilman]

...when you pry it from my cold, dead fingers.

i do concede, though, that my environments are such that the internal networks (and users) *are* trustworthy.

Nothing has me chained to it

[Sycraft-fu]

But I ceritnaly thing it's the best practise. The principle is simple: Only allow access to things that people should have access to. That way, if something is accidentally set up that could be compramised, it's not a danger since people just can't get to it.

It's no magic bullet for sure, the services behind the open parts of the firewall have to be secure or it does no good, but it restricts the possible places an attack can occur.

Seems overkill...

[MrDomino]

The post proposes a pretty novel solution---maintain separate hosts for each server---but it seems really inefficient. I mean, Xen as I understand it will run full operating systems in each of its virtual domains, including separate kernels and whatever else the system needs running.

Why not just work with chroot jails? They accomplish the same thing---keeping things isolated from dangerous interaction with the rest of the system---but without the ridiculous performance overhead of running entire and discrete systems for each service provided.

Re:Seems overkill...

[Master of Transhuman]

You didn't read this part, did you?

"The price tag of such a hardware-intensive architecture may seem high, but virtualization software allows us to deploy all three tiers within the same server."

Re:Seems overkill...

[MrDomino]

I did, in fact, read that part. I was not, however, referring to the overhead of purchasing more machinery; Xen virtualization may not require different hardware for each service, but it does require a unique memory space for each virtual server, and that is costly in terms of system resources.

Re:Seems overkill...

[Master of Transhuman]

They SAID it was costly but less so than buying another box. Evidently they think it's less costly than trying to support perimeter security over numerous workstations rather than protecting the "meat" of the company which are the servers.

Defense in depth.

[!ramirez]

This concept can largely be summed up as 'defense in depth'. You use multiple layers to defend that which you value the most.

Saying 'I have secured my OS, I no longer need a firewall' is like saying 'I have an airbag, thus I do not need this seatbelt'. One complements the other.

Re:Defense in depth.

[Anonymous Coward]

Saying 'I have secured my OS, I no longer need a firewall' is like saying 'I have an airbag, thus I do not need this seatbelt'.

Actually, it's more like saying, "I'm running OpenBSD!" :)

Re:Defense in depth.

[drmerope]

And ironically... having airbags and not wearing a seat-belt is more deadly than just not wearing a seat-belt (because not only do you fly-forward but now you have a rapidly expanding explosion as well).

Airbags can only be used safely with seat-belts.

Re:Defense in depth.

[Master of Transhuman]

Which is not what the article is saying.

The article is saying that perimeter defense costs more than internal multiple layer defense. And a perimeter firewall is more restrictive of end user access than it needs to be.

Also the article is saying that perimeter defense leads to lax internal security.

The article is advocating firewalls between the end users and the servers, not the end users and the Net.

The points are valid, but I'd say a system based on it needs to be pen-tested to be sure it can work.

Re:Defense in depth.

[photon317]

Five years ago or so, I wrecked a 1999-model car. I was wearing my properly adjusted and tensioned seatbelt, and the car was equipped with perfectly functioning airbags. The main impact in this spinning wreck was to the passenger's side rear corner of the car, almost at a 45 degree angle into said corner, but a little more from the side than from the back.

Because this is not a "typical" angle and location for a major impact (and it was major, it literally tore the rear wheel off the axle and then crumpled the subframe and floor of the car), the seatbelt completely failed to lock, and the airbag did not deploy. My head was slammed forward at an angle into the steering wheel. Luckily the top edge of my eye socket struck it, rather than my eye itself. I ended up with a fairly major concussion, short term memory loss for a few hours, and a nice scar over my eyelid.

The moral of the story is that if you want to really be safe, even the combination of an airbag and a standard seatbelt is not enough. Had I been locked into a racing harness and/or wearing a racing helment with neck-brace, the injury could have been avoided.

When it's your company on the line, and the cost of professional intrusion could be in the millions, there's almost no such thing as too many layers of security.

Re:Defense in depth.

[Anonymous Coward]

This is untrue. Airbags in the US are designed to protect a large, unbelted American male. A safer airbag standard would assume that the occupant is wearing a seat belt. IMO, anyone not wearing a seatbelt gets what they deserve.

Novell paying for article ads on slashdot or what?

[Anonymous Coward]

I hope VA Software Corporation (owners of Slashdot) got some cash for that blatant Novell advertisement.

Its always a risk/reward analysis

[Danathar]

As always the amount of security you deploy depends on the risk level you are willing take and the amount of work/money you are willing to spend.

At the organization I have we have NO firewall because it is designed as an environment for the deployment of services (videoconferencing, ect..) and users who need unrestricted network access to the outside world. The security policy is written so that the user is completely in charge of their system. If it becomes comprimised and we find out about it...it's disconnected.

Networks rarely are compromised but the edge devices ARE. With the exception of some vulnerabilities in routers of late, networks do what they are supposed to do.

It's NOT nework security....it should NOT be the job of the network to protect hosts from themselves. It's HOST security and the people in charge of the HOSTS are responsible. "Not my fault" you say? Windows is insecure? It's precisely this mindset which has isolated MS for so long and pushed the responsibility back on the network admins that have kept microsoft (and OS vendors in general) and application developers from being serious about securing their systems and applications.

They just moved the clients outside

[skybrian]

They still have a DMZ. What they actually did is moved people's laptops and personal computers outside the firewall. The servers are apparently still still locked down using "application-level" firewalls.

The idea is that people will taking their laptops home and on the road and need to be secure in those conditions. If they have to secure the clients anyway, there's no point in maintaining two different configurations and they might as well assume all clients are on a hostile network all the time.

Re:ssh

[Anonymous Coward]

man tcpd

/etc/hosts.deny:

ALL: ALL

/etc/hosts.allow:

sshd: my.ip.add.ress

Crazy.

[Aldric]

Even for servers. I don't know about anyone else, but I have services running on my server at work that I use internally that I don't want to expose to the outside world.

Re:Crazy.

[Anonymous Coward]

Indeed it is crazy for you to have those services running. Why are you doing that?

Weve been tricked...

[j_kenpo]

"Your not Stuart Berman, your really social engineering expert Kevin Mitnick, and you almost tricked everyone into taking down their firewalls".

"And I would have gotten away with it if it wasn't for you nosey Slashdotters!"

Re:Weve been tricked...

[QuietLagoon]

Hey, be nice to the guy, he's one of InfoWorld's Top 25 CTOs for 2005...

Re:Weve been tricked...

[Anonymous Coward]

Your not Stuart Berman, your really social engineering expert Kevin Mitnick

And you can't spell. The word (contraction) you're looking for is "you're", the contraction form of "you are", not the posessive "your".

Here's a little tip to help keep these straight in the future: You're obviously choosing words based on how you pronounce them, and not their actual meaning. Thus, if you'd pronounce words correctly you would have fewer problems. In this case, the word you used, "your", is pronounced like "yore". The word you meant to use, "you're", is pronounced like "you-err", where the "you" is distinct. By pronouncing "you're" as "you-err", you'll never write it as "your" again because they no longer sound the same.

Other examples:

• "[sh|c|w]ould've" and "[sh|c|w]ould of". The first is pronounced "should-ehv" (short e sound), while the second (incorrect) phrase is pronounced "should uhv" (short u sound).
• "are" and "our". The first is pronounced "arr", while the second is closer to "hour" (oww-err).

Re:Weve been tricked...

[Anonymous Coward]

Just wait until Xenu and Xena catch up with him.

Re:Weve been tricked...

[stuart_berman]

First I am Kevin Mitnick, then the 'other' Stuart Berman...

What's a simple network engineer to do?

I don't run a firewall

[KidSock]

I only run essential services - ssh, http, https, and secure imap. That's it. If you don't have any other services on the inet interfaces you don't need a firewall at all.

Re:I don't run a firewall

[Anonymous Coward]

You're a fucking retard.

Re:I don't run a firewall

[ravenspear]

That is a rather bold statement. Have any evidence to back it up?

I can think of a few instances where you would still be vulnerable without a firewall, like if there was an exploit discovered in the network stack of the OS.

Re:I don't run a firewall

[smash]

So when something like, oh... I don't know... this happens, or perhaps this happens, you're screwed, right? :)

smash.

Re:I don't run a firewall

[KidSock]

So how would a firewall help protect you against exploits in services that you allow through the firewall?

Re:I don't run a firewall

[KidSock]

Have any evidence to back it up?

How about the fact that I've been running a site that get's 2GB of traffic a month for 3 years?

If there's an exploit in the network stack of the OS how would a firewall help if I need to allow some traffic through?

Re:I don't run a firewall

[smash]

You let ssh in from anywhere?

Oh, ok. :D

Granted, apache may not have been the best example though...

smash.

At the risk of being redundant

[davidwr]

As others have already said, "why not do both"?

Without a firewall to block incoming-random-port traffic, client machines are still vulnerable to day-zero open-port vulnerabilities. Granted, a software firewall SHOULD prevent this but a second, independent firewall helps.

What this guy is doing is A Very Good Thing, but there's no need to turn off those external firewalls completely.

My rating of the original article:
Informative, but overstated.

Re:At the risk of being redundant

[Anonymous Coward]

Firewalls are also very important for blocking outgoing traffic. Lets say you have a worm that calls home over IRC. If you have the IRC port blocked, and worm is not smart enough to find another way, you have stopped your machine from being controlled.

ACL == packet filter firewall dork

[Anonymous Coward]

"This begins with separating our servers from our clients. We can do that now, thanks to layer-3 data center switches that allow for the low-cost creation of subnets. By defining simple ACLs, we further isolate our backend servers."

Oh so they elimiated their firewalls to go back a few generations and implement packet filter firewall.oops I mean access lists, I mean oh hell its still a firewall just implmeneted in adifferent piece of equipment.

while I agree the border is going away and information and its integrity has to stand alone, he didn't write it very well by saying lets just do packet filtering..haha

What's got me chained to my firewall...

[Anonymous Coward]

> What has you chained to your firewall?

The fact that I can't rely on a program to so much as accept a name and password without risk of a buffer overflow exploit?

Too smart for their own good

[lheal]

As a previous poster said, why not do both?

They've taken a nugget of insight, that the reliance on a firewall can make you sloppy, and built a whole mountain of security policy on it. Trouble is, that's upside down architecture.

Good security is about building up as many layers as you can that are easier on you than on your attacker. The goal isn't to be impenetrable, it's to look like too much work so the attacker goes away.

We have a firewall so that we CAN be a little sloppy inside if needed. It's the balance between security and usability. It doesn't mean you rely solely on the firewall. It means that the "firewall", which you should treat more like a window screen, is just another layer of defense.

And when everyone else has a firewall, your unfirewalled network stands out like a house with no window screens.

There is another big picture here, too. If everyone has a firewall, having one doesn't make you look like you've got something to hide. If only 1% of networks were protected, then your firewall makes you look suspicious.

So thanks, but quit telling people they shouldn't use a firewall. Some of them might take your advice.

Re:Too smart for their own good

[poopdeville]

We have a firewall so that we CAN be a little sloppy inside if needed. It's the balance between security and usability.

If you find yourself being sloppy because you have a firewall installed, I suggest you re-evaluate your security model. Evaluate the points you're slacking on and figure out if you really need that layer of defense. If you don't, get rid of it -- it's clearly an inconvenience. If you do, stop using the firewall as a crutch. It will fail at some point, and your lapse will bite you in the ass.

Re:Too smart for their own good

[Anonymous Coward]

Fucking numbnuts! You like being a "little sloppy" inside your network? Sounds like a good thing you're operating from your bedroom and have nothing to do with security at any real business!!

Re:Too smart for their own good

[Anonymous Coward]

If the firewall is another easy layer of protection, they why not use it?

It only takes one slip-up or accidental oversight. This could be 10 minutes while in the middle of configuring software, or it could be a remote exploit in services that are only used internally. In either case, having strict firewall rules will act as a safeguard until the problem can be fixed properly.

stop using the firewall as a crutch. It will fail at some point, and your lapse will bite you in the ass.

So you see the firewall failing as inevitable - but can't fathom the possiblity of the server security itself ever being breached? What is wrong with this picture?

Re:Too smart for their own good

[poopdeville]

If the firewall is another easy layer of protection, they why not use it?

I didn't say that he shouldn't use a firewall. I said that his internal security procedures shouldn't depend on a firewall. There's a difference.

Imagine this scenario. A fortress has an inner wall and an outer wall. But the inner wall will fail if the outer wall is breached. It effectively only has one wall. There are two ways to harden this: you can either make the outer wall very strong, or you can make it so the inner wall doesn't depend on the outer wall, so that you actually have two independent layers of security.

My suggestion was that if you finds yourself slacking with regards to security procedures, you've effectively eliminated the inner wall. If the outer wall is breached, so is the inner one, by virtue of the fact that you're slacking. If the benefits of slacking (with respect to productivity, convenience, etc.) are sufficient, you should just harden the firewall and ditch the internal security processes. If maintaining security is a serious issue, you should do your damn job and implement the security processes. The fact that you have a firewall is no excuse for being sloppy, and sloppiness will bite you in the ass when the firewall fails.

So you see the firewall failing as inevitable - but can't fathom the possiblity of the server security itself ever being breached? What is wrong with this picture?

Your understanding of what I wrote.

Re:Too smart for their own good

[tftp]

In other news, it is OK to point a handgun at your head and pull the trigger, as long as you know that the weapon is not loaded.

Dr. Who: "What could possibly go wrong?"

Re:Too smart for their own good

[Nonesuch]

My suggestion was that if you finds yourself slacking with regards to security procedures, you've effectively eliminated the inner wall. If the outer wall is breached, so is the inner one, by virtue of the fact that you're slacking. If the benefits of slacking (with respect to productivity, convenience, etc.) are sufficient, you should just harden the firewall and ditch the internal security processes. If maintaining security is a serious issue, you should do your damn job and implement the security processes. The fact that you have a firewall is no excuse for being sloppy, and sloppiness will bite you in the ass when the firewall fails.

That sounds great, but doesn't reflect the reality in large corporations.

One team runs the big honking edge firewalls, and takes their job seriously. They regularly strengthen the walls, and comission tiger-team testing to verify the belief that the perimeter walls are as secure as they can be for the budget available.

Another team (or six teams, or sixteen teams) run the various internal networks and servers and desktops. These are the ones who will start slacking off because "we have a firewall", and getting sloppy in locking down the internal devices.

Sure, the perimeter team can rant and rave about how while their firewall is great, it is not a panacea and the internal groups need to take up their share of the load, but this is little more than a CLM.

Re:Too smart for their own good

[poopdeville]

It's a shame, really, that you're right. Your post has given me a great idea for a book. You're going in the acknowledgements.

This is better?

[Transcendent]

Meanwhile, the clients sit in the clear. We protect them by boosting their immunity levels so that they can exist in harsher conditions. They run secure OSs, fully patched with current anti-virus protection. We assign each user a central identity, which is authenticated and validated before accessing the internal DMZ. We use central directories to manage identity privileges and PKI certificates. Existing systems, such as Active Directory, allow for low-cost private certificate authorities where PKI isn't well-established. We also log and monitor the activity and enforce acceptable application behavior.

Sounds like a pain in the ass to me...

Frankly, there's too many damn buzzwords.

Why Choose?

[Doc Ruby]

Do both. Eliminating their firewall was just the motivation to do more comprehensive security work. That motivation should come from IT management, and self-interest in preparing a manageable system, rather than fighting fires. Every insecure part of a system should be secured. A firewall has a unique role in providing a good amount of cover for an entire organization for its cost. Especially valuable when making changes to security configurations, which might temporarily expose resources in the transition.

Re:Why Choose?

[mabhatter654]

you hit one thing this guy is trying to stop. As long as you're relying on external firewalls instead of internal security, you'll always be in "firefighting" mode!!! A vendor or subcontractor, VP or engineer is ALWAYS going to be comming in your office with a hot project that's holding up the whole company and "internet security" is the lowest thing on their list of hazards. They're worried about not getting an order out on last minute notice.. not wether they just left the "barn door" open and all the horses are out. Most business types think of security as a social issue... "people should just do right" that's not always possible... the education in computing alone is enormous.. that's why they have us! They tend to want to punish minor infractions severely rather than spend time diciplining the business processes to build in security.

One good thing for the IT industry is the big push for all things SOX... my company is being audited right now and we're finding so many holes in accounting practice and internal apps it's enough to make your head spin.. and that's what the authorized users can do!!! I think with SOX that the idea of multi-tiered, paranoid internal networks are going to become the norm real soon now. Just the access to sensitive information that people in the same department shouldn't be having.. i.e. purchasing and recieving.. at medium sized companies those are often office mates!!! let alone the bigger issues of an outsider knowing such holes exist. If anything IT has relied far too long on the good will and honesty of the "geeks". When you see how much power "geeks" have in most companies it's truely staggering that more companies don't have trouble with IT staff hurting them.

Re:Why Choose?

[Doc Ruby]

I learned security practice building multimillion dollar infosystems for multibillion dollar financial businesses, in NYC and Toronto. In that game, you never know exactly what is going on, so you're always off into paranoia or denial. Denial gets you killed; paranoia only gets you a bigger budget. We go with paranoia.

Multiple layers

[Digital Pizza]

OK, I haven't read the article (I'm on Slashdot, after all), so maybe I misunderstood the article post (they are often misleading). What the hell is wrong with having multiple layers of security? That's what's been preached for years now, and it makes sense,

Of course one should strive for having one's servers secure enough to stand on their own in case someone breaks through the firewall, and also because attacks can come from within. You don't need to remove your firewall to do that, however; use your imagination! What happenes if there's a flaw in the server's built in security? Bugs have been known to happen. Paranoia becomes a wonderful trait when you're dealing with network securiity.

So a firewall is that much extra work; boo hoo!

Re:Multiple layers

[plierhead]

OK, I haven't read the article (I'm on Slashdot, after all), so maybe I misunderstood the article post (they are often misleading). What the hell is wrong with having multiple layers of security? That's what's been preached for years now, and it makes sense,

Nothing wrong with it. However this guy's point (I think) is that human nature, and particularly that of less tech-savvy PHBs, is that "we HAVE a firewall, therefore we are secured".

I agree with this sentiment. Lots of people (most in my experience) put their faith in something like a firewall that can never fully secure your network, and neglect other things. Most of what this guy says is not innovative - having multiple levels of DMZ, etc. But ehre are plenty of idiots out there who don't do these sensible things because "its OK, we have a FIREWALL!!!!".

By forcing the mindset of "assume we don't have a perimeter firewall - now how do we secure things" he has introduced some good security practices to his organization. Of course he has then sensationalized it in order to get his article read.

The best thing would be to return, after this, and then slap the perimeter firewall back on. Of course soon people would resume their lazy ways and the problemn would recur.

Re:Multiple layers

[Digital Pizza]

OK, I think we're in agreement! As I stated, I didn't read the (sensationalized) article, but it did sound like this guy was advocating the elimination of firewalls altogether and forever, which would be stupid.

My own approach has been as you said, pretend you don't have a firewall when setting up your servers. Anyone who does otherwise (in a business environment at least) deserves what they get. I wouldn't take down my firewall either though, even for testing because bugs happen, in servers and in firewalls. Maybe I have a better imagination than most, but I have no problem pretending that the firewall isn't there and acting accordingly. Or maybe it's my paranoid nature. :)

This sounds like another one of those "nothing to see here, move along" articles.

security about layers

[atarione]

I applaud these people for trying to limit the vunerablity of there systems and for all, but my understanding is the more layers of security you have the better off you are. updated servers/systems/applications security policies auditing firewalls if one thing breaksdown (patch gets delayed being deployed) i'd rather have something to serve as a 2nd line of defense than not?

Life without firewalls according to Abe Singer

[Helevius]

Here's Abe Singer's ;login: article on Life Without Firewalls... and how he learned he was Tempting Fate by advertising the fact. Both are .pdf's, but the second requires a USENIX membership until February '06. Essentially he says he was right to operate an enterprise without firewalls, even though he was compromised.

Helevius

No need for firewalls anymore

[Anonymous Coward]

If you run only secure services(latest versions/patches) as you should there is no need for firewalls anymore. Firewalls create only unnecessary overhead and latencies.

IP address wastage

[whoever57]

Unless we all move to IPv6, his proposal cannot be widely implemented, since it appears to do away with NAT and hence all "clients" must have their own routable IP address.

Re:IP address wastage

[Anonymous Coward]

NAT != firewall

What is a firewall anyways?

[Anonymous Coward]

Umm, a firewall is a set of security policies and a set of systems and procedures to implement those security policies. Where did it say that a network perimeter firewall is the be-all and end-all? Where did it say that each set had only one non-null member? Did I miss that?

Petition to tear down your firewalls!

[Ingolfke]

I am starting a petition to tear down your firewalls all across the Internet. Please join us as we liberate these captive servers and spread security best practices all across the Internet.

Post a child-post to this post listing your Slashdot user-id and the subnet that your firewall has been removed from so that we can validate that you have indeed joined the revolution.

Ingolfke - 172.16.56.0/24

--
Bot-net for sale. Contact me.

Re:Petition to tear down your firewalls!

[Anonymous Coward]

flippin' idgit - 127.63.30.0/24

Let's see how many people try to correct me vs connect me. I am always amazed at how many people instantly get the obvious, but not the above.

Re:Petition to tear down your firewalls!

[smash]

Scared to post your public, internet visible IP?

smash.

PR?

[ricochet81]

that is blatantly an advertizement. Xen's PR person must be crying in happiness. Shame on you slash

heh brings me back

[william_w_bush]

when i first heard about firewalls a decade ago i thought "heh, thats a cool name for a lazy hack". the need for firewalls comes from the crazy overdesign of operating systems. seriously, how many people use the rpc or dcom functions of windows? or use linux rpc for much more than nfs?

for me, a gentoo box that hasn't been around or played with long enough to have servers i don't remember running on it is easily safe enough to put up naked on the net. true, i will echo icmp and a few other in-kernel protocols, but how many script kiddies (and really thats what most of us are hiding from, maybe enterprises have targetted attacks, or that geek whose sister you hit on) will go any farther than "sh apache_vuln_109123_kit.sh" and sit back?

btw, if you are being cased by people who targetted you, this strategy won't cover you that well, but neither will a half-assed firewall.

the word "firewall" really sounds cool if you don't know what it means, but it's a lot smarter to just not bind insecure servers to your outbound interface. a firewall is basically saying "i have no clue whats running on this box, so ill just stop everything", which is fine, but for a serious production server thats not the right attitude to have.

for windows, or a specialized application that's hard to secure and/or uses a few ports, yeah it's the right solution. theoretically you could probably disable all the stupid services in windows to make a bulletproof box, but you'd still have patches and 0-day vulns to deal with.

do have to give this guy credit for the xenSE angle. someday when lizards rule the earth from their giant underground caves, and the mach kernel is usable natively for an os (i know osx, but thats more a hack), maybe we can have that kind of security in all computers without having to partition it into 5 different run-time images. i tend to say things like that about every 5 years, before i give up and get drunk instead.

ps. someone should make a process audit call that allows you to restrict userspace processes to given interfaces or bind addresses, so those little apps that are written to bind to ANY_ADDRESS are forced to a programmed one instead. even a post-fork, pre-exec type call would be nice, so all shell children are restricted. you could even have outbound servers running on one intf, and other people using firefox or other clients on another interface with different routing.

Re:heh brings me back

[smash]

Just because your home/personal use gentoo machine is not targetted by anyone serious, and therefore has not been hacked, doesn't mean that no one else:

• needs NFS, telnet, and other insecure protocols to support applications required to conduct their business
• has data worth millions of dollars

smash.

No, he's just using poor firewalls..

[tji]

From TFA:

We can do that now, thanks to layer-3 data center switches that allow for the low-cost creation of subnets. By defining simple ACLs, we further isolate our backend servers.

So, in reality, he has not given up on firewalls, he has simply transitioned to a different firewall structure based on primitive firewalling. "Simple ACLs" are neither simple nor effective.

The other point is that yes, you can create all kinds of contrived security structures if that's how you want to spend all your time/resources (setting up and managing a contrived structure). But, most organizations can't afford to do that. Instead, they buy a commercial firewall, which allows a single person to manage the network controls as a small part of their job.

Also, a commercial firewall has support for a huge range of applications/protocols. The article kept mentioning the limits on applications when using a firewall. From this I would have to infer that he was using a very poor firewall solution in the past (simple router ACLs?, one-way NAT gateway?, stateless firewall?)

Re:ssh

[TeknoHog]

Good point! I was thinking of the ListenAddress option of sshd to accomplish the same thing. Some other daemons have similar options, right now distcc comes to mind.

I admit that the hosts.files are much better in general, but I guess you could use both methods for an extra layer of security.

Why have a hardware firewall?

[Anonymous Coward]

iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A INPUT -j ACCEPT -i lo
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT --dport 22

Problems

[cynic10508]

assigning them to a three tiered system of security levels

I'm curious what the justification for a 3-tier system is. Why not 2 or 4? If it's arbitrary then it may be worse than what they're trying to fix.

The cost of the added servers is greatly minimized by making them virtual servers on the same machine

But then an attack on one virtual server for a particular functionality takes out all other virtual servers on that machine? How does this fix anything?

With the new security-enhanced XenSE, this might become easier and more possible.

If I had a dollar for every time I've read about a new OS that is "vastly more secure" than anything else... and it still gets hacked.

What has you chained to your firewall?

How about the ability to control, monitor, and filter traffic through an external border point? And isn't most DOS-resiliant software written for the firewall-type application?

Re:Problems

[Anonymous Coward]

I'm curious what the justification for a 3-tier system is. Why not 2 or 4?

A three-tier system has more buzzword strength than a two- or a four-tier system. It was all the rage at Infoworld, et. al., a few years ago. As far as I know, two- and four-tier systems have been on the hit parade at all.

Its a matter of scalability AND responsibility

[Anonymous Coward]

Not replying to the article as much as the original poster...
My personal system, which I and only I manage, does quite well w/o a firewall. I built it, I hardened it, I only run those services that I need, and I am the only one who could do something stupid to it. I am on it daily, and KNOW what is and isn't going on with it.
My corporate systems (250+ Windows, Linux, and Solaris servers providing various services to the Internet, with over a 100 various 3rd party VPN or leased line connections from customers, vendors, etc, with six different T3 Internet pipes) are managed by various people, from geniuses to newbs whose grasp of English comes from reruns of Friends! I can dicate what is to be done/not done on my environment, but not the customers' or vendors. Sure, I can ask, but I cannot enforce. I cannot keep anyone from doing something stupid to the servers, I cannot personally verify the configs/revisions/patch levels/etc., so I use multiple PIX 535s at each connection point to make sure that even if they DO do something stupid like turn on anonymous FTP with write, I don't get a 4am phone call wondering where all the disk space went, or a Cease and Desist from the RIAA. Does that make me invulnerable? Hell NO! (hence, I am posting as A/C since I don't want to invite problems ;-) But it sure limits the amount of work I personally have to do, compartmentalises my systems, and allows me to sleep at night.

security wants redundancy

[wotevah]

Before everyone starts posting "I've been doing that for ten years" and "of course, firewalls are teh suk", let me say that while TFA does make some good points (about "perceived safety" of firewalls), I still do not see any way that its conclusion would be correct.

First off, redundancy in security is good. You want multiple layers of security. It does not make sense to remove a layer just because you installed a different (non-overlapping) mechanism in place.

Second, firewalls are a policy enforcement mechanism, and a single point of control. Under stress it is much easier to control access from a firewall than the eclectic mix of machines behind it. The point needs to be made that while securing each machine is a good idea, that should not be done to replace the firewall.

Visible services can't be assumed to be bulletproof. Compromising the frontend machines can result in them becoming rogue agents (DDOS and whatnot). Firewalls attempt to mitigate this risk by blocking outgoing access and thus rendering the network less useful to the attacker. Without a firewall, well...

The network of machines is secure today, after a lot of careful design work. Is it stable ? Will it still be secure after the next site upgrade ?

While more complex systems can occasionally be more secure by their inherent obfuscation, verifying such systems from the inside is also difficult, but manageable given the manpower. When the security components are mutable though (they are OS services and custom software which are upgraded often), the complexity of the system works against us, making it that much harder to verify that all the combinations still result in a secure system. Not to mention that the machine verification involves application-level checking which is either laborious or impossible for the network admin to do.

From TFA: Meanwhile, the clients sit in the clear. We protect them by boosting their immunity levels so that they can exist in harsher conditions. They run secure OSs, fully patched with current anti-virus protection.

So our definition of a secure OS is Windows (what other OS needs to have "current anti-virus protection"). That sure explains a lot. I suppose those machines wouldn't happen to have the firewall enabled, would they ?

Firewalls confusion for script kiddies.

[future assassin]

I have a windows 2000/apache server on my cable connection which is behind a IPCop firewall. One day some retard from Infection Group used an exploit in phpbb to change the index page on my board. What this retard did was post this onto a hacked website db and stated that the "owned" box was running Linux (eh refering to the IPCop box)

Yea, I don't get it.

[cbreaker]

His "new way of thinking" isn't new at all. Many large corporate networks are set up the same way - you have clients on one segment/group, servers on another, and Internet-accessable on another. You filter between the networks.

Not sure how he can say they "gave up" the firewalls - if it's a router doing filtering or a special "application firewall" (whatever the difference is) it's still doing *firewalling* and thus still needs to be managed.

He never really mentioned that they removed any firewalls, really. There's going to be packet filtering for the client machines, be it in the form of NAT or whatever. I'm sure they don't want people using Bittorrent all day, so they're going to lock it down. And that requires firewalls.

You can pretend that your firewall isn't a firewall but if it's blocking packets, it's one.

Layering is always good..

[TheHawke]

Think cake and you'll understand. A 3 layer cake is always better than one.
Never let oneself get tricked into thinking that one big layer of defense will keep them out. The French frogs built the Maginot Line and look where it got them.
The best defense is not showing the world that you have the systems in the first place. Hostmasking, IP shrouding, wrecking the IP tables to the point where a hacker only winds up either getting rerouted or dev/null.

The 2nd layer is securing the LAN. Standard firewalls on every system are excellent if the 1st layer is breached.

The 3rd layer is terminal access. The usual workstation security applys here. Rotating passes, biokeys, magcards, or a combination of any. One-time pads are nice too.

Keep the scriptkiddies and hackers on their toes by changing the security infrastructure around. Don't get complacent.

How good is your security? How much do you have in your budget to invest in? Keep beating the PHBs and their ilk over the head when it comes to security. Don't let them think that they are safe, for every network is like a glass house.

Re:Layering is always good..

[superpulpsicle]

While I do agree with you. I can't help but think TCP/IP in general is too old school that it needs 3 layers of cake of protection. Some future IPv# version has got to address these complexity problems.

What has you chained to your firewall?

[the_quark]

Two words: Regulatory Compliance. Thanks to standards like CISP (the Visa security standard) and SAS-70 (the accounting standard), HIPPA (the medical privacy standard), firewalls are mandated for many US businesses, even small ones.

At my last company, we didn't have a firewall on the website, because my philosophy was "I'm running port scanning to make sure 22, 80 and 443 are the only ports listening on the boxes - why should I put a firewall in front of it to only let those ports through?"

Unfortunately, now, if you don't have a firewall, you're not in compliance. It's simply a cost of doing business - the security concerns are completely irellevent.

Obviously, you should be building your networks so they would work without firewalls - that's a lot more secure. But, unfortunately, you can't just throw the firewalls out even if you don't need them.

So what's the big deal

[ScrewMaster]

with having to maintain a firewall? I don't really see why that's such a chore that it's worth the risk of eliminating. Sure, it's only perimeter defense, but depending upon an operating system to defend itself from outside attack just seems risky. The more layers a cracker has to peel back to get at the juicy insides of your server the better.

Uh-huh...

[constantnormal]

Change is Good... ... You go first.

The best thing about firewalls....

[Anonymous Coward]

... is that you can tunnel *anything* through them; usually through port 80, but often through other ports instead.

That makes a firewall very convenient for getting stuff done at work like important applications named "kazaa", "napster", and various pr0n downloaders, etc when the IT staff decides that firewalls are the approach your company is taking to provide "security".

If these admins didn't rely so much on such firewalls, I'd have to do my kazaa & pr0n browsing from home or something.

Re:The best thing about firewalls....

[stuart_berman]

This is fairly true in a typical packet filtering firewall. Application proxy firewalls were supposed to be more protocol aware - but the dirty little industry secret is that most application proxies were never developed and it is easy enough to tunnel any protocol inside a 'real' http packet.

Re:The best thing about firewalls....

[Lord Kestrel]

The band-aid to that is to only allow outbound authenticated http/https. This makes it difficult enough to deter most users, the very few who do know how to tunnel traffic are an acceptable risk.

Not real bright...

[Percy_Blakeney]

He probably doesn't believe in parachutes, condoms, or car insurance, either.

Re:Not real bright...

[Anonymous Coward]

Your an idiot :p

Firewalls do nothing useful whatsoever
(Except protecting idiots against themselfs)

No really they DO NOTHING useful

Look I'm not kidding here, get that idea you got from watching the movies out of your head

I admit there are firewalls with "bonus features" which do, do something however they can all be got seperately without the useless piece of junk.

How exactly are ACLs on a switch different?

[Anonymous Coward]

This guy doesn't like the idea of a firewall being a "security device" so he's building his own, which is the right thing to do and once you do that, a firewall is a nice and ideal addition to the mix.

He almost learned an important lesson, layered security is the solution, multiple tools and mechanisms are the solution. Instead, somehow he's managed to bastardize the whole thing and now he's encouraging stupidity. Any chance he'll stake his career on this network's security? I'm better he won't even stand behind it.

Re:How exactly are ACLs on a switch different?

[gambler2073]

This is how I see the difference...Where a router ACL filters ip address and ports, a firewall can do much more i.e. they inspect application layers for RFC compliance/attack patterns, authenticate users, and log permitted & denied traffic (its nice to know who's trying to screw your systems after all...) Find a router that can do all this across more than 100 ACL entries and then maintain a decent level of performance then your laughing, but only the modern high kit is starting to get close. If ACL's in routers were efficient then surely Cisco wouldn't produce a firewall blade for their high end routers.

I've been working in the network security field for most of my career and advocate the layered/defence in depth approach, but I suggest anyone relying on router ACL's consider their requirements first. Personally I prefer firewalls on the edge of the network with lots of application layer filtering (i.e. proxies, SMTP scanning etc) to keep all the nasty stuff away, and simple (to keep maintenance easy and processing overhead low)ACL's for any internal segregation. Naturally I look at host based security as well, but that's for another post in the future.

Re:How exactly are ACLs on a switch different?

[Anonymous Coward]

First off, an ACL is a firewall. You're thinking of stateful inspection, protocol validation, proxying, etc. These are all common in so-called 'firewall' devices. Many routers support stateful inspection and logging of permitted and denied traffic. I have ran many ACLs with several hundred ACEs on low-end routers, your thinking isn't correct. The FWSM's goal isn't to fix the problem of slow ACLs, but to allow better handling of data and to offset the firewall processing to a seperate module. Similar to an AIM module. The FWSM allows you to create virtual physical firewalls which adds more flexability into how you deploy ACLs, stateful inspection, etc.

Seems somewhat questionable..

[EMIce]

So his network clients can be port scanned, but the servers are in a DMZ that must be authenticated into. The advantage is that a user can now run all kinds of specialized apps that need open ports, and the admin can avoid micromanaging regulations based on specific client needs, but it opens a whole other can of worms.

Maintaining a 100% secure client OS and specialized applications aside, if a user were to download a malicious program or visit a malicious page with a new IE exploit, couldn't his authenticated computer act as a gateway to the DMZ portions? But I guess this would happen in the case of a firewall anyway.

Now the thing is if the user takes advantage of this and starts running applications that open ports, he no longer has to be lured into running a malicious program, he just needs to be running an exploitable program. It seems that this would make it easier for an attacker to compromise a pre-determined target, simply by scanning around rather than luring an actual person.

Of course the upside would be simplified management, because certain applications that were considered too "fast and loose" before are now ok. But systems aren't so secure that once you pry into even a lower privileged client, that you won't be able to somehow escalate those privileges and access the DMZ server farm. As soon as you break into a client, local exploits come into the playbook, and it only gets easier at that point, unless your local OS and internal network authentication are uncrackable.

That would be a tall claim, as any user input into the network authentication system can be recorded and played back via a locally compromised OS. From there, authenticate into the DMZ and look for local server exploits. Am I missing something?

I realize he is weighing the risks and benefits, but the risks here seem too high, especially with users allowed to run network applications that take inbound connections. Any compromise there could open the machine and network to the world of local exploits.

Does SANE support the Scanmaker 4850 yet?

[tepples]

And if you have processes running and listening on ports that you don't want or need, why are you running them?

Because the operating system that you run is incapable of turning them off, and no other operating system is compatible with a mission-critical application or hardware device?

Re:Does SANE support the Scanmaker 4850 yet?

[jacksonj04]

Oh for mod points.

Also, firewalls are good for if you have networks which need to do a lot of internal talking on potentially hazardous ports, but don't want the rest of the world to talk on those ports. Think big application platforms.

Re:Does SANE support the Scanmaker 4850 yet?

[Nutria]

And if you have processes running and listening on ports that you don't want or need, why are you running them?
Because the operating system that you run is incapable of turning them off, and no other operating system is compatible with a mission-critical application or hardware device?

X Windows uses the 6000ish ports.

Are you telling me that I should not run X Windows?

Re:Does SANE support the Scanmaker 4850 yet?

[tepples]

X Windows uses the 6000ish ports.

There is no "X Windows". There is "X Window System" or "X11" which mean the same thing in practice.

Are you telling me that I should not run X Window[ System]?

If possible, you should configure your X11 server to listen only on localhost or through an authenticated channel such as an SSH tunnel.

Re:Does SANE support the Scanmaker 4850 yet?

[Kent Recal]

Think big application platforms.

Those usually talk on a separate network that is not connected to the internet.
If they don't (and rely on a firewall) then they deserve what they get.

Re:Does SANE support the Scanmaker 4850 yet?

[jacksonj04]

I know they're not directly connected to the net, but firewalls on the edge of their network are a good way of ensuring that the application network can talk freely (well, as much as it needs to) without the bits it's connected to being able to inject malicious packets.

Re:Does SANE support the Scanmaker 4850 yet?

[m50d]

As a stopgap perhaps, but you really need to get out of that situation as quickly as possible. A firewall is not a long-term solution in that situation.

Re:Does SANE support the Scanmaker 4850 yet?

[m50d]

No, but if you don't need network access you should tell it to only listen on unix domain sockets and not public tcp. If you do need network access, you don't want to firewall it off.

To answer the question...

[SmoothTom]

...that was asked "...What has you chained to your firewall?"

I'd just like to say:

I'm chained to my firewall because I'm not running a server farm, but a simple LAN for my desktop and my WiFi laptop here at home, while trying to keep the code-kiddies out of my hair.

I'll keep my firewalls, thankyouverymuch!

--
Tomas

Address translation

[tepples]

But the port is already closed, so the firewall's just a waste of processing power and/or money

A firewall often provides network address translation, reducing the number of machines that are visible at all to the outside world.

Re:Address translation

[JamesTRexx]

Not only that, the firewall I use doesn't only do NAT for the machines inside, but it seperates my network into the regular internal network, DMZ, and the wireless network, making sure traffic like http, smtp, ftp goes from the outside to the right server inside, but also keeps unwanted traffic going from one internal network to the other.
If you only have one public ip address but more than one (virtual) server, you need a firewall or router.

Re:Address translation

[m50d]

Why is their visibility a problem? If they are running services that you want accessible, they need to be visible. If you don't want people to access the services, turn them off, then the machines aren't vulnerable.

I am sparticus

[william_w_bush]

Hear, Hear!

192.168.42.0/24.

if you really want to check my root password is "hotdog"

Let my packets go!!!

This is common in DoD

[Anonymous Coward]

This type of network layout (defense in depth, rather than perimeter) is quite common in military (DoD) networks. Outside connections must terminate in an untrusted zone (ie on a webserver), firewall rules allow specific systems in untrust (like webserver) to talk to specific systems in semi-trust (ie app servers), and seperate firewalls allow specific systems (ie app servers) in semi-trust to talk specific systems (ie database servers) in trusted. Seperate firewalls between each zone (usually of different manufacturers, to limit vulnerability) provide high security and mean we don't rely on any 'ring' of security.

Re:This is common in DoD

[Anonymous Coward]

This is NOT a common DoD style network. Defense in depth starts at the perimiter. Thats why DoD web / email servers are unprotected and anyone can see them?

What has me chained to my firewall?

[Luscious868]

Microsoft Windows ....

All the things they do to NOT use a firewall

[Anonymous Coward]

But education of the end user in better security practices aren't one of them...these people are not doing something smart..they've just figured out another way to do it and frankly I think it's the wrong way...You have multiple app level firwalls, PKI, AD, the internal DMZ..oook....all this rather than keeping things patched and using a single point of configuration in addition to that stuff is easier my byte.

Can you really do this?

[Sloppy]

It seems to me that there's one really obvious non-security-related problem with not having a perimeter firewall: until you switch to using IP6 for everything, don't you pretty much need NAT?

So once you get yourself a box to do NAT, then you've got 95% of your firewall already built. Just start tweaking it a little to deal with the stuff that you want to be able to come in, maybe add another interface if you want a DMZ, etc.

What I can agree on, though, is that you shouldn't be spending much time or money on a firewall -- a firewall shouldn't be a big deal. If you're spending serious money on it, then some vendor has conned you.

Greatly minimized?

[WombatDeath]

Sounds like overkill to me. I prefer to just minimize things a little bit.

Only linsux users use firewalls

[Anonymous Coward]

Because their crappy zealot code is so damn shitty. Like linsux? Eat a dick for torvalds!

I'll tell ya what I gots chained to my firewall.

[Stankatz]

What has you chained to your firewall?"

I ain't chained nothin' to my firewall. That would be a fire hazard.

Odd

[joey.dale]

This has to be the first article I have seen in which advocates more overhead and fewer levels of security. If anything way make a network LESS security. A firewall makes a machine less visible to the outside (thats a good think), and MORE likely for a script kiddie to skip over in favor of an easier target.

-Joey

Nice advertisment.

[Jaysyn]

Nice advertisment.

Hear hear!

[PhotoGuy]

I've argued for ages, often on deaf ears, that firewalls should be unnecessary; they really are just hacks to dodge around buggy TCP/IP implementations or configurations. Get the stack solid, and allow it to be configured properly and easily, and a firewall is moot. I'd love for these to be some ancient mythology that I tell my grandchildren about...

Re:Hear hear!

[PhotoGuy]

It's also a bit like the anti-virus world; anti-virus software isn't big on the Mac (is there even any?), because the system was designed right, and coded in a more solid fashion, than Windows.

With proper OS design/implementation/configuration, anti-virus software should be irrelevant; with proper TCP/IP design/implementation/configuration, firewalls should be irrelevant.

Re:Hear hear!

[smash]

*should* be yes.

In reality, software is buggy. "So i'll just go open source then, and fix it myself" you say...

Good luck. There's still plenty of holes in Linux, the BSDs, etc found every year.... and thats not even taking into account configuration errors.

I think of it like this: In theory, seat belts and airbags on your car should not be required, because people should be able to drive, your brakes should work, and your car should be 100% reliable. In reality, that just doesn't happen.

smash.

I'm not

[Anonymous Coward]

I don't think I've used a firewall on anything other than RH systems for a long time; I only use it there because it's sooooo easy to setup.

I simply see them as a just in case I turn on some service I didn't really want; and it keeps other people from turning on services I didn't really want (usually).

Here is why this is worthless...

[Anonymous Coward]

The servers and their respective applications sit in their own DMZ, protected by an Application-layer firewall. We organize servers into three tiers: The first tier consists of presentation servers such as Web and e-mail servers--these are the only servers accessible to end users. The second tier, made up of application and middleware servers, is in turn only accessible to the presentation servers. Finally, the third tier, consisting of the database servers, is only accessible to the application and middleware servers.

Right.. so I own your webservers with an exploit like I've been doing for years...then I tunnel from the webserver to your application/middleware servers.

What have you done here? NOTHING!

All through TFA he didn't once mention VLAN. That is a sign that he doesn't know a damn thing he's talking about..

Mr. Berman, tear down this wall!

[doormat]

n/t

Re:Mr. Berman, tear down this wall!

[Anonymous Coward]

Get the fuck out of here. What do you think this is, Kuro5hin?

This guy is nuts!

[Anonymous Coward]

Keeping all in the same server just makes it easier to use those good ol' 0dayz exploits. Hey, they all run the same architecture! What happened to multi-level firewalling?
With the rampant popularity of virtualization techniques, sooner or later will be found some security breach on it.
Also, having all your eggs in one basket will increase the possibility of you losing'em all, for example, hardware failure.

Firewalls offload the servers and save big bux.

[Ungrounded Lightning]

[...] firewalls are of any use only if: [your server farm has one of this set of problems]

Beg to differ.

Firewalls unload the server from spending cycles on filtering rules and memory on surviving DDoS attacks, just to name two functions.

If the servers must do their own filtering, and you have enough load that you need more than one to get everything done, offloading the filtering to a separate machine means that you need less servers. The gain is not linear, too: Keeping multiple servers synchronized (espeically those changing database state due to the transactions they serve) is an extra load, which becomes a lower fraction of the transaction cost when the server count is smaller.

Separating the functions also means that the machines can be specialized for their work - with, for instance, hardware accelleration for attack detection on the firewall - drastically cutting the box count. Putting all the eggs in a single basket means accelleartors get less usage, since they're used only for a fraction of the machines' load. Meanwhile you need more accellerators to put one on each machine - or you're stuck with using a GP machine to do the work, at much lower efficiency and a much higher box count.

Accellerators may only be available for appliance firewall solutions, not for upgrading a machine optimized for database handling or other server tasks.

If you have a license fee for the server software, having more servers means more licenses to buy. Another cost savings from specialization - this time a big one. If both the server and firewall software is licensed you have to have licenses for BOTH on ALL machines, rather than one or the other on each machine.

If you need content filtering against specific identified attacks, you need a service from a specialist organization, to track new attacks as they arise and upgrade the filtering functions. You don't want an outside house tweaking the machines which contain your own proprietary data.

Separate machines also means separate software. The firewall software can be written by people focusing JUST on secure and efficient firewalling, the server software by people focusing on efficient transaction service. Do a combined box and your firewalling functinality is just one of a bundle of functions being handled by a software team - in the server and/or the supporting system. (You only have to look at Microsoft to see the level of security produced by the latter approach.)

I could go on. But any one of the above points, by itself, shows an advantage for the separate firewall/server approach in a commercial scale, commercial grade, service. Combine them all (and others I haven't mentined) and the argument is compelling.

Re:Firewalls offload the servers and save big bux.

[KiloByte]

So, are the services provided by those servers available to the general public?

If they are, then things are already accessible from the network, and your firewall is a no-op (unless you're running additional things that shouldn't be there in the first place).

And if the public can't access those servers, then why would they be even routeable from the outside world? Make them able to talk to your internal network only.

Firewalling things only gives you a false sense of security in these cases. Having the network be physically disconnected is something that's a lot harder to break. And a firewalled service is a lot easier to break than a service that isn't running at all.

Re:Firewalls offload the servers and save big bux.

[Ungrounded Lightning]

So, are the services provided by those servers available to the general public?

Only for correctly-formed requests to the correct port in the correct protocol.

If they are, then things are already accessible from the network, and your firewall is a no-op (unless you're running additional things that shouldn't be there in the first place).

Not true. The front-end box(es) can do the following:

1) Block connection attempts to the wrong ports.

2) Proxy TCP connections through only after they hsve been connected. (The server doesn't even SEE SYN attacks.)

3) Deep-inspect the data headed toward the server, resetting the TCP connection (or for UDP, never forwarding it) if anything hostile is recognized.

4) Proxy and buffer the actual requests, making connection to the server after inspecting them (so that recognized hostile requests in TCP are also never seen by the server).

5) Load-balance among multiple servers (which can also be used to throttle-back excessive resource drains from hostile client sites.)

This way the actual servers only spend memory and crunch on the requests themselves, and only on requests that the firewalling box considers safe. With neither attempting to do the other's work, firewalls can be optimized to survive DoS attacks, servers to serve requests.

The ratio of boxes can be adjusted so you only buy enough server to handle the legitimate load and enough firewall to handle the WAN connection speed. Meanwhile, unlike the servers, the firewall machine(s)can protect a broad range of services and network functionality behind the firewall, continuing to make efficient use of their power as attack bandwith shifts among the targets.

Not an Innovator; Just a Contrarian

[sabat]

I have heard this guy propose his nonsense in person. This is a classic case of throwing the baby out of the bathwater; his proposition summarizes as "firewalls aren't a silver bullet, so they're worthless."

He proposes that we secure all individual boxes, which is umpteen times more difficult, more time-consuming, and less secure.

He's not an innovator; he's a contrarian.

Re:Not an Innovator; Just a Contrarian

[tholomyes]

I think we can all agree this isn't a brilliant approach. Contrarians, however, get more press, even if this does seem kind of like reverse-FUD.

Securing the individual boxes is *always* a good idea, and there are a million tools to help with this, like nmap/Nessus to see where the weaknesses on the network are, Cisco's Security Agent to protect at the kernel and network level of the device in question...

Throwing out the firewall is a moronic idea, however, not only because you're discarding in-depth security, but you're also losing a host of other security tools like stateful session tracking, address translation, and site-to-site VPN capability.

Re:Not an Innovator; Just a Contrarian

[pgilman]

for the record, the phrase is "throwing the baby out *with* the bathwater."

Re:Not an Innovator; Just a Contrarian

[sabat]

Just a typing mistake, man. Chill.

Re:Not an Innovator; Just a Contrarian

[stuart_berman]

No I'm not... 8p

Speaking of which...

[JamesTRexx]

Why is slahdot.org asking my webserver for "GET http://it.slashdot.org/ok.txt HTTP/1.0"? *tinfoil hat* Trying to compile a list of relaying http servers?

Re:Speaking of which...

[QuickFox]

It's checking if you're connecting through a proxy. There really should be a FAQ entry about slashdot's evil-looking port scanning!

-- Terrorism may have turned the United States into a nation of fear and aggression, but it won't succeed in Europe.

Re:Speaking of which...

[JamesTRexx]

Ah, thanks.
Silly thing to do though, I use a proxy, but it's not running on port 80 of course.

Re:Speaking of which...

[swdunlop]

To identify requests which have come through a public proxy.

Jericho Forum

[AYeomans]

Check out the Jericho Forum - a group of major companies who also recognise that the role of the network perimeter firewall is becoming less relevant and an obstacle to business demands:

The Jericho Forum is an international forum of IT customer and vendor organisations who recognize that over the next few years, as technology and business continue to align closer to an open, Internet-driven world, the current security mechanisms that protect business information will not match the increasing demands for protection of business transactions and data in the future. Existing perimeters are full of holes. The 'walls' are crumbling. Managing the problems using today's security solutions is increasingly expensive and time-consuming.

A new approach is needed, to move from the traditional network perimeter down to the individual networked servers and devices - and ultimately to the level of the data being sent over the networks. The Jericho Forum aims to drive and influence development of security solutions, based on open standards, that will meet future business needs for secure interoperation of information systems to support collaboration and commerce over open networks, within and between organisations, based on a security architecture and design approach which the Forum calls de-perimeterisation.

Next major meeting is in Sydney on September 8th - join in the debate!

Re:Jericho Forum

[stuart_berman]

They are a great example of a consortium that is trying to evolve beyond perimeter security. Not a whole lot on their web site yet - but there is a book or two published.

They recently held their first US based conference in Ohio - but unfortunately I was unable to attend. I would love to know if anyone else had the opportunity.

Network World had an article similar to this one

[front]

Howdy

The July 4th, 2005 issue had an article similar to this one:

Are firewalls expendable?

Quote from the article:

"But a growing number of security managers, united under the banner of the Jericho Forum, want to retire this stalwart because they say it hinders e-commerce."

cheers

front

Keep the firewall, but LOG!

[e9th]

A well-designed firewall will keep out the less determined bad guys.

But if you log as much as you can afford of what gets past the firewall, you'll have a chance of catching the evildoers, or at least the ability to deny that your company really wasn't willfully engaging in spam/fraud/kiddie porn/etc.

I GOT IT!!

[Halvy]

Why not JUST relax and have fun (think) like the hackers and script kids!!

Be like a KID AGAIN!!

TOOO much emphasis is being put on things that stop small attacks, while not preparing for something major like a total (or mostly total) melt down of the net (eg a terrorist event).

High crims by larger organizations and the government, are more of a threat to businesses and individuals, than the clowns we hear about all the time.

The obsession over remembering passwords which has been breed into us all, is more time consuming and frustrating, than any attacks yet.

After reading the first several comments, it became apparent that people can't even take the effort to RTFA!!

Where OH where does he claim to not use any firewalls?? Just the oposite, early in the article he clearly states that at least one is used (currently) with his little invention.

AHHHHND later on down he explains the reason for his experimenting.. and that is, that this obsession with firewalls and security in general, is more of a problem (threat, stagnation of implementing nu tec, etc) than the PUNKS out there trying to have fun.

Alternative InterNet access via shortwave (radio) over ip, WaveTop like programs (remember wavetop ;) extreme wireless nets, extreme Dns (where the masses control things more than the hand full of scum that do now) & IP6 are just a few of the possible things people should look into which will help *secure* themselvs for the crappola the *real* bad guys have in store for us poor earthlinks :)

egress filtering?

[smash]

So what does he do about egress filtering?

I don't trust *any* o/s to *never* be hacked - given that, it makes sense to make sure that *when* it is... the damage is contained...

smash.

What has me chained?

[Syberghost]

What has you chained to your firewall?

Common sense. The fact that you've implemented a layer of security doesn't eliminate the need for another layer.

Jails...

[argent]

Why not just work with chroot jails?

Indeed.

FreeBSD jails provide about the same level of isolation as virtual servers for a fraction of the cost in disk space and virtually none in performance.

This whole scheme seems like a massive step backwards... do they sell blade servers?

Dedicated perimiter firewalls

[Anonymous Coward]

Through creatively separating server functions into different, isolated servers, and assigning them to a three tiered system of security levels, his company has almost completely eliminated the need for (and headache of) network firewalls.

"Network firewalls" being dedicated perimiter firewalls. Regardless these should add security. If firewalling is a headache for someone, they are using a crappy one or do not understand the issues and should be delegating that role to somebody who does.

Getting rid of perimiter firewalls and relying on application firewalls on each host, is not going to avoid firewalling headaches. Having a firewall on each network is no different to having a single perimiter firewall, except that it adds complexity for little gain. The beauty of a dedicated perimiter firewall is that it should not be running any services and should thus be extremely difficult to exploit. Especially if it is a bridge firewall.

"Taking that crutch away has forced us to rethink our security model," Berman says.

I would not call a perimiter firewall a "crutch". We'll see if it's a crutch when an accessible service on a host is exploited, gaining administrative privs and leading to the local application firewall being turned off or configured in some way to mess you and your customers around and ease the hackers further exploits.

Not everything needs firewalls

[anticypher]

I had a client who, one day, decided to become an ISP. Just like that! Threw away some money on some big cisco routers (purchased for almost nothing from a bankrupt dot.bomb) and bought a few 1U rackmount servers. They wanted me to set them up with a few internet feeds, BGP, and whatever else it takes to make the RIPE believe they were an ISP.

So I took a couple of servers, installed OpenBSD, and set them up as DNS+NTP servers. Hooked up the ciscos and got everything running. No problems at all.

A few weeks later, the client decides to take on a "security conslutant". He knows nothing, proves it by waving around his week old MCSE, and insists on putting firewalls everywhere. Not just any firewall, but windoze2000 based firewalls. Even the ciscos had to have a Win2k firewall between them and "the evil internet" on every port. Otherwise, how could the ciscos be protected from hackers?

I walked away from the insanity, told the client he could re-hire me when the M$ certified idiot and his auto-update-is-faster-than-any-hacker machines were no longer part of the network. A few weeks later, I got the call. They were asking me to explain why they were the laughing stock of all the ISPs, and why no ISPs seemed to have firewalls in their networks.

The Internet doesn't have firewalls in it. At the far edges of the Internet, there are firewalls to protect customer networks. The routers, servers and switches that make up the Internet don't have dozens of useless services running that can allow exploits. If an ISP is just running BIND on their DNS servers, they configure the application for secure operation. Don't want the whole internet to make recursive lookups? Its a few lines in some config files. Don't want your sendmail to relay? Don't use a firewall, just clean up your configuration. Every other useless service on your servers? Strip them off so they can't run. The security is in the applications, not in the firewall.

Sure, there are some ACLs in the routers that can clean up spoofed addresses, and limit garbage and bogons. Those could be considered basic firewalls, but each router or DNS server doesn't have a separate firewall to protect it.

The internet is a lot simpler than people imagine, but it works.

the AC

Could have had a much snappier title

[SuperKendall]

"Mr. IT Professional, Tear Down this Firewall!"

Answer

[Anonymous Coward]

What has you chained to your firewall?

Windows. The 400-pound gorilla of a man with a mean disposition and the keys around his neck tends to discourage any attempts at escaping.

Oh, and he's got "I LUV M$" tattooed to his biceps too.

i just love so called security experts like this

[timmarhy]

just like everyone else seems to miss, firewalls are not just for incoming traffic, but for out going as well. security is in layers, throwing away firewalls is the most stupid idea i've heard in a long time.

Packet filtering

[Urusai]

There's plenty of "background radiation" on the 'net, your firewall can turn that down. Really, though, firewalls are just a hack, especially with all this tunnelling going on nowadays. Yeah, let's block all ports but HTTP, then tunnel every packet through HTTP. Smart move, Poindexter!

Re:Packet filtering

[m50d]

Exactly. They are, as the author says, a crutch. If your network can be hurt by that "background radiation" you've got deeper problems.

Tear down that firewall

[ScrewMaster]

because thousands of blackhats are depending upon you.

Yeah, right.

Already been done. ie. Smoothwall

[Vrejakti]

I've been using this security setup for a while now. Smoothwall has this option available to advanced users. Basically, you configure your network to have Green + Orange + Red interfaces.

The Green interface is where you connect your standard LAN router/switch.
The Red is where you connect your WAN cable.
The Orange is the DMZ your servers go on.

The Green zone has full access to both Red and Orange.
The Red zone (outside traffic) is denied by default unless requested or allowed by port forwarding rules.
The Orange zone is completely denied access to the Green zone. Therefor if someone from the Red zone hacking your servers gains root access to your servers, they will not be able to access or see any of the computers on the Green zone.

If you're very network savvy, you could set this up for free in one weekend.

my what?

[v1]

What has you chained to your firewall?"

My firewall? (Oh, do you mean my macintosh?)

Inspired...

[DavidD_CA]

Inspired by this article, I've decided to remove the lock on my front door, and instead install individual locks on my closet, entertainment center, computer desk, and fridge.

The security is great, but getting another Dew from the fridge is a bit of a bitch.

Re:Inspired...

[stuart_berman]

How about an analogy that is applicable?

You have a business (like a jewelry shop) which is open for business. How much security does that front door provide? I bet it may not even be locked. But you may have locked display cases, a separate vault, even a separate show room for qualified customers.

Unlike the store - you don't lock up your perimeter at night though - unless you change your firewall to Deny All at 5 PM - along with deprovisioning all phone lines, cutting the mains powers, etc.

Now tell me how secure the perimeter your home is even with the best door lock money can buy? (Those crazy locksmiths can get through the best in any case.) Oh wait... that is right you put bars on all of your windows and doors, you have reinforced your walls, you rekey all of the locks every few months, you search all guests before they enter your abode. Yeah, that front door lock is super effective. Criminals wouldn't dare approach your home.

Seriously - I wholly advocate personal hardware firewalls and PC based firewalls for all home users. They are so cheap and do offer a basic layer of security as well as reducing the noise of broadband connections.

"Firewall" is the wrong word in the first place

[ebvwfbw]

What a "Firewall" does in the computer industry today is a misnomer. A true firewall is designed to stop a fire and it is a very simple device. You don't drill holes into a firewall either. I think the term "firewall" is a sales gimick.

What they call a firewall is in reality at best a network filter and networks off of it are not a "dmz", that is a total misnomer as well. Firewall protected zone (fpz) would fit far better. Dmz is just plain idiotic. Could call it what it really is - Filter protected zone.

Getting rid of the network filters out there with windows around is just plain crazy. I bet they get hacked soon. What will be the first question - Did you have a firewall in front of your machines? No? - your an idiot, no your a fool, no your a foolish idiot! I hope his resume is up to date. I also hope his company doesn't have any of our personal data on their machines. If they do and he gets hacked, he would make a great example. Let's start boiling the tar, get the feathers ready.

Most Retarded Article Ever

[pavera]

Ok,
They replaced a stand-alone hardware firewall with ACLs in layer 3 switches.... Um, last time I set up a network with layer 3 ACLs it was significantly more time consuming and harder to manage than a firewall.

Further if they are using Virtualization technology and they mention each virtual server sits in a "DMZ" well, they they have to be running iptables or some other type of host based FIREWALL as there is not a physical network layer, the traffic isn't getting sent through a switch to do layer 3 ACL checking!

Next in this setup the client machines (yes often the most vulnerable and least looked after machines on any network) are left completely without network level protection, and rely on antivirus and vendor patches to be "safe". Maybe you can rely on MS to always release a patch before an exploit is released, I certainly don't.

Further, Antivirus technology is wholly flawed. What kind of protection does Norton offer you in the first 2 or 3 hours after a virus is released? It takes at least that long for them to analyze the threat and publish a new def for it, in the first 3 hours of any new large scale virus everyone on the planet who is relying on antivirus software is vulnerable.

These people are demonstrably retarded for setting their network up this way. This is certainly not the future of network security.

As long as there is Microsoft software...

[Anonymous Coward]

...there will *ALWAYS* be a need for firewalls.

It is as simple as that.

Re:As long as there is Microsoft software...

[chawly]

Correct ! Without reservation, correct ! Now let me add one. I've been working all day today (Sunday) on a LAN/WAN complex which suffered a "visitation" during the latter half of last week. I think all will be well when the employees arrive tomorrow morning. I'll be collecting a really nice hourly rate for the work I've done over the last three days. So yes ... as long as there is Microsoft software there will always be a need for firewalls .... but, as long as there are articles like this one I'm always going to be paid (and well). Please don't discourage them; I need my holidays etc. (And I deserve them, dammit ! As a bacon saver, I'm worth the money. No, really !)

What a firewall (filtering router) can do

[einhverfr]

Firewalls (in most cases filtering routers) do more than just control traffic. They monitor suspicious activity, and help prevent undue amounts of information about one's network internals from getting out.

They can also take on load-ballancing functions, and split ports on a single public IP across many servers for the isolation the article discusses.

They can also act as end-points for IPSec tunnels (VPN's to extranets etc).

In essence filtering routers can act as a powerful abstraction tool-- a sort of swiss army knife of network security. Giving up on such a powerful tool is foolish in my opinion.

Now, on the other hand, going through your network design *as if you can't put in a filtering router* and then putting one in anyway is a pretty good idea.

Of course this guy has *not* gotten rid of his firewalls. Instead, he has merely changed the setup from one based on filtering routers to one based on the structure of his DMZ (remember, a DMZ as a perimeter network acts as a sort of firewall anyway). Living without a firewall means no security boundary between your internal and external networks. If you have any sort of security boundary, such as a DMZ, that is a firewall (doesn't have to be limited to a filtering router).

Remember the firewall of a large company usually includes a DMZ and at least one filtering router (between the DMZ and internal zone). The firewall between the DMZ and the internet zone is usually considered optional. However, such a firewall if properly configured, can provide substantial protection against trojans, worms, etc. as well as early warning capabilties in case of a security breach. Wonder how this works. Would you allow your web server to make arbitrary connections to the internet? Probably not.... So if someone plants a back door, not only is the inbound port blocked at the router, but so is the outbound connection request. If both of these are logged, you will say "Why is my web server trying to connect to the IRC server at 3vi1h4ck3rz.com?" and realize pretty quickly that the server has been compromized. Can a firewall be used as a crutch? Sure. But do you *really* trust a security professional who advocates getting rid of such a useful tool?

Still don't even half way agree

[einhverfr]

Ok, so this guy is recommending using Windows Server *and* getting rid of firewalls???

I understand the dangers of hacking from the inside, but this is as prevelent as it is largely because people better recognize the danger of the large number of internet script kiddies. Based on the firewall analysis I have generally done, the internet zone is the originating area of *far* more attacks than any internal zone.

Additionally, or requirements of usability are generally higher on the internal network (we don't have to open file sharing services out to the public, do we?) so of course the network is going to be *by nature* less secure.

Yeah, but the problem is this: what if it's your firewall admin who screws up? Granted, it's better to leave a port open on ONE device than on twenty different ones, but it's still the same problem.

What about defense in depth? Has that somehow been superceded here? Ideally, your firewalls are merely layers in your defence. They are designed merely to increase the cost of a successful attack. Getting rid of the firewalls creates a more brittle network security infrastructure, where failure in any computer is by itself sufficient to do all sort of nasty things to your network (ping or syn floods being just the beginning). Firewalls therefore also help to contain the damage.

This guy's network sounds like the Titanic. Seemingly invincible but suffering not only from the hubris of the architects but also from hidden but fatal flaws in the design which make the infrastructure fundamentally unsound even against the very dangers it was designed to withstand.

Re:Still don't even half way agree

[stuart_berman]

These points go to some of the issues I am trying to raise:

"usability are generally higher on the internal network "
This is changing in many corporate networks. People and systems on the outside are needing as much if not more access than other users in the inside.

"open file sharing services"
This typifies the perimeter security model (not defense-in-depth) which has an internal network that is 'soft and checwy'. This model no longer works for many corporate networks.

"What about defense in depth?"
This is what I am proposing (I don't claim that any of this is innovative - it is just that it gets more lip service than effort) - the firewalls are being asked to carry too much of the burden, the other layers are either non-existent of supremely weak.

"Getting rid of the firewalls"
I am not saying we should do this but we should ask everyone to act as if this is the case. (This counters the mindset that says, we do defense in depth, we have a firewall! Or 'let someone else put in a layer of security, I'll be safe anyway")

Firewalls won't protect you from dumbass employees

[tgraupmann]

The greatest firewall in the world isn't going to stop your employees from opening attachments and running exe's they downloaded from the net. It's simple to write something that can infultrate your network that runs on port 80. Because if you close port 80, your employees can't surf the net without a proxy server.

Router + ACLS = a firewall

[einhverfr]

I don't understand this "fear" of firewalls that people seem to have nowadays... firewalls are not a bandage, they are a layer of security that should not be removed. Say you want to access SSH from only computer X, well, having the service open to the world and just rejecting logins from other computers still leaves it vulnerable to buffer overflow problems if there are any discovered.

First, as you point out router with acls are firewalls. I would say that a firewall is *any device which provices a security barrier between networks* (which includes a DMZ between the internal network and the external network too).

Secondly, any security professional who recommends dispensing with firewalls, I agree, is not to be trusted at all for security advice. Firewalls have a large number of uses including damage isolation, traffic control, detection of abnormal attack or traffic patterns, etc. Dispensing with them is just not wise.

Firewalls are needed many places

[einhverfr]

The point of the article is that your "added security" from the outer firewall is probably unnecessary and therefore nonexistent if your internal security is good. Your comment gets modded "redundant."

Sorry, but it doesn't work that way. The function of a firewall is simply to add one more obstacle between the attacker and the resource being attacked. Defense in depth is a good thing...

This being said, my business network consists mostly of externally visible servers. So I use an approach similar to that in the article (without the application server DMZ as my entire network is in a DMZ). However, I *still* use an external firewall. The firewall has a number of important functions, both as a security and a generic network appliance. It handles:
1) Some VPN termination
2) External DNS
3) Load balancing
4) masquerading my entire network behind one public IP address.
5) General network abstraction-- presenting my network to the external world as a single machine (see #4 above).

Probably 90% of the services I run are externally accessible on at least one machine. But the firewall does provide a strong degree of added protection *when combined with other means.* And it is just one more obstacle that the attacker needs ot overcome.

Redundancy in security is a good thing. Even if your security is good elsewhere, the security a firewall adds is almost never unnecessary.

Re:Firewalls are needed many places

[Master of Transhuman]

You comment basically merely reiterates stuff that the article deals with.

The other services that a firewall renders are irrelevant to the discussion because the same services are available from any cheap 486 Linux (or other OS, including Windows - well, not on a 486!) box running as a firewall or not and any number of other network devices that do these things. We're talking about the firewall here strictly as a device to handle packet filtering intelligently.

"my entire network is in a DMZ" How does this square with being "defense in depth"? You need MORE THAN ONE DMZ to have defense in depth. The article has a three-tier approach which is actually very commonly advocated.

Also, the point of the article is that there is NEVER a need for ALL servers to be exposed to the Net using the three-tier approach. I suspect your systems are not using the presentation layer/application layer/database layer approach to system design mentioned in the article which is a pretty common approach these days, if not for security reasons.

As for the firewall being "unnecessary", the point is that if your security elsewhere handles all the things the firewall is supposed to help with, then the firewall is redundant and adds maintenance time and expense better applied elsewhere. It's an economic decision once the security decisions are made.

These guys didn't START by dumping the firewall, they got fed up with them over time and migrated to a different posture they feel is more effective at protecting what's important while allowing more freedom to the end users. Some /. commentators seem to think the article just advocates up and dumping the firewall without rethinking the security architecture in total at the same time. I didn't get that sense from the article.

Re:Firewalls are needed many places

[einhverfr]

The other services that a firewall renders are irrelevant to the discussion because the same services are available from any cheap 486 Linux (or other OS, including Windows - well, not on a 486!) box running as a firewall or not and any number of other network devices that do these things. We're talking about the firewall here strictly as a device to handle packet filtering intelligently.

You can't handle packets intelligently with a cheap Linux box and various usermode programs?

Ok, so it may be too much to ask for a P1 with 32MB RAM to run (or even compile) an H.323 gatekeeper program. But even a 80486 could be used with many of the layer-7 patches for netfilter to provide very sophisticated handling of packets. Once you add the ability to use usermode programs to filter other forms of packets, then you have a very capable system.

"my entire network is in a DMZ" How does this square with being "defense in depth"? You need MORE THAN ONE DMZ to have defense in depth. The article has a three-tier approach which is actually very commonly advocated.

Filtering router in between DMZ and internet. Strong host-based security, etc. It is a little more complex than this because although the entire network is a DMZ, it is sort of logically set up into several smaller DMZ's of a structure not conceptually different from the article.

There are actually a large number of layers that are necessary to compromise the network. There are some areas where we have had to make some tradeoffs of expenses vs security, and we are aware of these and are slowly working on them.

Finally my network is not typical. 75% of the computers offer services to the internet and the other 25% are mobile laptops (which must be hardened anyway). So the "My network is a DMZ" is relatively apt for my specific network. It is not a general recommendation. Even here we have multiple forms of obstacles to get layered defences. We don't rely exclusively on the security of the hosts, and if one system was compromised, it would not likely affect operation of our business.

We have had a number of what look like serious recon attempts against our network. We caught these by reviewing firewall logs (I use an automated tool I wrote to flag suspect activities and it errs on the side of false positives. I can them review the logs to see what is really going on). We have also been seeing what look like more and more sophisticated attacks (but probably automated) on our network. So far we have been lucky enough to avoid having these be successful.

For obvious reasons I won't go into the exact security measures in place. However I will say that so far they have been sufficient, and that we are planning on providing substantial upgrades to these measures in the next few months.

Re:Firewalls are needed many places

[Master of Transhuman]

"I use an automated tool I wrote to flag suspect activities and it errs on the side of false positives. I can them review the logs to see what is really going on)."

Excellent approach - it's what the article recommended and I agree the best method is to have someone eyeball the alerts and follow up rather than poring over logs in the first place.

I didn't say you couldn't use a cheap Linux box as a firewall, I said the other features provided by such a firewall (NAt, etc.) weren't relevant to the use of a firewall to detect and block complicated attacks. In other words, the justification of a firewall AS A firewall and AS A security appliance depends on its security aspects, not its general networking utility features.

When you say 75% of your systems offer services to the Net, are you saying you don't have ANY "back-end" servers such as database servers that would logically need to be separated from the Net-facing systems? If so, then saying the entire network is in the DMZ would make sense.

If not, those back-end servers should be isolated from the Net-facing systems as described in the article - and yes, the article recommended application layer firewalls as well as Layer 3 switches with ACLs (which are effectively firewalls in this context), so in this context firewalls are definitely needed.

It sounds to me like your systems work a lot like the ones in the article, albeit you have the additional Net-facing firewall. If it's working to keep out and alert you to serious penetration attempts, then I'd say you're doing the right thing. In your configuration, having the additional firewall protection might well be a reasonable trade-off. The article simply suggests that's not always the case and I think it's not wise to dismiss that as a viable concept. I suspect it depends on the specifics of each network and the relevant targets to be protected and the probable type of attacks - in other words, the usual risk analysis.

publish your ip

[Anonymous Coward]

I will prove you wrong

Firewalls protect from *OUTGOING* traffic

[wtarreau]

It's one thing to give up the firewall if all you have behind it is servers.

I cannot agree here, whatever you have behind your firewalls - servers/stations -,
the firewall protects your network from OUTGOING traffic, while the hosts themselves cannot. Having a webserver broken into and used as a spam base is not something any admin should accept to risk. And the firewall protects against that : outgoing traffic.

Rule of thumb : if a root on any of your front servers can do nasty things to your network or outside, then you need a firewall to filter traffic from this server.

Willy

One more thing

[einhverfr]

I hold with the 80/20 rule. YOu spend 80% of your effort protecting 20% of your resources (usually your servers). Usually this is broken down as follows:

40% or so on external-facing servers in the DMZ.
40% on business-critical servers and infrastructure.
20% on workstations.

Secondly, a well designed firewall infrastructure should allow external admin applications to open ports (say connecting via SSH). So the majority of the effort in opening a port is determining whether the security and business ramifications mandate opening it or denying the request. This is what your security architects should be doing anyway.

Re:One more thing

[Master of Transhuman]

"So the majority of the effort in opening a port is determining whether the security and business ramifications mandate opening it or denying the request. This is what your security architects should be doing anyway."

And by dumping the (external) firewall you avoid all that work. The issue is whether the work is worth it. These guys decided it wasn't.

With the article's approach, you put 80% of your work on the servers - which makes them (perhaps not quite) twice as protected as if you put 40% into them. In other words, you're not splitting up your defense resources which leads to a more effective defensive posture.

well...

[Tom]

two words: "scrub all"

A good firewall does more than just port filtering. It cleans up the traffic, writes logs (on a different machine), it terminates VPN tunnels and enforces routing policies between networks.

Maybe your firewall is a glorified ACL - mine aren't so get your dirty hands off them.

This would be a lot more interesting...

[nuckfuts]

if the solution described didn't use a firewall, as in this line from TFA:

"The servers and their respective applications sit in their own DMZ, protected by an Application-layer firewall".

At least you need few rules

[vivekg]

It is true that if you run dedicated FTP/www server then firewall/iptables plays limited role such as blocking IPs. But I run iptables on server to block atleast following type of stuff:

Syn-flood protection
Make sure NEW incoming tcp connections are SYN packets; otherwise drop them
Packets with incoming fragments drop them:
Incoming malformed XMAS packets drop them:
Incoming malformed NULL packets
Spoofing and bad addresses
Filter incoming ICMP, PING traffic
Block the unwanted IPS

Berman, Blogs, and War

[tdaxp]

Mr. Berman is an admirer of the war-strategist Thomas P.M. Barnett, and Bermans theories can be seen as war doctrine applied to IT networks.

This same story appeared on Berman's blog a month ago.

Re:Berman, Blogs, and War

[stuart_berman]

Yes, I am. But I would call Tom a global security strategist.

Re:Berman, Blogs, and War

[tdaxp]

Yup, you're right. :)

-Dan tdaxp

Who are people?

[tepples]

Why is their visibility a problem? If they are running services that you want accessible, they need to be visible. If you don't want people to access the services, turn them off, then the machines aren't vulnerable.

Depends on whom you mean by "people". Administrator wants authorized employees to access some of the services, not the general public. Besides, globally routable IP addresses cost money per year, which is a waste for machines that will only be used by users on the LAN or who have authenticated to the VPN.

thin-clients

[Anonymous Coward]

The article describes a 3-layer model. Looks to me like they have set up a thin-client model, or at least are almost there.

I'm author of TFA

[stuart_berman]

For those of you who haven't totally uncloaked my conspiratorial attempts at world domination or my simply lame ass ideas, here are a few clarifications:

I wrote the article to inspire discussion among a broad audience and inspire attempts to harden the inside of corporate networks.

The Network Magazine column called 'Soapbox' requires a 650 word submission - my first attempt to write a concise summary yielded about 1500 words. Perhaps a better person would have refused to discuss such a topic with less than 1500 words, but I chose to balance idealism with pragmatism. Consequently the content got pretty hacked up and some points rose to a higher level of attention than originally desired. I have great respect for Network Magazine and I consider getting published in it an honor, and in order to have a piece published the topic should have a wide appeal, be interesting and perhaps be a bit provocative - the title reflects that.

For a Slashdot audience I certainly would not have composed an article this way since the subtleties would not get lost on a Slashdot readership. A more accurate description of the topic would be, 'stateful inspection network based firewalls are being given far too much credit for the security they and perimeter security in general can possibly bring to a system'. As several people have noted, I am not advocating that we should eliminate the perimeter or network firewall, but rather trying to get people to reconsider what it actually offers in the way of security - to sum it up concisely: it becomes a coarse grained noise filter. (In early drafts I tried to liken it to an RF choke.)

In an IT context, too many IT people who should know better see a firewall as a panacea. Threatening to remove the firewall gets their attention rather quickly. When I talk to our IT architects, managers and system admins I try to get them to work to create systems that are as reasonably secure in the environment in which we operate. If we are running an insecure desktop in an enterprise such as Windows 95 then there needs to be a wakeup call to get this situation changed. If we approach this as though we are living without a firewall, then the people responsible take a very different view of what needs to be done to correct the situation and we consider better alternatives. I am not advocating a specific solution rather an approach that views our internal network as being hostile rather than safe. I contend that there are viable solutions available to us today to build affordable and secure systems whereas many larger companies have adopted an attitude that we can live with the status of our internal networks as they exist today.

For those people that put a lot of faith in firewalls, I simply say that most significant threats go around the firewall (e.g., reverse proxies ala Adrian Lamo; war dialing; and access via VPNs and remote site penetration); go through firewalls (e.g., embedded content in e-mail; direct user downloaded content; XML vulnerabilities; and spyware) or simply exist within the internal network and don't need to consider the firewall (e.g., malicious employees; partnerships with organizations that don't respect our 'property' or are careless about handling access). For many companies the threat is already inside the walls - they just refuse to accept it.

So I don't foresee the network firewall going away, but it will continue to be less effective as we are required by the business to continue to create more permissive rules and see more channels that bypass it completely. We do need to create ways to put the protections closer to the stuff we are trying to protect.

I didn't touch on home networks, but this is an area I strongly advocate the use of simple and cheap hardware firewalls for most people. This is not just because home users have notoriously vulnerable systems and generally don't need to allow inbound connections but also for any system that has to deal with the noise coming from the Internet and all of the wasted processor interrupts th