Ask Slashdot: Is Running Mission-Critical Servers Without a Firewall Common?

An anonymous reader writes: I do some contract work on the side, and am helping a client set up a new point-of-sale system. For the time being, it's pretty simple: selling products, keeping track of employee time, managing inventory and the like. However, it requires a small network because there are two clients, and one of the clients feeds off of a small SQL Express database from the first. During the setup, the vendor disabled the local firewall, and in a number of emails back and forth since (with me getting more and more aggravated) they went from suggesting that there's no need for a firewall, to outright telling me that's just how they do it and the contract dictates that's how we need to run it. This isn't a tremendous deal today, but with how things are going, odds are there will be e-Commerce worked into it, and probably credit card transactions... which worries the bejesus out of me.

So my question to the Slashdot masses: is this common? In my admittedly limited networking experience, it's been drilled into my head fairly well that not running a firewall is lazy (if not simply negligent), and to open the appropriate ports and call it a day. However, I've seen forum posts here and there with people admitting they run their clients without firewalls, believing that the firewall on their incoming internet connection is good enough, and that their client security will pick up the pieces. I'm curious how many real professionals do this, or if the forum posts I'm seeing (along with the vendor in question) are just a bunch of clowns.

Comments

Common?

[bengoerz]

Is stupidity common? Yes. Yes it is.

In my experience, the stupid people tend to get fired eventually. But the mess they leave behind can be tremendous.

Every stupid idea is common

[i kan reed]

Not just because plenty of things are run by stupid people, but also because otherwise smart people can have pretty damned important blind spots. And other IT people have been talked out of it by their clients just like you're letting happen.

Whether it's common or not has no bearing on whether it's a good idea.

The only question you need to ask them is weather they're willing to accept the quantified risks from having exposed systems.

Fire(wall) and forget

[RichardJenkins]

It sounds a little like you're trying to just fling a firewall at the system and improve some sort of objective security metric.

What threats are you risks to mitigate with the firewall? What threats will it help guard against?

They don't come for free, and configuring them don't come for free.

Re:Fire(wall) and forget

[Anonymous Coward]

It sounds like you're some bureaucrat trying to justify the costs of standard security practices.

The objective of any firewall is to prevent traffic on all unused ports in order to limit potential attack vectors. This is a given and no specific threat needs to be stated.
Put the firewall up FIRST, and open essential ports as necessary. This is network security 101.

Re:Fire(wall) and forget

[praxis]

But again. What IS the threat of network traffic to a port no one is listening on? None. What your firewall is you protecting from is NOT bad stuff from the outside. It's protecting you from the inside danger that some service suddenly opens a port which is reachable from the outside. (Hate to dig out the old Win vs. *nix, but the usual suspects for this are usually Windows servers you need to lock down first, as they're usually asuming that they're in a friendly network. On *nix machines you usually need to manually add those services one by one, as you would open the ports on your firewall)

The firewall provides defense in depth. Yes, if nothing else goes wrong, the Firewall is unnecessary. On the other hand, if something else does go wrong, the firewall become another obstacle for the attacker.

Picking battles...

[Kookus]

The problem with this battle is that you're a contract worker. So if reasoning/persuasion doesn't work, then you're only options are to end the contract, or fulfill your obligation.
Keep documentation that shows that you brought up the problem, and were rejected. Bake in language on subsequent contracts that give you an out under these types of scenarios, and move on.
If someone is unwilling to listen to reason, is in a position of power, and there's no laws that they are breaking, then that pretty much gives you all of the information you need to know about your options! Just learn to stop worrying and love the bomb.

Re:Apparently...

[i kan reed]

Or bandwidth. Or visitors. Or intern-connections. There's a lot of room for serious damage from a lack of security, and not all of it is data theft.

People using your server as a spambot is bad.
People infecting your sites visitors with malware is bad.
People jumping to a different, more secure system from your server is bad.

We tend to notice the data theft issues most these days, because a lot of companies keep a lot of sensitive data, so a Target credit card hijack is tremendously bad and newsworthy.

But that doesn't mean other classes of security risk don't exist.

Re:Apparently...

[Jason Levine]

Exactly. Too many people (both businesses and home users) say "Well, I don't have anything that 'those hackers' would want so why bother with protections?" The thing is, though, you DO have something they want. At the very least, a home user has bandwidth. If a malware author hijacks a computer, he can use it to pump out tons of spam. The user might notice an annoying slowdown but otherwise wouldn't know what was up. In the case of businesses, infecting your customers with malware (due to being hacked) or your site slowing down to a crawl (because it is a spam bot and is spending precious resources spamming people) is a sure method to lose customers. I'd wager that the money "gained" by not doing a proper firewall network is more than lost by the "lost sales" of customers fleeing after the servers have been hacked.

Re:Its Fine. - not

[Bacon Bits]

Application support always says to turn off everything that might possibly interfere with their precious application. They would have you shut down the operating system if they didn't need it. Application support lives in a fairy land where the only thing they have to worry about is their application. They don't have to fix anything if the application isn't broken. They have no interest in anything else. A good vendor will program their application to work with the system standards. Most ISVs are not good vendors.

As a system or network admin, you have to protect the application from the rest of the network and protect the rest of the network from the application and protect everything from the users and the Internet. Part of doing that is firewalling the crap out of your core network, and if you can't do that you should be looking at adding more VLANs and controlling traffic that way.