Obscurity. Security. Reality.

1 August 2012 by 22 Comments

It was only a year or two ago that I was informed I no longer need curtains in my house. “So long as your door locks are strong, and the house well designed,” it was said, “hiding your valuables really doesn’t make them more secure. Quit fooling yourself and simply take those curtains down, so everyone can see everything. You won’t miss them after a while.” More recently, I’ve been told door locks really aren’t needed, either. “The end of the door lock age,” I’m told. So long as you have a really good alarm system, combined with cameras that record everything, door locks are really not needed. They’re simply old fashioned, passe, just not needed at all.

Or so you would believe if you listened to the security folks in the network world. “Obscurity is not security,” we’re told. Don’t bother with route filters and network address translators, because they only obscure your devices, rather than secure them. I’m reminded of one of the sayings drilled permanently into my head through Biblical Hermeneutics: “When you take the text out of its context, you’re left with a con.” Obscuring your cipher certainly isn’t a good way to keep people from breaking your cipher, but networks aren’t cryptography problems, they’re networks.

“The age of the firewall is over,” we’re told. “So long as applications are properly built, and you have a solid IDS system, firewalls are just making your life complicated.” The complexity we’re talking about here is the complexity of layer 2 domains stretched out of any sort of natural shape, not sane network designs.

Let me be blunt for a moment (or have I been blunt enough already?): obscurity isn’t security by itself, but it’s a perfectly valid tool in a suite of tools designed to provide a secure system. If you don’t think it is, then please, feel free to wander onto any battlefield in an international orange jumpsuit. Let me know how it turns out. Firewalls aren’t the end-all, be-all of security, either, but they are yet another element in a suite of tools designed to secure a system.

My house has curtains because not letting people know when I’m home (or not) is one of the simplest things I can do to provide cover. My house has door locks because door locks at least slow down the thieves in our midst, provide me with some notification that someone is trying to enter where they shouldn’t, and they keep people who really aren’t all that determined out. My house has an intrusion detection system, and a video recording system, too. You probably don’t want to know what waits for you at the top of the stairs if you get that far, either.

All of these things are tools in a complete system. So long as they’re used for what they’re useful for, there’s no problem with using them. The problems start when you think any single point of security is going provide all the security you need, or when you forget that every layer in a security system has its place and its purpose.

Applications should be hardened, yes. Servers should be hardened, yes. But preventing attacks in the first place adds a layer of security on top of the application and server hardening. And keeping eyes out that shouldn’t be there in the first place makes the attack vector harder to find in the first place.

We need to remember that security is a mindset, a set of tools, and the proper use of those tools. Don’t use a hammer for a screw, but also don’t think screws can solve every fastening problem on the face of the Earth.

 

Filed Under: Blogs, Security Tagged With: , ,
About Russ White

Russ White is a Network Architect who's currently looking for a new challenge. He's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. If you want letters, well... BSIT/MSIT (Capella University), CCIE #2635, CCDE 2007:001, CCAr. So there.

  • http://showbrain.blogspot.com Ben Story

    I agree that obscuring things is a valid tool. Unfortunately things like NAT, cloaked SSIDs and such often become magic pills in non-technical managerial circles. This can then turn into a problem when trying to justify other in depth security tools.

    • riw777

      Yes –the problem is when we try to make any tool or process “the magic key” to security. It just won’t work, no matter whether it’s crypto, obscurity, or anything else. Thanks for the comment. :-)

  • packetu

    Good read and great points. I wrote a smilar article yesterday. The point I attempted to make was that crypto and authentication controls are always built around some form of obscurity. The thing we have to understand is the amount of entropy and how to mitigate brute force (for online and offline controls). For example, an authenticator needs a lockout, while symmetric key crypto needs short key lifetimes. Since authorization and accounting first requires authentication, it is my opinion that all logical controls are built around obfuscation. Only physical controls lack the need for obscurity. So in our world of infosec, obscurity is security. We just need to be very obscure :-)

    • riw777

      A very valid point –while the algorithm might not be secure, the key is obscure, and the obscure key is used to generate an obscure cyphertext. This is where I was trying to go with the “context – text == con” point, but I didn’t quite get there, so thanks for bringing it up.

  • http://twitter.com/MrsYisWhy Mrs. Y.

    I think there’s a difference between obscurity and OBSCURITY. I’ve seen people do strange things in the name of security. For example, changing the default Sendmail SMTP port and failing to tell the users. Well, that *would* make it secure. Or replacing certain binaries in /usr/sbin and /usr/bin with shell scripts that call the real ones and send alert emails to various staff members. Try figuring out how to modify that. I think there’s a middle way here, but I frequently see security professionals go off the deep end, forgetting that the whole point of a network is for the “fire to go through the wire.”

    • http://www.packetu.com/ Paul Stewart

      I look at changing a default mail port as very weak. That’s like 16 bits of entropy per TCP stack. So the equivalent of like a 2 character password. There are mitigating controls that could be applied in both cases. For example account lockout (for the 2 character pw) or IP blocking (when a sweep against the mail server occurs).

      I look at all logical security as obscurity. All authentication and crypto is based on some obscure element. I like the analogy of obscurity vs OBSCURITY and would love to hear those contrasted. To me, it is the degree of obfuscation that must be understood. Then we have to deal with brute force attacks by detecting them or using short lifetimes for the element of obscurity (key, password, etc).

    • Russ White

      Agreed –which is why I think it’s important to understand each tool, what it’s useful for, and then restrict it’s use to that set of uses. Engineers tend to err by flipping back and forth between extremes (or maybe network engineers aren’t unique in this regard). Being conscious of the problem at hand, and the limitations of the tools at hand, might help to dampen the flapping a bit… :-)

  • Neil Anderson

    I’m one of those who says that the age of the traditional firewall is over, not because I think they’re totally redundant, but because they are not really delivering any tangible level of security any more. The vast majority of attacks now take place at the application layer rather than exploiting protocol vulnerabilities, so a traditional firewall only filters out a tiny fraction of suspicious traffic.

    For my money, traditional firewalls are no more than a speed bump.

    That’s not to say that we shouldn’t deploy firewalls at the perimeter of the network at some level (even if it’s just a filtering router to cut out the crap on the edge) – in almost all cases we should. We just shouldn’t expect them to stop an attack. In my opinion genuine attacks can only be prevented by using application layer inspection to detect and prevent attacks.

    And while obscurity _can_ be a valid security tool in combination with proper security measures, it can also increase a system’s vulnerability to attack and exploitation. It therefore needs to be used carefully, and in combination with other, more robust, strategies.

    • cjinfantino

      Even if most attacks, real attacks that is, are at the application layer, it doesn’t mean you shouldn’t protect against the script kiddies. A firewall won’t stop real hackers, but it is like having your doors locked – it will protect against the lazy, the unimaginable.

      So firewalls do protect to some varying degree. I think the question becomes, is it worth the headache to support and maintain it.

      • Neil Anderson

        Indeed, which is why I say that firewalls are only really useful for filtering on quite a broad basis. The number of places I see where the firewall as the only network security measure is pretty scary.

        It’s now got to the stage that firewalls are essentially just a black box that you drop in with some broad filtering, set up logging and leave it alone. They’re essentially infrastructure rather than security measures.

    • http://www.packetu.com/ Paul Stewart

      I agree with everything you are saying, up to the last paragraph. Well I agree with that too, but there is a point that obscurity is all we have certain controls. That point is authentication and encryption. I cannot think of any authentication or encryption solution that is not based on some sort of obfuscation. However, some obfuscation techniques can have a lot of entropy and is computationally unfeasible.

      To your point with firewalls, they are a speed bump. What they really do is allow us to focus our efforts. Exploitation happen through applications. By properly using a firewall, we can block all but what is necessary. That keeps other applications that are intentionally or unintentionally listening from being a likely attack vendor. With that being said, our industry would be taking host and application security much more seriously if firewalls weren’t depended on like they are. Focusing of efforts on host and application security would be a huge win.

  • Jerold Swan

    The problem with traditional firewalls isn’t that they don’t increase security, but that they are priced completely out of proportion to their benefit.

  • robertjuric

    I still don’t believe that NAT is any sort of obscurity feature that has security benefits. It’s not like you’re hiding your valuables, you’re just changing their names. They’re still there and reachable if you firewall is open to them. Masking their real IP address, IMO, has no tangible benefits and breaks way too many things in networking to justify its existence.

    • http://www.packetu.com/ Paul Stewart

      So my response to the value added by NAT (from a security standpoint) would vary depending on the specific definition of NAT. For example one to one NAT has absolutely no value from a security standpoint. Dynamic PAT has some value. Sure, it may or may not block inbound traffic to the RFC1918 address space. However, if it doesn’t the bar has still been raised (you’d have to compromise the upstream router and tunnel or use source routing). Also, it would be possible to entice a host to send traffic and create dynamic NAT entries. I absolutely agree that this is nothing compared to SPI or CBAC. I also agree that no one should EVER refer to PAT or NAT of any form as a firewall. However I’m sure an attacker would prefer to attack a naked host on the internet, than one setting behind a PAT (aka NAT overload) router.

      • robertjuric

        PAT is the worst kind of NAT and would never block inbound traffic. Only the firewall would do that. A server with a unique global address, as compared to 3 servers sharing a global address is not any more naked. An attacker doesn’t care what IP address the server is using, the attacker only cares about services running and available for exploiting. If an unpatched web server is public facing, whether it’s using a unique global address or being NAT/PAT’d to a global address it is still an unpatched webserver.

        • http://www.packetu.com/ Paul Stewart

          I would have to disagree. The only point I will agree on here is that it will is your example of the public web server. The server would be powned in most cases with a vulnerable or unpatched www server. This is not a PAT issue nor does it mitigate my claim in any way. This is exploit would happen with a traditional firewall as well. The only ways to prevent this is to do one of the following:

          1) use a good waf
          2) use hips/hids
          3) use something integrate like modsecurity
          4) use a good network IPS
          5) use a fw that employs checks all the way up to the application layer
          6) actually patch and harden the service

          The reason PAT helps is not because it would do anything for the WWW server. You are on the right track there. However since the PAT rule would have been created for only the web server, the remaining 65534 TCP ports, and other 254 IP protocols are not exposed for attack. Again, unless you can source route or tunnel to the service provider and convince their router to deliver to an RFC1918 destination.

          PAT is certainly not the worst type of NAT from a security standpoint. The real risk with PAT/NAT and traditional firewalls is a false sense of security. There is definitely some benefit from PAT, but I’d never classify it as a firewall. To a degree, firewalls suffer from the same problem.

          As in your example, the real vulnerability was in the application. Any false sense of security that leads us away from application hardening is dangerous. Firewalls (and static PAT to a degree) limit applications that are exposed to the world. In your example, the www server was owned. That server may have had an ftp instance that allowed anonymous write and read. That wouldn’t have been directly exposed since the www server was the exposed port.

          • robertjuric

            I see what you’re saying, but you’re saying that PAT is adding the security by not allowing certain ports through and I’m saying the firewall is doing that function. The other ports and protocols that you mention not being open because of PAT would also not be open because of the firewall DAPE(Deny All Permit by Exception) policy. That’s almost like saying Routing is a security feature because if you can’t reach a network you can’t attack it.

            But either way open ports is not the reason why most people feel like they need NAT/PAT. Most people feel that an actual global address on their server, and not a masked address is more secure. This false sense of security that people believe NAT provides is exactly why people are trying to bring NAT into IPv6 when it was never intended or designed to be done so. (And I’m not talking about IPv6 transition methods utilizing NAT).

          • riw777

            I tend to see NAT and PAT as being part of the “fail closed” doors of a network facing the outside world.

            Security isn’t just about hardness, it’s also about brittleness. The springs on a door that auto-closes don’t seem to do much in everyday life, but when they auto-close the door into the back room of a retail establishment, they are a crucial piece of the overall security system. In today’s networking world, we’d look at the springs, say, “springs aren’t security,” and discard them while puzzling over how to make the perfect lock for a door everyone forgets to close. :-)

            If the security mechanisms along the edge of a network fail, no matter what those security mechanisms might be, they should fail in a way that prevents the network from being reached at all, rather than opening the network to any and all traffic. Using addresses that simply can’t be reached from outside of the network, even if there’s an open wire into the network, can be one component of a “fail closed” design.

            So I don’t see NATs or PATs as a way to block ports, but rather as one part of the door that closes behind you when you walk through it. They’re a hassle sometimes, but they’re a hassle you live with in the context of building a complete system.

          • robertjuric

            I understand what you’re saying and I think that is very valid reasoning. However I think if you’re building any sort of complete system you can do so without NAT/PAT and not compromise security. I don’t see the reasoning in living with a hassle that can so easily be removed from our networking lives without affecting the security of our networks.

          • http://www.packetu.com/ Paul Stewart

            Okay, I see where you are coming from completely now. You are coming from the perspective if NAT/PAT adds value in an OTHERWISE properly secured network. In that case, I agree that it is unnecessary, doesn’t add value and is a hassle.

            I was coming from the perspective of a host that had no firewall in path. The host would not have had proper server or application hardening on ANY of the exposed ports. From that very scary position, I think static PAT through to the one port is better than a public address on the server.

            From an operational standpoint, you are absolutely correct. PAT is the worse kind of NAT.

  • Michael Gonnason

    Firewalls mainly tries to control the scope of a given hack. Yes the firewall might not stop the initial hack, but it should prevent the hacker from turning your server into a FTP server, or to use it as a relay point further into the network. (Hopefully no host in a DMZ can initiate RDP/ssh/telnet/other interactive session into an internal host.)

    • NeilTAnderson

      IMO, stopping the hacker turning your server into an FTP server or pivot point into the rest of the network is a job for HIPS, _not_ the firewall. After all, if your server is pwned, and you’re relying on outbound rules on your firewall to prevent a control channel or whatever being established, you’ve already lost.

      It’s perfectly possible to tunnel a shell through HTTP (or even worse, HTTPS!) and I’m fairly sure that those ports will be open on most firewalls for at least some hosts ;)

      Sure, the firewall should be filtering out stupid stuff like telnet (and I hope to $deity that your server admins aren’t stupid enough to be running telnet) and obviously spoofed source IPs, but don’t expect a firewall to prevent an attacker from exploiting and controlling a vulnerable service.