Other Does the web servers or other application servers also need to enable the firewall?

Hello everyone,

If there is perimeter and internal firewalls in DMZ, should the firewalls on the servers still be enabled? Such as web servers and database servers.

Thanks.
 
Your question is not very direct and clear enough to me. However, I would expect that you need configure your firewall (including internal firewall in DMZ) to allow traffic in/out for web servers (via port 80, 443 and your choice ports), database servers (e.g. 3306 for mysql) and other servers.

Look up the Internet for a good resource on how to configure your PF firewall.
 
If there is perimeter and internal firewalls in DMZ, should the firewalls on the servers still be enabled? Such as web servers and database servers.
That depends on your company's policy. I've worked for companies that insisted a local firewall must always be enabled, and I've worked for companies that don't.
 
It is really a matter of company policy. IMHO if there is a proper security policy on the firewalls then the systems should not be running any type of local firewall. Stateful inspection always adds some extra burden to a server.
 
It is really a matter of company policy. IMHO if there is a proper security policy on the firewalls then the systems should not be running any type of local firewall. Stateful inspection always adds some extra burden to a server.
I agree with your opinion.
 
Best practices would dictate that every server have a firewall. Not doing this gives you a shell defense with no protection against an internal threat (which is the most likely threat, actually). Servers should also be locked down other ways (access control, no unnecessary software running) and networks should also implement other defenses (use of vlans to provide isolation, traffic control and monitoring, etc), but a firewall on every box is certainly one component of a secure environment.

In some environments, I use port-knocking (using custom software) before even allowing an ssh port for remote (LAN-only) access to open on the server. In today's environment, there is no such thing as too paranoid, though as we see over and over there is certainly such a thing as not paranoid enough.
 
If another box is penetrated within the same LAN, then having firewalls on other servers/workstations potentially limits propagation.
 
If another box is penetrated within the same LAN, then having firewalls on other servers/workstations potentially limits propagation.
...or within any LAN that is not explicitly isolated from the LAN that has the compromised system...
 
Best practices would dictate that every server have a firewall. Not doing this gives you a shell defense with no protection against an internal threat (which is the most likely threat, actually).
You typically poke a lot of holes in a local firewall or else the server is pretty much useless. So a firewall isn't going to protect you here, it just adds to the complexity without adding much security.
 
You typically poke a lot of holes in a local firewall or else the server is pretty much useless. So a firewall isn't going to protect you here, it just adds to the complexity without adding much security.
You don't if you are doing it right, and if you have designed for security. You will open only those ports you need for the server to function. And the server functionality will be limited and/or isolated depending upon its function. Thus, the vulnerability of the server is limited to vulnerabilities of the software that uses the open ports. And, of course, you keep your server patched up-to-date, naturally. You do, don't you?

If, for instance, you host the database that handles your company's financial and personnel data on the same box that hosts your internet-facing web server (even if it is protected by a perimeter firewall), then you deserve what you get...and you certainly will get it. In such a case, you will indeed have "many holes" and you have given no thought to security.
But if you have done it properly, the web server only handles that job, and the database server is on a different vlan and only does THAT job, and the vlan the web server is on is not allowed to talk to the vlan the database server is on. In this case, each server has only the holes it needs and a compromise of one limits the risk to the other.

Even if a local firewall only adds a bit of security (an assertion which I dispute, most particularly if there are Windows or Android devices on the network even part-time), that is one more barrier in place to protect your data. There is no magic bullet; security consists of a number of constantly changing steps, each being intended to increase the difficulty of compromising networks and exfiltrating data.
 
You will open only those ports you need for the server to function.
I only enable services that are needed for the server to function. Services open ports. This isn't Windows where there's a million and one (unrelated) services required to be running.

and the vlan the web server is on is not allowed to talk to the vlan the database server is on
And how is your dynamic website supposed to get its data if it's not allowed access to the database? If it's allowed access to the database you're already opening yourself up for SQL injections. A firewall, local or otherwise, isn't going to change that. Neither is splitting the database servers off on their own VLAN. The website needs access to the database and you'll have to deal with that, i.e. poke holes in firewalls.
 
And how is your dynamic website supposed to get its data if it's not allowed access to the database?
That seems to be a common poor design/build approach. Web site based apps pulling data from the main database should be managed. Typically web site data volumes are low and the design/build can control that. Larger/broader data accessing should be internal - made on the same LAN as the database, isolated from 'outside'. Otherwise If a web facing app can pull the entire database then sooner or later it could be pulled externally by someone not intended to have such extensive data content.
 
Otherwise If a web facing app can pull the entire database then sooner or later it could be pulled externally by someone not intended to have such extensive data content.
Well, it could be worse. It could use MySQL's root account for this. Wouldn't be the first web application. But never on my watch, the first developer that suggest I put that into production gets free flying lessons from the top floor of the building ;)

But these are all design requirements, none of them have anything to do with a local firewall. Which is what this thread is about.
 
This isn't Windows where there's a million and one (unrelated) services required to be running.
Then you are artificially limiting the discussion. OP asked whether firewalls on servers should be enabled. He did not restrict it to just *nix servers. And even so, those services needed for the server to work are limited by the number of functions the server handles. Generally, from the perspective of security, the server should handle fewer functions in order to limit risk. How practical this is...just depends. There is always a compromise involved, but the more critical the data is the less you should be willing to compromise.

Ask Maersk:
https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/


And how is your dynamic website supposed to get its data if it's not allowed access to the database? If it's allowed access to the database you're already opening yourself up for SQL injections. A firewall, local or otherwise, isn't going to change that. Neither is splitting the database servers off on their own VLAN. The website needs access to the database and you'll have to deal with that, i.e. poke holes in firewalls.
Well, that depends on the data that is in the database and how you have distributed and segregated your data to enhance security, now doesn't it. And, to the extent you must allow web access to sensitive data, you still gain considerably by having that database on a different server, on a different vlan (with vlan-vlan access only for a small number of specified ports and to/from specified machines). If it shares the server that is the webhost, and I crack that webhost, then I have gained full access to that data. If the data is on a different server than the webhost, and I crack the webhost, I may have access to a port that has access to the data but I still have to deal with the security protocols on that separate server; I do not have full access to that data and (depending on the security protocols between the two boxes) I might not have ANY access until I take further steps. Since it is on a different vlan, has a firewall, and my access is controlled by the router that controls the vlans, I can't just start scanning it to figure out how to break into it.

In the very worst case, my attack has been slowed down, which gives you more time to discover me. If you are monitoring your network, of course.

Reality is, in today's world, with the growing internet of things and the pervasiveness of "bring your own devices" that you can't stop the penetrations. You simply can't; it WILL happen. Therefore, you design your systems for security. Segregation and separation. Cofferdams. Barriers. Walls. Monitoring. And local firewalls are certainly part of that.

If you wish to be HIPAA and PCI compliant - and in today's world, you really want to be - then you'll do these things. When (not if) your network is cracked, the damage will be limited, you will have time to identify the penetration and kick the attackers out, and your customers, your employees, and your trade secrets will be safeguarded.
 
Therefore, you design your systems for security. Segregation and separation.
I fully agree with that. I just don't think local firewalls add anything and may actually give you a false sense of security. There are a lot of 'manager' type people out there that think a 'firewall' is some magical piece of kit that protects them from the bad guys.
 
I fully agree with that. I just don't think local firewalls add anything and may actually give you a false sense of security. There are a lot of 'manager' type people out there that think a 'firewall' is some magical piece of kit that protects them from the bad guys.
Quite obviously, lots of manager type people simply don't understand the issues. If they did, then we wouldn't be seeing what we are seeing in the world today.

Well...maybe we would; there is an enormous shortage of properly qualified personnel to actually address these problems right now.
 
Back
Top