Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

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

Soulskill posted about 7 months ago | from the common-enough-to-make-you-sad dept.

Networking 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.

Sorry! There are no comments related to the filter you selected.

Its Fine. (3, Funny)

Anonymous Coward | about 7 months ago | (#47566127)

Everything is Fine.

Re:Its Fine. (3, Insightful)

beschra (1424727) | about 7 months ago | (#47566161)

I think Target may disagree. Firewalls on database servers may not have kept their data safe but their experience proved that it is unwise to assume that all internal network traffic is trustworthy.

Re:Its Fine. (0)

Anonymous Coward | about 7 months ago | (#47566315)

If a firewall would not have kept the data safe, and you have to pay someone to maintain the firewall, they why would you bother? It's not like Target was some kind of wake up call, the industry is already aware of the fact that internal network traffic can be malicious.

Re:Its Fine. (1)

scubamage (727538) | about 7 months ago | (#47566399)

This is true, however some databases simply aren't compatible with local firewalls. Oracle for instance requires your server to be more or less wide open (request comes in on one port, a response is sent back indicating the port to actually communicate on, then the client resends the query to that new port - so, more or less all ports have to be unblocked). This is where stuff like centralized authentication, nagios, monitoring of the /home/*/.history files, etc comes in useful. Sometimes local firewalls simply aren't an option.

Re:Its Fine. (0)

Anonymous Coward | about 7 months ago | (#47566521)

[...] monitoring of the /home/*/.history files, etc comes in useful.

How is that any useful? I always symlink mine to /dev/null because having "rm *" in history is asking for trouble. Anyone malicious could do the same to avoid your cutting edge monitoring of .history files.

Re:Its Fine. (0)

scubamage (727538) | about 7 months ago | (#47566659)

It's actually quite useful if you have something which monitors those files. No open CM ticket for a server, but you suddenly see someone logged in and making changes? Sound an alarm. .history shows you everything a user types as soon as they type it (even modifying the shell to keep 0 history would show up initially). We use splunk to monitor it, and also monitor /etc for any changes to system files. It's lightweight and has helped us find a number of issues before.

Re:Its Fine. - not (4, Informative)

Anonymous Coward | about 7 months ago | (#47566571)

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.

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 (4, Informative)

scubamage (727538) | about 7 months ago | (#47566677)

After 4 weeks of oracle training, the advice from the oracle trainer was that oracle simply doesn't play well with firewalls. I'm not a DBA (thankfully), but that's from their actual instruction.

Re:Its Fine. (1)

Titus Groan (2834723) | about 7 months ago | (#47566817)

so on the client side you would run rules such as "established and related" or specifically allow all UDP or TCP to/from the required server's IP. You should still run a firewall, but the rules would be a little more relaxed.

Common? (4, Insightful)

bengoerz (581218) | about 7 months ago | (#47566147)

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.

Re: Common? (2)

Type44Q (1233630) | about 7 months ago | (#47566215)

Judging from the state of things in the world today, they climb to the very top of the shit-heap (who knew you could wear your stupidity and use it like a jetpack?!)...

Re: Common? (1)

Anon-Admin (443764) | about 7 months ago | (#47566257)

Johney Cash's Song "The Farmers Almanac" --
  It's a little off-beat and a little off-track
But it says in the farmer's almanac, it says
'In rivers and bad government the lightest things flow to the top'

Every stupid idea is common (4, Insightful)

i kan reed (749298) | about 7 months ago | (#47566151)

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.

Re:Every stupid idea is common (-1)

i kan reed (749298) | about 7 months ago | (#47566281)

Also: how stupid am I to use 2 different spellings of whether in one post?
It's not like I was paying extra attention to the first one.

Re:Every stupid idea is common (1, Funny)

rnturn (11092) | about 7 months ago | (#47566503)

Well... at least they were spelled correctly.

Re:Every stupid idea is common (1)

nospam007 (722110) | about 7 months ago | (#47566337)

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

And you might be able to make a quick buck with that information later.

Re:Every stupid idea is common (0)

Anonymous Coward | about 7 months ago | (#47566375)

This is a reasonable stance. You're there in a contracting position, not a long term security adminstrator. Make recommendations, detail what could possibly happen both now and in the future. I'd raise the point that if a company takes this stance on a firewall how secure could the rest of the system be? A firewall only blocks unwanted traffic. What about when you have to open ports to interface with their software? How secure is the underlying service? I'd argue not very.

Depends (0)

Anonymous Coward | about 7 months ago | (#47566169)

Is there a reverse proxy and a DMZ to the outside world and transparent VPN on the internal network between the database and the clients?

Apparently... (0)

Type44Q (1233630) | about 7 months ago | (#47566173)

Apparently only if you possess data that someone else might want... ;)

Re:Apparently... (5, Insightful)

i kan reed (749298) | about 7 months ago | (#47566319)

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.

Fire(wall) and forget (4, Insightful)

RichardJenkins (1362463) | about 7 months ago | (#47566175)

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 (2)

Maxwell (13985) | about 7 months ago | (#47566299)

Stop being rational. Just, stop it. You never need a business case for awesomely complex, double reverse DMZ firewall setups here on /. !

Re:Fire(wall) and forget (5, Insightful)

Anonymous Coward | about 7 months ago | (#47566353)

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 (3, Insightful)

bickerdyke (670000) | about 7 months ago | (#47566569)

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)

Re:Fire(wall) and forget (4, Insightful)

praxis (19962) | about 7 months ago | (#47566669)

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.

Re:Fire(wall) and forget (2)

Bert64 (520050) | about 7 months ago | (#47566593)

If ports are unused, then the hosts themselves will reject any traffic sent to them without the need of a firewall...
If the hosts are running services you don't want, then you haven't configured your hosts correctly and hiding poorly configured hosts behind a firewall is not the answer.

Re:Fire(wall) and forget (3, Insightful)

gstoddart (321705) | about 7 months ago | (#47566717)

If ports are unused, then the hosts themselves will reject any traffic sent to them without the need of a firewall...

Unless someone figures out how to glean information from your system, or exploit something you don't know about in the operating system. If I can figure out what ports you have stuff listening on, I can work on exploiting the things that I can determine are listening.

Without a firewall, you're allowing external entities to map the system, when they shouldn't even be able to reach the system.

if you're going to try for security, assume nothing, trust nothing, and act as if it was really important stuff.

If you're not going to try for security, well, the Ostrich Algorithm is a strategy, but one whose consequences you might need to live with.

I'm more of the school that says packet requests from sources you don't trust should simply be dropped, and not provide them with any more information than necessary.

Re: Fire(wall) and forget (1)

Anonymous Coward | about 7 months ago | (#47566611)

If the ports are unused, what is the firewall doing?

I rarely use firewalls on or in front of a server. Focus on maintaining security updates to the software which is network facing. It's the best you can do. A firewall in front of a server with an open port is stupid because it already has a giant hole in it.

Now, a firewall between local networks, that's a different matter.

Re:Fire(wall) and forget (1)

Maxwell (13985) | about 7 months ago | (#47566793)

No that is Windows Server Security 101. Network security is different. If you had network security you don't need firewalls on every single server in your enterprise because that traffic is already caught and logged elsewhere. By the time they are at your server, and you haven't detected it, it is too late.

Is it a Windows box? (0)

fatboy (6851) | about 7 months ago | (#47566189)

If it's a Windows box, the firewall for the local subnet is down if the "Network Location" is a "Domain Network" anyway, so it really doesn't matter.

Remember cornflicker? (1)

Anonymous Coward | about 7 months ago | (#47566191)

When I came here, the AD server (2003) where the Oracle Sales DB and the ERP were installed were in the called "DMZ" (at router level) because "Somebody in the European HQ wanted to browse some tables".

Yes, that's in a home router, DMZ, where it means "route everyhing that doesn't match a rule to that server".

Aaaaaaand it had cornflicker. The DC. The DB server. The ERP server. All-in-one and out of our control.

The reality is that there are a lot of enterprisey guys who don't have a clue of what they're doing.


It Depends (4, Interesting)

MightyMartian (840721) | about 7 months ago | (#47566201)

I've set up networks where the server infrastructure itself is on its own segment, so there's no need for firewalls between the servers themselves, but the whole subnet is firewalled by a border router.

A lot depends on how tightly you can lock down a server. On my *nix boxes, I tend to only run daemons with listening ports to the extent absolutely necessary. I have a LAMP server that basically has ports 22, 80 and 443 open, and everything else either shut down or set to listen only on Do I really need to configure iptables?

Re:It Depends (0)

Anonymous Coward | about 7 months ago | (#47566413)

Mod parent up -- If you have a border firewall, there's no reason for a software firewall on the server itself.

Re:It Depends (3, Informative)

Bert64 (520050) | about 7 months ago | (#47566733)

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.

Re:It Depends (0)

Anonymous Coward | about 7 months ago | (#47566481)

Yes, of course you really do.

You also need monitoring/logging any abnormal traffic or access attempt as the bare minimum.

Re:It Depends (5, Informative)

i.r.id10t (595143) | about 7 months ago | (#47566501)

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: It Depends (-1)

Anonymous Coward | about 7 months ago | (#47566853)

Everything happens over port 80 these days because everybody blocks everything except 80. Your rules are useless. Server-local firewalls only cause headaches for people trying to do work.

Further more, both Linux and Windows are riddled with kernel exploits. If an attacker can run a shell script, I guarantee you he can root your box.

Focus on maintaining security updates and if you can audit software yourself. Everything else is a waste of time because doing the former is infinitely more important and should be taking up a huge chunk of your time. For example, coaxing your coworkers to suck it up and move to a newer, better maintained version of some application.

If you find yourself fiddling with firewall rules you've already lost the battle.

Re:It Depends (3, Interesting)

bleh-of-the-huns (17740) | about 7 months ago | (#47566621)

I disagree. The border is just one aspect, and your typical threats tend to be the result of intentional stupidity (employee systems), or internal maliciousness (soon to be ex employee). A border firewall will not help in this particular case. Additionally, depending on the users access, no firewall may help. My preference, is typically to setup every server with a default deny, permit IPSEC traffic only to and from the support components on the internal network. Then obviously open the business requirements to provide a server. Example, a Web server that connects to a DB and image processing server, port 80/443 open from external to DMZ web server (DMZ and Application zones are separate), all other incoming ports from external are blocked, your border router can cover this. Internally, default deny to everything, permit IPSEC, between Web Server, DB and Image processing server, as well as terminal/jump servers. Tunnel all communications over IPSEC between the servers. In that way, man in the middle attacks become almost impossible, there is no sniffing traffic if a user manages to get local segment access, If the system is compromised in some way (SQL injection, etc, assuming the services are not running as administrator), the servers cannot be used as a jump point to other servers and components in the network, and vice versa.... Call me paranoid.. but that is how I do things. Also, there is no additional cost (except system overhead, and that can be compensated for by crypto cards, or the new Intel AES CPU instruction sets on their current gen Xeons, and I am sure other procs) to running IPSec, it has been included on every Windows server since 2003, and for Unix, Raccoon is free and works just fine.

Re:It Depends (2)

mlts (1038732) | about 7 months ago | (#47566711)

Out of habit, I like using iptables or firewallD with existing services. At first, there will be initial configuration breaks (especially outgoing stuff), but it provides me three assurances:

1: Machines not configured to talk with the machine will not be able to. This narrows down the attack surface greatly. For example, if a DB server only communicates to some machines in a DMZ, a limitation is put on to only allow that port, so another machine on the same subnet that gets compromised won't be able to access the DB. This also protects against unauthorized nmap scans.

2: If non-root malware gets on the box, it won't be able to phone home or get itself a connection outside. Defense in depth is often overlooked because it has been habit to focus on network security, with relatively little attention to paid to individual hosts and OS level security. Well, other than desktop malware that is.

3: It looks good in audits when you can prove that individual machines have packet filters in place.

Re:It Depends (0)

Anonymous Coward | about 7 months ago | (#47566781)

It depends - when your LAMP stack gets compromised through a common PHP vulnerability, do you want to block the outbound connections the script makes to download kernel exploits or not?

PCI Compliance (4, Informative)

ebrandsberg (75344) | about 7 months ago | (#47566205)

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.

Re:PCI Compliance (1)

EvilJoker (192907) | about 7 months ago | (#47566295)

Also, "Install and maintain a firewall configuration to protect cardholder data" appears to be the VERY FIRST requirement of PCI.
Now, I'm not sure if that can be met with a separate (hardware) firewall, but I suspect they require firewalls on each piece.

I'm assuming by "vendor", the OP meant a small company that sold the equipment and installation, not the manufacturer.

Re:PCI Compliance (1)

ebrandsberg (75344) | about 7 months ago | (#47566617)

This requirement is normally done at the network boundary, so a hardware firewall will meet this requirement, although for web facing servers, often companies also like having application level firewalls (protocol level) that can inspect for suspicious activity at layer 7, not just the simple stuff. There is a huge business around certification and auditing for this, nobody should just jump into handling credit cards without knowing what they are getting into.

Re:PCI Compliance (1)

skyryder12 (677216) | about 7 months ago | (#47566689)

This. You can also configure IPSec between the machines. This link gives you some specific info: http://www.it.cornell.edu/serv... [cornell.edu]

Run only services you need (3, Insightful)

Anonymous Coward | about 7 months ago | (#47566207)

The key is to only ever run the services that are absolutely needed, carefully configure these and keep them up to date. If you follow that advice a firewall is an added level of security but not necessarily needed.

Depends (0)

Anonymous Coward | about 7 months ago | (#47566213)

Is there a reverse proxy and DMZ to the outside world and a VPN between the clients and database server on the internal network? This will mitigate some of the risk.

Could you repeat... (1)

Anonymous Coward | about 7 months ago | (#47566217)

Could you repeat the ip address of this server, you know, for research and the children... :)

Firewalls are useless (0)

Anonymous Coward | about 7 months ago | (#47566235)

They don't prevent attacks, nor do they keep your data in. If you correctly secure your infrastructure, ie by using point to point, white listed communication pathways, you have done more than a firewall will ever do.
Firewalls are just like the TSA. They sure say they do their job, but do you really believe them?

Tower Systems (2)

criten (986175) | about 7 months ago | (#47566241)

Is a POS vendor used by most Australian newsagents. Their contract not only mandates the lack of a firewall, but a writeable share of the C: drive on the Windows machine acting as a server - with no authentication.

While this is incredibly negligent, the support contract makes the vendor completely liable for any security breach that occurs while honouring their contract requirements.

Re:Tower Systems (3, Informative)

roman_mir (125474) | about 7 months ago | (#47566445)

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.

Picking battles... (4, Insightful)

Kookus (653170) | about 7 months ago | (#47566243)

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:Picking battles... (0)

Anonymous Coward | about 7 months ago | (#47566627)

In common words of downtown.... Tru Dat !

As contractor, you might get stuck with the issue later if they call you back.

- Bring up the issue.
- Offer solutions, I usually show what could be done immediately and a best case scenario should they be willing to spend.
- Bring up backups, test restores. (this might get you a customer for life.)

The only question to ask is this.
How much are they willing to lose?

Good luck.

Data point (1)

sigmabody (1099541) | about 7 months ago | (#47566251)

I don't run a local firewall on my work system, for reference. As a developer, it's common to need to have "random" ports open for various things for testing, and having to deal with a firewall is one more nuisance I don't want to account for. A local (on system) firewall won't prevent most attacks anyway, so I don't feel I'm giving up much real security.

I do run a local firewall at home, but only because it has not annoyed me enough to be disabled yet.

I don't know how useful that information is; consider it a data point.

Firewall is a requirement, end of story (0)

Anonymous Coward | about 7 months ago | (#47566267)

PCI v3 compliance *REQUIRES* a firewall. End of story. Do not pass go, do not collect $200.

Re:Firewall is a requirement, end of story (1)

rubycodez (864176) | about 7 months ago | (#47566551)

so does PCI v2, with mandatory six month reviews of firewall rules

Trusted network zones (4, Informative)

bluefoxlucid (723572) | about 7 months ago | (#47566269)

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.

Ubiquitous (0)

Anonymous Coward | about 7 months ago | (#47566275)

The 3 machines are presumably firewalled from the broader internet?

The server isn't offering services beyond those needed by the clients?

If these are both true, I'm not convinced a local firewall on the server offers much security benefit, and is yet another thing to configure/troubleshoot.

What is the gain from running a local firewall? There are significant downsides in maintenance and troubleshooting time (not always, but not infrequently in my experience).

Like anything, it depends. (0)

Anonymous Coward | about 7 months ago | (#47566287)

Depend if you have ports open? Some OSes install a lot of extra crap that you cant remove and should firewall off, but its not always the case.

Usually a firewall is a good thing, as it can drop packets that would otherwise use your programs, but it is possible that the only ports they have open are the ones they are meant to access, in which case it doesn't really do anything for you unless you set up access rules.

Every vendor does this... (1)

Bugler412 (2610815) | about 7 months ago | (#47566291)

In some way every third party vendor does this. Anything that can potentially complicate their installation or support gets eliminated, rather than configured in a way that is appropriate or best practices. It reduces their support cost and increases their profits. Overspecing hardware and network resources for their app is another area where this is done.

common or not, it's not prudent (1)

roman_mir (125474) | about 7 months ago | (#47566297)

Well, whether this practice is common or not is probably irrelevant, it is still not a prudent thing to do.

I build and supply retail chain management software to a number of chains, there are dozens of stores that use it, we switch at least one computer in a store to a Linux machine that runs the store management software (the chain management software is a central system and it doesn't run in a store, but all stores talk to it.)

Store management system is on the Linux machine that faces the Internet, it has 2 network cards, one is the Internet and the other is LAN (the same machine controls the LAN). Since this is Linux, iptables is used to filter out any unnecessary traffic.

I think there should be some sort of packet filter on Internet facing equipment, POS or anything else.

It depends (2)

scubamage (727538) | about 7 months ago | (#47566313)

From the sounds of it, you're discussing disabling a software firewall, not an actual hardware firewall. There's a lot of applications which require local firewalls to be disabled - for instance, we disable local firewalls when we're deploying telephony application servers because of vendor requirements. Likewise, some applications require SELinux to be disabled as well. All of our servers are still collectively behind a firewall, and beyond that we have a number of ACLs and centralized authentication controlling them. As for not running a firewall being lazy - firewalls are tools. Sometimes they're the right one, and sometimes they aren't. The only way to tell is experience on when to use each tool (and budget too). The more time you spend with networking, the more you'll come to realize that. But since you're learning, stick to what you've been told until you master it. As Picasso said, "learn the rules like a pro, so you can break them like an artist."

Re:It depends (1)

Anonymous Coward | about 7 months ago | (#47566681)

Sad, it's just bad documentation.

SELinux does not need to be disabled, it needs to be configured. It's a hard piece of software to learn but once you know it, it can save your bacon against bad updates, typos in code that can open up some nasties.

Whichever way you look at this, disabling security features is just lazy. Learn your software properly and security is easy to deal with. As always, we don't take the time, rush rush rush. move to the next guys and deal with problems when they arise. Have the customer throw more money at more devices to protect what could have been protected if installed right the first time.

Boy, I'm really cutting loose today !

Internet servers (0)

pcjunky (517872) | about 7 months ago | (#47566339)

Plenty of companies do. This is standard Operating procedure for ISP's and online services. Google, Facebook, Ebay all do. If your server needs to be accessible from the public Internet then yes. Firewalls are overrated as a protection measure. If you can run them from behind a firewall then I see no reason not to unless you have to open a bunch of ports to allow access to the server in which case the firewall won't help much. This is usually port 80 and it's where most of your attacks will come from anyway.

If only a select group of people will be accessing this server from the Internet then the safest way may be to make it accessible only via VPN. Users would have to log into the VPN first. Much stronger protection than a server behind a firewall with ports open.

Re:Internet servers (1)

kencoe (1474539) | about 7 months ago | (#47566525)

Uhm, this is SO not true. Google, for example has done white papers and research docs, written articles, blogs posts, and practically screamed from the mountain that they use a "no trust" model including a wide range of individual measures on each resource. While firewalls are not used on ALL devices, they are used on many.

Facebook also uses asset level security, including asset level firewalls; discussing this in an article about them signing a deal with Duo Security, and Ann arbor, MI based security company.

Both of these companies have repeatedly made public statements that there is no canned answer for security, and that even individual resources are treated differently depending on case. You should not use random companies for example without knowing that your facts are correct.

Re:Internet servers (0)

Anonymous Coward | about 7 months ago | (#47566835)

Google has very strict firewalls. They even have the same ips for youtube, google, google maps, and all other services. Nest hasn't been added yet.


Anonymous Coward | about 7 months ago | (#47566345)

They can write whatever they want in their contract, but that means jack and shit when it comes to complying with federal regulations. They're required to run a firewall, and if they can't code to comply with that, then you should alert the appropriate regulators.

Regardless of client or application (1)

Virtucon (127420) | about 7 months ago | (#47566351)

A zoned security architecture is always best and implementing intra-zonal firewalls is likewise a best practice however there's always pragmatic considerations because of cost or risk of the information being protected. If any of the servers are Internet facing or face an internal desktop network, that should be firewalled off at a minimum.

Is it common... (0)

Anonymous Coward | about 7 months ago | (#47566373)

... to run mission critical servers on Windows?
It's the only OS on which "to firewall or not to firewall" is actually a question.
On a proper OS you would only have the minimum services necessary open... and a firewall would add nothing.

Interesting Microsoft article on this subject (0)

Anonymous Coward | about 7 months ago | (#47566381)

Microsoft seem to indicate that they do NOT use a firewall in front of their Exchange and SharePoint systems; no UAG, TMG, nothing. BUT, they admit that to do this requires a very different way of managing security. The Application Development and Support people MUST take FULL responsibility for keeping their applications secure, and CANNOT just leave security to the Network/Security teams. The days of securing buggy software by sticking a security appliance in front of it are gone, but many IT departments have NOT caught up with this yet. Networks and Security people still don’t trust Microsoft applications to be secure, while Application people think Security is something Networks or Security people should look after. The perimeter collapsed and nobody noticed....

Bob G.

Re:Interesting Microsoft article on this subject (0)

Anonymous Coward | about 7 months ago | (#47566517)

Having set up dozens of POS systems on Windows, I can say with some authority that you DO need a firewall. A strict network topology can mitigate much of the risk, but there are 0 day exploits available for every Windows OS at all times, guaranteed. It is not a matter of IF that system will get owned, it is a matter of when. As a contractor though, you can pick up some hefty maintenance checks for cleaning out infected POS systems due to negligence, which is how almost every Windows tech I know makes money: repeated cleaning of infected systems and a total lack of ability to secure them.

Software or Hardware? (0)

Anonymous Coward | about 7 months ago | (#47566389)

The OP makes it sound like their environment is not running a firewall at all. Do they have a hardware firewall that sits between the outside and inside? Do they have a DMZ?

If they have a hardware firewall and other security appliances, there's not really a benefit to a firewall on an internal server, and it can get in the way of specific services or necessary apps needlessly.

If they have nothing between the server and the outside, however, then yes, a firewall is necessary.

Well... (1)

thieh (3654731) | about 7 months ago | (#47566401)

Is your firewall "mission-critical"? I meant if your mission involves being accessed from the outside then the firewall is as critical as whatever stuff behind it that you are trying to access.

The vendors are clowns, but not the funny kind (1)

Stolpskott (2422670) | about 7 months ago | (#47566403)

If the POS (point of sale... although if the vendor are as lax about their quality assurance as they are about network security, that might just also stand for "piece of shit") and the back office PC are completely isolated from the internet, then I would agree there is no need for a firewall. However, retail POS systems almost always now come with a built-in credit card payment system instead of having separate terminals for that... so the POS cannot be guaranteed an airgap out to the internet unless the POS vendor is also supplying a separate credit card payment system with separate hardware that will reside on a completely separate network from the POS and back office system.

My advice to the OP would be to register their extreme dis-satisfaction with the setup verbally with the client, and in writing/email to the client and vendor, detailing the concerns about data security. That way, it at least limits OPs liability for the inevitable fuck-up and loss of customer credit card data to the time and effort involved in hiring a lawyer and producing said documentation when the shit hits the fan and law suits alleging incompetence start flying.

From experience, I know that as the 3rd party implementation consultant, you are nothing more than an annoying buzzing sound to the vendor unless you get the client on board, and even then it will still not work unless there are break clauses around client satisfaction built into the vendor-client contract. All OP can really do is cover his/her own ass, do their best to educate the client about the dangers involved, and leave it at that.

No firewall is probably because the vendor is too lazy to figure out how to configure the POS firewall so that they can still connect to it for remote support/maintenance tasks.

How about NO (0)

Anonymous Coward | about 7 months ago | (#47566405)

Back in my consulting days I would throw in an openbsd firewall running on a customer provided machine as part of my services to them. The customer would get the documentation and passwords for it as part of the deal for whomever followed me. It was the ounce of prevention vs the pound of cure. Customer's who wanted wanted to just hang their gear on the internet without it were customers I declined to deal with.

Its true the customer is aways right. But they can be right with someone else. I had a reputation of providing a quality service. Not going to sacrifice my good name and reputation with reports of shoddy work.

with the push to virtualization (1)

0xdeaddead (797696) | about 7 months ago | (#47566415)

we run firewalls on the hypervisor a'la vGW. But a firewall won't stop people from doing stupid things, but it sure makes day to day annoying as shit.

Very common (1)

Lumpy (12016) | about 7 months ago | (#47566421)

For incredibly inept companies that really know nothing at all about security to run without firewalling.

Make sure you have a clause written in that without a firewall your client is fully responsible for any and all damages their unsecured server will cause.

No Excuse really these days. (1)

upuv (1201447) | about 7 months ago | (#47566425)

I do a ton of infrastructure builds. From a few boxes to 1000's of VM's. There is no excuse for no firewalls.

If a vendor is disabling the firewall then they should absolutely be approached. If the clown you are talking to says that's the way it's done then go over his head. Tell your boss.

Be gently of course. Doing the run around my hair is on fire dance is not going to win any one over.

You can even help the vendor. There are a ton of tools for all OS's that will help you determine the port that need to be open. Simply run up the software and scan the open ports. Tada you have a simple set of fire wall rules at least. Are they perfect? Of course not they can be improved on. But it's something at the very least. I'm not overly a fan of point to point rules in firewalls as they are self defeating in the long run. ( This is a longer story )

So yes host firewalls should always be enabled. And the rules you use better be documented.

Yes, but not the way they do it... (0)

Anonymous Coward | about 7 months ago | (#47566433)

There are plenty of mission-critical servers run without a firewall. That's because they provide services (web hosting, DNS, and the like) to the internet at large, and the firewall functionality is built into the server.

This is called a "bastion host [wikipedia.org] ". It runs a severely stripped-down system (for both security and performance reasons), and is usually reimaged periodically from a secure master copy.

So yeah, I do it all the time. There's no need for a separate firewall. But the server is configured from the ground up with a heavy emphasis on security.

Now, did this vendor provide a highly secure OS image and a process for reimaging it if there's a problem? Or did he just give you a binary to install on a generic MS-Windows install?

In the latter case, the vendor is a fucking idiot.

Vendors do stupid things. (1)

Fencepost (107992) | about 7 months ago | (#47566435)

The most recent one I'm dealing with is an IE-specific browser-based EMR (electronic medical records) package that apparently has some issues with newer Flash versions, and by "newer" I mean "released within the past 3 years." They want us to roll back to some version of Flash 10.x (the product mostly works with newer, but has some very annoying delays).

My basic take on this is to go to the practice manager and say "According to the EMR vendor, their requirements are that we run an incredibly insecure configuration. I can do that, but my recommendation is that if we do so, no computer should be able to use both the EMR and other parts of the Internet." It makes me wish we were a Citrix shop; I'd set up a terminal server/app server running that insecure configuration, then just share direct app access via desktop icons for the end users.

It may be common ... (1)

gstoddart (321705) | about 7 months ago | (#47566441)

But it's a terrible idea.

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.

If this is what your vendor is telling you, they're either lazy or incompetent when it comes to security.

My advise, you need to get management to sign off on it to do a little CYA, otherwise someone is going to blame you for this when you get hacked (assume there is no 'if' in this situation).

If they've signed a contract with this vendor saying it "needs" to be ran without a firewall, then the person who signed that contract wasn't reading carefully, or didn't understand what they were signing.

Telling you that you don't need a firewall is like telling you that your car doesn't need brakes -- it should be a giant warning that someone is either lying to you, clueless, or doesn't give a damn.

"Real professionals" are paranoid about security, and don't take stupid risks. Me, I'd go with your assessment of "bunch of clowns".

Yes, this might be a small shop, and with a limited budget -- but hanging your production database outside of a firewall is just asking to get pwned. You can safely assume someone is trying to hack into you right now, because there's a good chance they are.

Really depends on the details (2)

gnu-sucks (561404) | about 7 months ago | (#47566447)

Your post is not clear on what you mean by "without a firewall". There are so many places in a typical setup where a firewall could be placed, and yes, it is safe to leave them out in some situations.

For example, your store has a firewall at the internet connection and everything inside is a private ip address. The cash registers run on their own network, firewall'd away from the other computers in the store, with rules to allow for outgoing credit card authorizations and that sort of thing. Does each cash register need a firewall? Probably not, and it might even be a significant expense to maintain updated rules every time the network needs to be reconfigured.

So yeah, it depends on the entire configuration. The tone of your post suggests that the situation is not good though, and of course, it's a lot easier to argue for a firewall these days than against one.

PCI-DSS or Tokenization (2)

paysonwelch (2505012) | about 7 months ago | (#47566451)

You need to look at the PCI-DSS requirements because this is what dictates the security standards of your network if you are storing credit card information. Specifically PCI-DSS dictates (not your contract) that there needs to be multiple levels of firewalls. Ergo you will need a firewall in front of the web server. You will then need a separate firewall in front of the DB servers. And the preferred setup is a three or more tiered system. Web server with firewall connects to the Application (WCF / web service server) which also has a firewall, which connects to your database server which also has a firewall. Also note that I am referencing hardware firewalls such as a Cisco ASA or a Dell Sonicwall. The servers should also have their own software firewalls enabled whether it's Windows Firewall or Linux IPTables. With that said we are "supposed" to be PCI-DSS compliant and should be for the sake of liability (and doing it the right way). Unfortunately I know many vendors who don't want to spend money on proper setups and run very insecure systems. If you can avoid it don't work for these people and go find a client that has the budget to do things right. PCI-DSS: https://www.pcisecuritystandar... [pcisecuritystandards.org] A better option for a cheap client is to not store any customer data and use a tokenized system. Authorize.Net will store all sensitive data for an extra $10/mo and allow you to skirt PCI-DSS regulations. You should still run a firewall though and be as close to PCI-DSS as possible though. http://www.authorize.net/solut... [authorize.net]

Depends on the industry (1)

thalakan (14668) | about 7 months ago | (#47566461)

Some industries do make it a standard to disable firewalls on everything except perimeter devices. Networking talent is rare in these industries so it makes a certain amount of economic sense. You might be surprised to hear that SCADA and industrial control are one of the industries where this is common.

It's not totally crazy, either. If you know that if anything were to ever get on your internal network, you're going to be more diligent than usual about letting things on it. If you put all your eggs in the perimeter firewall basket and it's pretty good, then what's the problem?

Well, here's a big difference: the guy running your water plant is way different than the minimum wage guy you have running the till. The cashier has more incentive to attack the system, especially if he can get away with running a skimmer without getting caught. But the cashier has physical access to the system for several hours per day! What's the firewall going to do to stop him? He can just reboot the machine into an OS he controls, then turn off the firewall by writing to the disk directly.

There's another more important problem: if SQL Server Express is involved then I'll bet the PoS app is doing cleartext database writes, which might include credit card transactions in the future. If that's the case, the firewall has to be configured to allow these writes in cleartext. Mr. skimmer guy just needs to put a tap inline with the register's network port to get all this data, firewall or not. The app is the problem here.

Security is a people problem. Think about your staff and your vendors and choose them wisely. Until that's done pontificating about firewall best practices probably shouldn't be your first priority.

Where makes a difference (1)

Thyamine (531612) | about 7 months ago | (#47566475)

A firewall between you and the outside world, yes, absolutely. If you have to open ports to your network, that is expected, and you should make every effort to minimize those ports and encrypt when possible. If you can establish a DMZ even better.

Internally you should be maintaining a secure environment anyhow, so there is no need. Between users and vulnerabilities, I can understand why people would want to turn on internal server firewalls, but generally no I don't see that happen. And that's from small to very large corporate entities. Mostly what I see is people who don't know how to manage their networks, or don't understand security, saying 'well I'm going to turn on the firewalls and now everything is Secure'. Most applications on internal networks expect wide ranges of ports to be open, and yes that is normal. If you have the time to manage every server at the port level, go ahead and enable them, but most administrators do not have enough time to handle normal day to day activities, let alone micromanaging networks like that.

It SHOULDN'T be common (1)

darylb (10898) | about 7 months ago | (#47566477)

Seriously. Don't do it.

I had a smallish consulting client from 6-7 years ago that ran their Oracle server on a system that had no firewall protection, because it made it easier for the application server to get to it. It also simplified remote access by a contract developer. As the remote DBA, it was also easier for me, although I advised against it from the beginning.

Sure enough, an intrusion happened (whether my script kiddies or someone more serious I don't remember). The intruders left behind a lobotomized database and who knows how much rootkit. The latter was the bigger issue, as a big part of my job was to ensure that reliable database backups were being taken. I knew I could recover with what I had, but the admins had to know the system was uncompromised.

So...a good day or two of downtime resulted as a new system was built and deployed. (It wasn't a mission critical system, which is why contract offsite DBAs and developers were used.) I restored the database, AND a firewall was put in place to limit all but the most sophisticated of intruders. I also configured CMAN (Communication Manager) to restrict database access itself to known systems only, even though the database wasn't the intrusion vector.

If the system is valuable, or could serve as a gateway to the rest of an internal network, it must have a firewall. MUST have a firewall.

If by "local firewall"... (1)

Anonymous Coward | about 7 months ago | (#47566505)

...you mean the windows firewall, the answer is yes - a thousand times yes.

You need to understand why you need firewalls. (0)

Anonymous Coward | about 7 months ago | (#47566507)

To start with a pedantic nitpick: Strictly speaking most firewalls are packet filters, as they don't look further than TCP (or UDP) port numbers. We'll call 'em firewalls here anyway. That said:

The reason it's been drilled into people to "use a firewall" is that *cough* certain systems *cough* are rather notorious for running all sorts of services, and so opening all sorts of ports to the world, with basically no way to turn them off. On top of that they historically have shaky network stacks that could use a little help filtering out "weird" packets.

If you know what you're doing and use (other) more robust systems where services only get enabled when the administrator says so, then it's not a requirement to run a firewall. If either is not the case then the traditional chicken waving with "enabling the firewall" is likely a better idea than having no firewall.

Above assumes a public network connection. If not, well, the need isn't nearly as pressing. Though we all know eg. SCADA systems are rather notorious for assuming a "safe" network and ending up connected to the public internet anyway. Sounds a bit like your situation is one of these: Assumptions of secure network so insecure configurations (on shoddy systems) are permissible, only not so much in reality. Nothing much you can do except swap suppliers, or hire someone who does know what they're doing and drill better practice adherence into the supplier. Or have them pick a better supplier to swap to.

Not Your Circus, not your Monkeys (1)

robstout (2873439) | about 7 months ago | (#47566509)

Yes, there should be firewalls (Not sure if client side is needed, depends on the AV used on the devices. There is AV, right?). However, with you being a contractor who is not responsible for this aspect of the design, and you notfied your client of the issue, and they told you to back off, its no longer your problem. Depending on how involved you are with the project, you may want a written document specifying that you mentioned your concerns about this, and they decided to not follow your suggestions, simply as a CYA manuver.

Depends (1)

jimmifett (2434568) | about 7 months ago | (#47566523)

tl;dr: Make your professional opinion known politely to the client in writing, with your advice, them let the client decide, and have records of this decision.

While I agree with you that security should be paramount, in reality, it is often trumped by adhoc business needs and costs. The owner/C-level want this or that to be able to happen, even tho you know it's bad security. You explain it, recommend alternative, then go with what they decide, no matter how asinine, provided you like receiving money. Document the decision so that when the inevitable happens, you've covered your posterior.

From the outset, it doesn't seem like the client is taking things too seriously when it comes to data, they are using sql express after all. The client typically doesn't want to be bothered with our techno babble of how they are doing it wrong, they want it to just work and on budget. They purchase service contracts and warranties so that when something does go wrong, they pick up the phone to get it fixed or point fingers of blame towards when legal gets involved. It's all about passing responsibility. That's why you document and get signed off that the client is aware of these shortfalls and that you work doesn't cover any breach due to the shortfalls. The client sure as hell doesn't need or want a pissing match between you and another vendor, even if you are correct.

Don't piss off the client. Call it a day, cash your check, have some beer.

Fences are not Firewalls (0)

Anonymous Coward | about 7 months ago | (#47566527)

When there is only one listener on your server, and only one port permitted inbound or outbound on the firewall, you should ask yourself:

Why am I putting a high latency, trivially DoS'd additional hop in front of my service?

In other words, yes, there are online configurations where no firewall is necessary, and adds no value. Personally, I've run several public facing (as in, a single Interface, public IP) hosts since 1996 and have never suffered a breach, because I actually read my logs and maintain my systems.

Hell, most "firewalls" are nothing but low performance, poorly configured routers, in many environments. If that's the case, put ACL's on your router and remove the firewall.

However, I will say one thing.. I would -never- do this with Windows. Linux? Sure. BSD? Sure. Solaris? Sure. Windows? Nope.

Necessary? (1)

Bert64 (520050) | about 7 months ago | (#47566533)

Assuming the servers are correctly configured and hardened, then a firewall is an additional layer - ie the ports allowed by the firewall will be those ports that you have explicitly opened on the server, nothing else should be present irrespective of what the firewall allows. Wether you then need one depends on your budget, your risk profile, wether you need to comply with any external requirements (like pci-dss) etc.

Personally i have many servers with no firewalls, because having a firewall would add additional hosting cost, additional point of failure, additional attack surface, additional latency, and the servers themselves don't run any services that aren't intended to be open to the internet (and thus everything thats running would be allowed by the firewall anyway).

The benefits of having a firewall in my case - an extra place for logs incase my host is compromised, and the ability to control outbound access if the host is compromised, are outweighed by the downsides. The chance of the host actually becoming compromised in the first place wouldn't be decreased by the addition of a firewall, but you'd have the additional risk that the firewall itself could be compromised.

If its an isolated network... (1)

Yew2 (1560829) | about 7 months ago | (#47566567)

eg. offline - no internet connection - then I wouldnt worry about not having an operating system/software firewall enabled on the 2 systems. Heck, even if you had a linksys giving them shared internet access it could even prevent the RPC worms and stuff from getting in. The day you start surfing on them or otherwise let the internet in then its horrible practice to go without a good edge firewall on that connection; but if the network is entirely offline I wouldnt worry about it. In the larger networks firewalls are independent devices; we no use software firewalls. Oh no..

Severe myopia all around (0)

Anonymous Coward | about 7 months ago | (#47566615)

If a vendor is telling you that a contract dictates to not use a firewall, get it in writing, and then bring this to your customer's attention detailing why this is unwise. While bringing this to your customer's attention, do it in a way that gets them to think about their risk tolerance. E.g. How do they want to handle:

a) Security compromises (machine trojaned, etc, but no evidence of other issues)

b) Demonstrated data loss (hackers steals data, maybe posts it to public forum)

c) Demonstrated public web site defacement (brand damage)

Once you get them to start thinking about these risk, THEN you can start talking about what tools and processes they want to use to mitigate these risks.

Recognize that firewalls do NOTHING to protect against poorly written services. If a vendor has custom code in play, and is talking as you indicate they are talking, I would personally RUN from them as fast as I could. Because even if the firewall is in place, it's a safe bet that an experienced individual could breach the service in short order. The only secure server is an airgapped one (and even not then). Realize that firewalls are only one tool, will not protect exposed services, and need to be one tool of many to be considered in any security process.

Yes. This happens a lot. It sucks. (2)

lwap0 (866326) | about 7 months ago | (#47566631)

In my experience, many smaller companies, especially ones who offer a specific one-off product, this is a common attitude. This means they've done no real security testing on their product, or how their product is deployed and managed in a customers environment. I think it stems from a couple of things: 1) They aren't security literate. They know how to code or deploy, but they can't be bothered to learn and implement security. They have enough to worry about as it is, and security isn't one of them. It's nothing less than willful ignorance. 2) Sometimes it's more nefarious. They don't want anything impacting their customer experience. Two factor authentication? Firewalls? Application white-listing? Those things get in the way of a customer using their code they paid for. They will not endorse or support it. More over, if YOU implement, it could violate your warranty and null any SLA's. Read the fine print. Ultimately, the (real professionals) answer is this: Defense in depth. For a small business (assuming 1-2 workstations as you've described), a premise (ISP) router based firewall will suffice, and then host based firewalls for each individual client/server/workstation. Keep AV installed, and signatures up to date. Implement a basic change management procedure, and ensure everything stays patched and up to date. All of those things can be done for relatively low cost and high yield for security return. Heck, just doing those basic things puts you head and shoulders above many peers.

Risk Assessment!! (3, Insightful)

dclydew (14163) | about 7 months ago | (#47566655)

There are lots of different risks that must be considered when securing a network or system. In my many years of securiy architecture, I've found it make the most sense to create a risk assessment.

Threat x Vulnerability x Impact = Risk

Once you have defined the risks, you can define the best protection method to reduce each risk.

Application firewalls may not be the best protection method depending on the rest of your network security controls. If you have strong network firewalls and every device that connects to the network must be authenticated (and scanned for viruses) before its given an IP address, an application firewall may not reduce much risk. If it doesn't reduce much risk, it may not be necessary.

In business, security is like insurance. You have to justify how much to spend, based on how it will protect us if something bad happens. Further, you have to make sure that whatever the security control is, it doesn't interfere with what the business needs to function. If the database cannot function with a firewall, a firewall is not the best protection method and other options should be considered (Network Intrusion Prevention systems, Data Protection [encryption/tokenization/hashing], Anti-Virus, File Integrity Monitoring, etc). There are many tools available to security professionals today. A firewall is a good tool, but not the only tool... depending on the situation, it may not even be the right tool.

ANY to ANY (2)

Headrick (25371) | about 7 months ago | (#47566691)

I've seen firewalls that simply allow any port on any protocol right on through.

Many PHBs seem to think that merely having a firewall is a panacea for all security issues.

If I hear "but it's behind the firewall!" one more time...

It Depends (1)

mjwalshe (1680392) | about 7 months ago | (#47566739)

Depends on the network design for high security networks yes it is common to have sensitive machines on a physically separate network with firewalls between.


Alioth (221270) | about 7 months ago | (#47566753)

If you are going to be working with credit cards then read NOW and not later the PCI-DSS (Payment Card Industry - Data Security Standard) standards and follow them, or the company could be liable to penalties from your financial institution. Firewalls are indeed mandatory, as is proper documentation, management and review of the firewall rules.

Download PCI-DSS v3.0 here: https://www.pcisecuritystandar... [pcisecuritystandards.org]

Yikes. This handles people's money (1)

Tool Man (9826) | about 7 months ago | (#47566755)

In my humble experience, POS systems are those most forgotten, and least protected once you get on to the network. Few patches if any, and the vendors often squawk about only supporting ancient versions of Windows XP. Yes, the POS systems are probably Windows. Probably no AV either, and quite likely all administered with shared accounts that everybody knows. A firewall is by far the least they should be doing.

no firewall, but something similar (1)

one_who_uses_unix (68992) | about 7 months ago | (#47566859)

Some large (internet scale) services run without a firewall, although typically ACLs on the router serve a similar function. The issue is that firewalls have a hard time scaling to internet scale volumes. (source: I have served as the lead systems architect on very large scale internet infrastructure).

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?