Ask Slashdot: Is Running Mission-Critical Servers Without a Firewall Common? 348
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.
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.
PCI Compliance (Score:5, Informative)
As soon as they start handling credit card transactions, they will need to conform with PCI standards, which will mandate much much higher levels of protections. There are significant fines associated with non-compliance so you may want to forward them over information about this.
Trusted network zones (Score:5, Informative)
If your database is in a trusted network zone, it's fine.
If you have a bunch of assets outside the corporate firewall, you're doing it wrong. These belong behind a DMZ firewall, blocking any ports not strictly necessary, possibly with PNAT and coalescence (i.e. an FTP, Web, and Mail server, natted to the same address, ports 80, 443, 25, 21, and FTP PASV going to different addresses behind that).
Within that DMZ, servers provide whatever services they're going to. MySQL on port 3306 will provide MySQL on port 3306; if you add a local firewall, you will have a firewall that blocks all non-listening ports and leaves port 3306 open, so no difference. If you're worried about ssh, use an IP console card (DRAC, etc.) on a separate subnet, or put the database servers behind another firewall. It is, in fact, common to create trust zones for front-end, application, and database, such that i.e. your Web servers connect through WSGI to a CherryPy application, which connects back to a Database, through a firewall in each step. You can do this with vlans and broken-down subnets, one switch, and one firewall.
You have to consider everything when you design secure network architecture.
Re:Tower Systems (Score:2, Informative)
I build and supply retail chain management systems and part of the platform is a store management system, which communicates with POS machines (in most cases via a share). So our solution to what you are describing (a common problem with POS systems) is to put our store management system on a Linux machine that has 2 network cards in it, one is the Internet connection and the other is LAN, this Linux machine runs the store management system and it becomes local network manager and a firewall.
The POS machines are on the LAN only, no Internet connection for them, the store management system connects to the retail management system that is external to the store (controls the entire chain). This way we can avoid this huge security breach.
Re:It Depends (Score:5, Informative)
Depends on the quality of the web apps running under LAMP
If they get hacked, it may be possible for the attacker to spawn a new process running on some other port (ie, a shell), or sending stuff out to other machines, so having a firewall that only allows the services you have listening may be good, as well as possibly having it restrict new outgoing connections.
And no, you don't need to write complicated iptables scripts/rules to do this. The ufw utility (available in Debian, Ubuntu, Mint, etc) has truly simple syntax
ufw allow ssh
ufw allow http
ufw allow https
ufw enable
Re:Its Fine. - not (Score:4, Informative)
Sorry to barge in like this.
Oracle does not have issues with firewall. A proper firewall will allow a specific program to monitor a range of ports.
Ex.
Open port 80 system wide.
Open ports 40000-65000 for sqlserver.exe TCP and UDP.
You may have multiple listener processes, it takes a few moments and some research but in the end, you ensure the door is opened only for the ports and processes you want. This blocks the door for ports and processes that may be vulnerable thru bugs.
It's not perfect, nothing is. But it's better than staying opened.
Will you get hit if you don't, not necessarily but what if you do??? How much is your data worth? Restore time and data lost since that last restorable backup? What? You don't have a backup or have not tested your restore recently... (excuse me while I rotfl).
Sorry for the nasty punts, but let's face it, the day you get hit. I will say the same thing as today. Rather you hear it today, it's cheaper for you and if I helped in anyway, I'll be glad to not laugh later. I do go see humour shows, I don't need this for entertainment.
Good luck, and best of chances either way you go.
Re:Its Fine. - not (Score:5, Informative)
Re:It Depends (Score:4, Informative)
That's completely the wrong approach..
If your hosts aren't secure enough to be on the public internet, they shouldn't be on an internal network either. Many attacks come from the inside, and if you have a large number of insecure hosts hidden behind a border firewall then all it takes is one tiny hole and everything can come crashing down, as has happened many times in the past.
A firewall is not the ultimate answer, and nor should it be your only line of defense. If hosts are correctly configured, then a firewall won't actually improve security as the only services exposed on the host will be ones you intended to run and thus explicitly allowed through the firewall.
yes it is common (Score:4, Informative)
Don't be a muppet. Limit the spread of malware on your network as much as possible by only opening things that need to be open, to places they need to be open to. There is ZERO reason, for example (plucked at random to illustrate a point), for your end user PC network being able to directly connect to SMB on your SQL server, for example.
Yes, in theory they need credentials to do that. But why leave it open to anyone who obtains credentials when you can be more pro-active about defending the box?
Re:Fire(wall) and forget (Score:5, Informative)
It doesn't matter if it's a rational argument backed up by facts or not, or if he's done a risk assessment, or if it's a free, cheap, or expensive firewall. The Payment Card Industry's Data Security Standard (PCI DSS) has as their very first requirement 1: "Install and maintain a firewall configuration to protect cardholder data." It's not an optional requirement, and you can't justify not having one.
If you're going to handle credit cards on the system, it has to be protected with a firewall.
If your POS vendor isn't requiring a firewall, either they are not selling a system that takes credit cards, or they are selling shoddy, insecure systems that are in violation of PCI DSS. Fixing these problems will cost you dearly; worst case, they are setting you up for a breach.
Discussion with Client legal (Score:3, Informative)
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.
I suggest you relegate the 'is this common' question to a discussion after hours over a beer.
Your real issue is security. I would want to schedule 2 different meetings, preferably with everyone attending in person. The first is a prep meeting with your client and their legal counsel to discuss your concerns, review the contract language that is being referenced by the vendor, and what liability the vendor has if the machine is compromised due to the vendor required there be no software firewall.
The second meeting would be with your client, their legal counsel, and the vendor.
Re:Its Fine. - not (Score:5, Informative)
Re:Common? (Score:5, Informative)
On the bright side, PCI compliance highly regulates credit card information security and will scrutinize any company/network/point of sale equipment that comes in contact with credit card info. They will never pass inspection with no firewall, which means that they will need to become PCI compliant or face fines.
That point alone was usually enough to convince our clients to do things the right way.
Re: Its Fine. (Score:2, Informative)
Not true. We ran host based firewalls on all our oracle servers, solaris, windows and Linux.We opened up port 1521 (sql*net) and that was it. If I recall, windows based servers defaulted to a handoff port like you describe, but it could be easily configured for just 1521.