Forgot your password?
typodupeerror
Networking Security IT

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

Posted by Soulskill
from the common-enough-to-make-you-sad dept.
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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Its Fine. (Score:3, Funny)

    by Anonymous Coward on Wednesday July 30, 2014 @10:06AM (#47566127)

    Everything is Fine.

    • Re:Its Fine. (Score:4, Insightful)

      by beschra (1424727) on Wednesday July 30, 2014 @10:10AM (#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.

      • by scubamage (727538)
        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 si
        • Re:Its Fine. - not (Score:4, Informative)

          by Anonymous Coward on Wednesday July 30, 2014 @10:45AM (#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.

          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)

            by scubamage (727538) on Wednesday July 30, 2014 @10:53AM (#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.
            • by BitZtream (692029)

              Your trainer was an idiot, not a network admin. Oracle database and the various Oracle apps I've used have no silly issues with firewalls. They may have some apps with issues, but not the main product which uses a single consistent TCP port for connections.

              • by Zmobie (2478450)

                To be fair, just because the network is properly setup and allows for certain behavior etc. does not mean the application will play well with that setup. I've seen it happen before (and have been able to demonstrate it with proprietary software) that sometimes the network will not react correctly with certain network setups. At my company we have had to implement special protocols and features in our software just to overcome some inherent network limitations that our IT group pretty much said, "we have n

              • Re:Its Fine. - not (Score:5, Informative)

                by scubamage (727538) on Wednesday July 30, 2014 @11:39AM (#47567245)
                FYI, oracle requires ports from 1024-65535 to be open for any client. 1521 is only used for initial setup dialog. This also forks a new oracle process, which gets its own socket. Afterwards, as stated above, this information is sent back to the client which reconnects on the new socket. This oracle doc explains what I am talking about: https://asktom.oracle.com/pls/... [oracle.com]
                • I setup all our Oracle databases.. (Many, many of them). Only port 1521 is open in iptables. (actually, for some, I have secondary listeners).. The Junipers also ONLY allow access on port 1521, (and a secondary, if specified)
                  I have never had issues connecting to the database.

                • Highly uninformative post as it doesn't mention this situation is only for NT. On UNIXes, port 1521 (or whatever port is selected in installer) is enough.

                  Oracle's emphasis is rarely on Microsoft's operating systems. Not only in RDBMS, but many other products support UNIXes primarily, and Microsoft's operating systems secondarily.

            • Re:Its Fine. - not (Score:5, Insightful)

              by Bacon Bits (926911) on Wednesday July 30, 2014 @03:42PM (#47569541)

              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.

        • 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.
    • and we don't keep logfiles, so we don't have to worry about checking for breakins and cooptions. hey, we don't comment or document our code, either, it's just us two guys. that way, we get to keep all the millions.

      hang on, the phone just started melting and my screens went blue...

  • Common? (Score:5, Insightful)

    by bengoerz (581218) on Wednesday July 30, 2014 @10:09AM (#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.
    • 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?!)...
      • 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'

    • Re:Common? (Score:5, Informative)

      by Shortguy881 (2883333) on Wednesday July 30, 2014 @11:58AM (#47567465)
      I worked in the restaurant point of sale industry for a few years and one thing all the business owners had in common was technology illiteracy. They have no idea how things like this can impact their business, especially when it comes to credit cards.

      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.
  • by i kan reed (749298) on Wednesday July 30, 2014 @10:09AM (#47566151) Homepage Journal

    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.

  • by RichardJenkins (1362463) on Wednesday July 30, 2014 @10:10AM (#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.

    • by Maxwell (13985)

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

    • by Anonymous Coward on Wednesday July 30, 2014 @10:26AM (#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.

      • by bickerdyke (670000) on Wednesday July 30, 2014 @10:45AM (#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)

        • by praxis (19962) on Wednesday July 30, 2014 @10:52AM (#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.

      • by Bert64 (520050)

        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.

        • by gstoddart (321705) on Wednesday July 30, 2014 @10:56AM (#47566717) Homepage

          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.

          • The original post was about the firewall on a host vs. the network firewall. The network firewall prevents people going around mapping ports on systems. Heck, unaltered raw NAT does that which is why people fought to keep it even in IPv6.

      • by Maxwell (13985)

        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.

    • by plover (150551) on Wednesday July 30, 2014 @11:30AM (#47567137) Homepage Journal

      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.

  • It Depends (Score:5, Interesting)

    by MightyMartian (840721) on Wednesday July 30, 2014 @10:11AM (#47566201) Journal

    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 127.0.0.1. Do I really need to configure iptables?

    • Re:It Depends (Score:5, Informative)

      by i.r.id10t (595143) on Wednesday July 30, 2014 @10:39AM (#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 (Score:4, Interesting)

      by bleh-of-the-huns (17740) on Wednesday July 30, 2014 @10:49AM (#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.
    • by mlts (1038732)

      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

    • Yes you should config iptables, If you thing all it's supposed to do is block inbound access your not really using it well. You should be locking down outbound as well per user/group. So rules for a LAMP stack box might only allow some very specific outbound connections from nobody, outbound packets to your log server, outbound connections to your config server and inbound connections to SSH from your jump box. Frankly I would not run a LAMP box in the modern day rather splitting up a web server box a D

  • PCI Compliance (Score:5, Informative)

    by ebrandsberg (75344) on Wednesday July 30, 2014 @10:12AM (#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.

    • by EvilJoker (192907)

      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.

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

  • by Anonymous Coward on Wednesday July 30, 2014 @10:12AM (#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.

  • 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: (Score:2, Informative)

      by roman_mir (125474)

      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 machi

      • by mlts (1038732)

        Next to using POS machines which are basically a 3151 terminal, a cash box, a PINpad and a credit card swipe item, I'd say this is the best approach one can get in this line of work.

        Only thing I'd add would be some way of protecting if someone decided to hop onto the POS network (physically unplugging a cash register, plugging in their laptop.) This could be somewhat solved by a smart switch that locks ports to MAC addresses for starters. Not "serious" protection, but will stop some kid trying to get on t

  • Picking battles... (Score:5, Insightful)

    by Kookus (653170) on Wednesday July 30, 2014 @10:15AM (#47566243) Journal

    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.

  • by bluefoxlucid (723572) on Wednesday July 30, 2014 @10:17AM (#47566269) Journal

    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.

  • 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.
  • by scubamage (727538) on Wednesday July 30, 2014 @10:21AM (#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."
  • 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.

  • 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 P

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

  • 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

  • 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 confi
  • 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 l

  • by gnu-sucks (561404) on Wednesday July 30, 2014 @10:34AM (#47566447) Journal

    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.

  • by paysonwelch (2505012) on Wednesday July 30, 2014 @10:34AM (#47566451) Homepage
    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]
  • 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

  • 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 sm
  • 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 lobotomi

  • 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 addi

  • 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
  • Risk Assessment!! (Score:4, Insightful)

    by dclydew (14163) <dclydew@gmail.com> on Wednesday July 30, 2014 @10:51AM (#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.

  • by Headrick (25371) on Wednesday July 30, 2014 @10:54AM (#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...

  • 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.
  • 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]

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

  • 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).

  • You simply don't know the future security bugs that will affect your infrastructure. Just look at http://www.cve.mitre.org/ [mitre.org] or any distribution security announcement like https://www.debian.org/securit... [debian.org] . Security bugs are discovered all the time. With this fact in mind you realize that you need more than a single protection layer to get a chance to detect and drop a harmful traffic. The bug could be deep into the kernel, making almost any magic possible from the application point of view. Having only a

  • by nine-times (778537) <nine.times@gmail.com> on Wednesday July 30, 2014 @11:08AM (#47566889) Homepage

    Honestly, determining whether you need a firewall isn't as simple as "yes, always, all the time" or "no you don't need one." You have to know what the firewall is doing, and what security is required. You can set up a firewall, allow all ports to be forwarded through without inspection, and while you have a firewall, it's not helping you. Or you could have a server running a secure OS with only the vital ports opened, without access to anything other than the Internet, in which case a firewall probably isn't doing you a lot of good.

    Also, it seems you're talking about a software firewall installed on the server? I wouldn't trust it. If I'm running Internet accessible servers, I generally want separate hardware firewall, and I want to put those servers into a separate DMZ if I can. I might leave the built-in Windows firewall turned on if it's not causing any problems, but if I have to disable it, I don't worry too much about it because I have the hardware firewall.

    A properly secured Linux/Unix server should be able to sit directly on the Internet without issues, but you may as well put it behind the hardware firewall if you have the option.

    But are we talking about disabling the built-in software firewall on a machine that's only accessible by other computers on the LAN? That's probably fine. You should have some security preventing unauthorized personnel from accessing the LAN, and I would assume the SQL databse it password protected, right?

    I guess my bottom line here is this: Since you can't trust a the built-in Windows firewall to actually protect from very much, you shouldn't worry too much about disabling it. Make sure your network is secure without it.

  • by metrix007 (200091) on Wednesday July 30, 2014 @11:13AM (#47566941)

    A firewall will not stop most attacks. A firewall has to allow traffic to the services that are permitted (duh), and so that open channel, attacking and exploiting the service is what will allow the attack.

    A firewall could not stop that by design.

    If an internet facing server is secure correctly, there is no need for a firewall in front of it.

    There is however a need for a firewall between the DMZ (which is where this server should be) and the internal network, to prevent access to the internal network in the event the server in the DMZ is compromised.

    • by smash (1351)
      A firewall can be useful to limit the spread of malware on your internal network. The days of relying on an edge firewall only are over.
      • by smash (1351)
        And to clarify - yes you need to open ports on the box, of course to provide services. But there is zero reason that you should be enabling non-user facing traffic to be sent or received to/from the box from end user machines.
  • After all, this is the vendor's recommendation, which should be in writing anyhow. Have the vendor sign a waiver accepting full responsibility for any damages and liability that could be attributed to not using a firewall I am sure that the company lawyers would be very eager to have something like this in place.
  • The Vendor will have issues with their product running if you do not configure the firewall correctly and will cost the Vendor support time.
    If you get hacked because you let malware onto your POS systems or put a compromised machine on the network it is your problem.
    A firewall will just prevent an exploit of a service. So only run the services you need. The real issue for this POS would be an exploit that gains access to the SQL server and a firewall is probably not going to stop that.

  • yes it is common (Score:4, Informative)

    by smash (1351) on Wednesday July 30, 2014 @11:25AM (#47567075) Homepage Journal

    ... because muppets pretending they know how to adminster a network are common.

    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?

  • You said they disabled the local firewall. That's how I'd run most Windows servers on a network of any size, because the local firewall just eats up resources on the server that could be better used for the server's actual job. The firewalls should be proper hardware firewalls built into the networking infrastructure located a) between the outside world and the client networks to control access to the network in general, b) between the POS terminal segment and the server segment to control what access the t

  • by maz2331 (1104901) on Wednesday July 30, 2014 @11:28AM (#47567103)

    That design tells me that you need to put a PCI-compliant hardware firewall between the POS and its associated DB server, and the rest of the internal network. And you also need to have a firewall logger that is actually looked at daily, plus you need to do vulnerability scans both internally and externally. A Windows firewall is not sufficient and won't meet PCI DSS requirements in any event, ever, and isn't going to provide any benefit if the firewall between the POS network and the rest of the store/enterprise is in place.

    Any device that processes, carries, or stores ANY credit/debit card data that isn't encrypted *must* be behind a firewall that only permits it to send traffic to specific hosts that are necessary for the functioning of the system, and even then only on the bare minimum number of ports, and almost all inbound traffic is denied as well.

  • If you don't run a firewall and you and your clients are the only one trying to connect to your server, then people see that running a firewall only interferes with things working. Meetings with management are really fun when they run along the lines of "We turned security on and things started breaking.", "Then turn off the security". So if no one is attacking you, you might make it to market faster with less resources than your competitors when only dealing with security after an incident.
  • by ErichTheRed (39327) on Wednesday July 30, 2014 @11:31AM (#47567149)

    My job requires that I deal with a lot of, to put it politely, vertical market software companies. As in, they're the only game in town for that particular function in the industry I work in. It's extremely common to see stuff like this, and it's usually justified by saying "firewalls won't protect you anyway, so why bother?" I only slightly agree -- in my mind the most important thing is to severely limit the use of admin/root accounts and protect their passwords, since you can shut off any security measures once you're through the door.

    Usually, it's just laziness on the part of the vendor. The software is assumed to be running on a closed network with no external access in many cases, and a lot of people don't get that even closed networks aren't really closed anymore. I'm completely platform-agnostic, but I've noticed this a lot with typical Windows DCOM fat client / SQL Server (or worse, Jet/Access DB) pairings. As soon as you try to run these securely on a general purpose desktop, you find that port-based firewalling is very difficult to do without opening a huge range of ports due to the way RPC works. Yes, there are workarounds, but in general the protocol is not firewall-friendly. And, the golden rule of vertical market software is "thou shall not upgrade thy technology stack, ever." I do desktop systems integration -- OMG, getting poorly coded VB6 applications working on Windows 8 is a nightmare even with the compatibility toolkit, etc. Not sure what it is with the market segment I'm in, but I see lots of VB6 married to a Jet database, and lots of craptastic fat Java applications. Both can be killers to fix and get working without access to the code/programmer.

  • by ewenix (702589) on Wednesday July 30, 2014 @11:34AM (#47567179) Journal

    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.

  • by roc97007 (608802) on Wednesday July 30, 2014 @11:48AM (#47567359) Journal

    My current company has a firewall for the incoming internet connection. (What sane company doesn't?) We also have individual firewalls on each PC but no individual firewall on any server. I'm not a network administrator -- it's a black box from my viewpoint, but I can rattle it and guess what's inside. The servers, I believe, are protected in two ways -- (1) to get out on the internet, you must go through a proxy, and the servers do not know how to do that. (2) traffic on the server subnets are blocked by the internet firewall, except for a few in a designated DMZ. We run into this all the time when applications have features that report back to vendor tech support, but are always blocked by the firewall. (In one case we had an application that would hang when it couldn't make an ftps connection with the vendor's tech support site -- who the heck uses ftps anymore? We stopped using that app.)

    So to answer your question, a well designed network will have clients that can get to the outside through a proxy server, and servers that can't get to the outside at all, and servers that can cautiously get to the outside from the DMZ. The servers that are blocked from getting to the outside by the network don't necessarily have to have individual firewalls, and in fact, local firewalls can cause problems with some applications.

    Now, if you're running the back end part of the system on a local PC that can also get out on the internet... whoo boy... that sounds dangerous.

  • Unless *all* datafiles on your client's system are encrypted, also, and I don't think even that's enough.

    ObDisclosure: I worked for about 4 months on a contract at Trustwave, a root CA.

    Leaving that huge hole in your defenses... I suggest you look, if you don't already know, at .

    From the 1.2 std: "Firewalls are a key protection mechanism for any computer network. Other system components may provide Firewall functionality, provided they meet the minimum requirements for Firewalls as provided in Requirement"

    Even all data between two systems *MUST* be encrypted, for full compliance, if you're doing your own.

    So, what this vendor is doing... I'd say you and your client need to reread the contract *VERY* closely, and if they say they're adhering to stds, they're in violation of the contract.

                            mark

  • by bferrell (253291) on Wednesday July 30, 2014 @11:52AM (#47567393) Homepage Journal

    "A firewall is a MUST".... However

    1.) If you are a contractor (or an employee for that matter), and you're explicitly told not to do something, document your concerns, in writing and either do what they tell you or quit. This covers your butt when thing blow up. Note I said, when, not if. You don't get to dictate the business objectives in either case (contractor or employee).

    2.) The networks/firewalls are only one part of the picture. I've noted other posts asking questions concerning the surrounding environment. These are good, even if they don't address point (1.) If a "best practice" for an element in the environment breaks the environment, then the "best practice" is invalid and MAY be ignored. It may also be that the app in question is brain dead, but that's a whole 'nother topic.

    I've seen way too many "best practices" that do not account for the specific environment and even more "checklist" jockeys who can't figure out how to make things work without them. Learn to do more than to follow a flowchart/checklist.

  • by WaffleMonster (969671) on Wednesday July 30, 2014 @01:50PM (#47568499)

    This whole "network security" meme is a failed experiment needing to be called out as the ridiculous farce that it is. Firewalls are the equivalent of mounting castle defense against an airforce. It does not work and never has. The opportunity cost of squandering resources on castle building vs standing up an opposing airforce is both high and sad.

    Host-based firewalls are even more amusing. They come enabled by default. High probability any application installed needing to listen() is going to automatically punch a hole to do so as vendors have zero interest in dealing with firewall support nightmares. This begs the obvious.. what is the effective difference between listen() and firewalled-listen() ?

    If you really want a secure internal system then lock down services/listeners and configure each system to use only secure communication protocols. If this is not possible set IPsec = required and secure the transport E2E only.

    The further away from application domain you apply security the increasingly worthless that security is.

  • by dominux (731134) on Wednesday July 30, 2014 @02:05PM (#47568643) Homepage

    There are firewalls and firewalls. If you have a box with port 80 listening and nothing else listening, and you install a firewall that blocks connections to ports that are not port 80, you haven't really added a whole heap of useful. If you have a firewall that allows port 80 from anywhere and ssh connections only from a particular subnet, then maybe the firewall is earning it's keep. If you have a firewall that warns you about outgoing connections from your server that might be to command and control botnet servers if it gets compromised, then maybe it is worth doing. If you have a stateful firewall that is doing traffic analysis and shutting down particular attacks on your server then great. Shutting closed doors just for the sake of buzzword compliance is not a useful function.

Moneyliness is next to Godliness. -- Andries van Dam

Working...