I was having a discussion with a colleague about security. In particular, we were discussing whether or not we should use standard HTML ports for an Internet-facing application. I thought we shouldn't use them because it would increase the risk unecessarily.
When I mentioned this, his response was, "you can't rely on security through obscurity."
I agreed. However, I still insisted that the ports should be changed. My logic was that using standard ports exposes your service to more people, which is insecurity through perpicuity and an unecessary increase in the risk of being attacked.
One example that is sometimes given as an argument against security through obscurity is that you can't just hide your front door with bushes, leave the door unlocked, and expect nobody to break in. This is true, but it doesn't mean that just because you think your house is secure, you should put a note outside that says, "Be back in a week, I put my $50,000 cash in the safe."
By exposing standard ports, you're guaranteeing that every port scanner, even those configured for a minimum scan, will find your server. You may think it's secure, but when a 0-day exploit is discovered, there is a window of opportunity from when it's disclosed to when the patch can be applied on your server where you are vulnerable. No matter how closely you track security vulnerabilities, 0-days are always a risk.
If you're using standard ports, the number of people who are aware that you're running a vulnerable service is going to be many times higher than if you were running on non-standard ports. That means your risk of being attacked before you can patch is also many times higher.
Thursday, March 10, 2011
Security in Consumer Network Products
Security is important for all software and hardware network products. However, when a security vulnerability is found in a consumer-grade product, all too often, I hear the argument that since the only attack vector is from the consumer's LAN, the priority to fix the vulnerability is low. After all, if users have intruders on their LAN, the vulnerability is the least of their worries.
Although this may be true to a certain extent, I still would argue against this. There are some reasons to investigate and address security vulnerabilities that may not be a real-world threat to consumers' data.
First, somebody could have a misconfigured wirelesss router. An attacker could get on their LAN withough their knowledge and wind up accessing their data stored on a NAS because of a bug that "nobody would realistically exploit." To be honest, this falls under the "they're on the LAN, so they have bigger problems" umbrella, but it is always an additional attack vector to consider.
Second, when the public finds out about an obvious exploitable security hole, especially one that is easily fixed, it makes the product and company look bad. People start to wonder what other problems are hidden in your product if you let out something that easy to find and fix.
Granted, not every security bug can or should be fixed, otherwise, you'd never release the product. For example, a potential Denial of Service (DoS) attack on a network device may not be a problem if that device is going to be behind a firewall. Even if an attacker gets on the LAN, are they really going to try to crash your media player?
However, regardless of the likelihood of a vulnerability being exploited, each known vulnerability should still be investigated to see how they might affect your product. I've seen cases where a DoS vulnerability was being triggered by a third-party device that was unintentionally sending malformed packets. We got reports from users that their device was crashing for no apparent reason. The logs didn't help, and we were unable to reproduce it. It was only after running a security scanner against the product that we found the vulnerability and were able to tie it to the crashes reported by users.
Of course, the stakes are raised when dealing with SMB or enterprise products. Even with consumer products, once you expose a single port to the WAN, security becomes critical, not just important.
Although this may be true to a certain extent, I still would argue against this. There are some reasons to investigate and address security vulnerabilities that may not be a real-world threat to consumers' data.
First, somebody could have a misconfigured wirelesss router. An attacker could get on their LAN withough their knowledge and wind up accessing their data stored on a NAS because of a bug that "nobody would realistically exploit." To be honest, this falls under the "they're on the LAN, so they have bigger problems" umbrella, but it is always an additional attack vector to consider.
Second, when the public finds out about an obvious exploitable security hole, especially one that is easily fixed, it makes the product and company look bad. People start to wonder what other problems are hidden in your product if you let out something that easy to find and fix.
Granted, not every security bug can or should be fixed, otherwise, you'd never release the product. For example, a potential Denial of Service (DoS) attack on a network device may not be a problem if that device is going to be behind a firewall. Even if an attacker gets on the LAN, are they really going to try to crash your media player?
However, regardless of the likelihood of a vulnerability being exploited, each known vulnerability should still be investigated to see how they might affect your product. I've seen cases where a DoS vulnerability was being triggered by a third-party device that was unintentionally sending malformed packets. We got reports from users that their device was crashing for no apparent reason. The logs didn't help, and we were unable to reproduce it. It was only after running a security scanner against the product that we found the vulnerability and were able to tie it to the crashes reported by users.
Of course, the stakes are raised when dealing with SMB or enterprise products. Even with consumer products, once you expose a single port to the WAN, security becomes critical, not just important.
Subscribe to:
Posts (Atom)
Posts
