Let’s look at a scenario.
Most security managers will limit the ports users can use going out to the Internet. You typically allow http and https, and maybe ftp. It just doesn’t make sense to allow “Any” out to the Internet. This will limit your attack vectors by not allowing IRC and other such dangerous protocols. There are also other things you can do to block what the firewall won’t see (protocol blocking, proxying, layer 7 filtering, etc.).
In the same manner, most organizations block incoming ports as well if they are not needed. Why allow http or ftp traffic in if you don’t have a web or FTP server? But if you do have these types of servers on your network, you might implement another layer of security by using non-standard ports on your webservers to help combat ID theft and other attacks. Basically, instead of using port 443 for SSL, you might set something like 8000 or 8700 or 8900… And many security admins and managers attest to the success of this approach. They claim to see fewer attacks because your typical script kiddy is going to be using scanning tools to look for standard ports and will just skip over those sites without those ports. Makes sense. Colleges and universities are a big advocate and user of this approach.
But what about the security admin / manager who practices limits the ports his users have access to but also has a user staff with a high percentage of professionals who have to access those very schools and other organizations that implement this type of security by obscurity (SBO)? Many are working on their degrees. Many are researchers that have regular access into university networks. These are legitimate needs for these types of professionals, so he can’t say “too bad, do your work at home”. If they were all accessing one or two different networks, then no big deal, but it just ain’t that simple.
What you have here is a “security collision”.
Basically, the security manager of the organization with staff trying to access these sites using SBO has to open ports to allow the traffic. But then you cause potential security problems because malicious insiders and malware (bots, etc.) might take advantage of those ports. So you try to limit that exposure by narrowly defining the policies by using specific source and destination IPs in the policy. That becomes a headache quickly because of the sheer number of policies this has the potential of creating. So what is this security manager to do?
Looking at this narrowly, SBO raises it’s head as the issue. I have spoken for SBO in the past, and I continue to think it is a legitimate tool in the security managers arsenal. Some people argue that if you have appropriate security measures in place you won’t need it. I contend that SBO can be one of those “appropriate security measures” and you should have layers. But it can cause headaches for others. Should that deter the security manager from using it? Probably not. You have to look out for you data and network first (and if some admin from another company calls me and starts griping that I am using non-standard ports, and it is causing him headaches, he might find himself on the “blocked IP” list quickly).
However, the above scenario is merely an example of the problem. There are other security collision problems out there.
Another example is caused by the fight against spam, namely reverse DNS lookups. Here is an excerpt from this 2004 Security Focus article:
1.4.1 Host-less and vanity domains
The reverse lookup approach requires email to originate from a known and trusted mail server located at a well-known IP address (the reverse-MX record). Unfortunately, the majority of domain names are not associated with static IP addresses. Omitting cyber squatters, the general case includes individuals and small companies that want to use their own domain rather than their ISP’s, but cannot afford their own static IP address and mail server. DNS registration hosts, such as GoDaddy, provide free mail forwarding services to people that register host-less or vanity domains. Although these mail forwarding services can manage incoming email, they do not offer free out-going email access.
Reverse-lookup solutions cause a few problems for these host-less and vanity domain users:
- No reverse-MX record. People sending email from a host-less or vanity domain simply configure their mail application to send email from their registered domain name. Unfortunately, a lookup of the sender’s IP address will not find the sender’s domain, and a lookup of the sender’s domain may not find the correct reverse-MX record. The former is particularly common for mobile, dialup, and other users that frequently change IP addresses.
- No outgoing mail. One possible solution requires relaying all outgoing email through the ISP’s SMTP server. This would provide a valid reverse-MX record for sending email. Unfortunately, many ISP’s do not permit relaying when the sender’s domain is not the same as the ISP’s domain.
In both cases, someone that uses a vanity domain, or a domain that does not have its own mail server, will be blocked by reverse-lookup systems.
This may not be a huge problem, but I have seen a couple of problems caused by this over my years in IT and Security.
Many people would say that these problems can be fought by sticking to standards, but baddies often rely on us doing that to make their job easier. That is seen specifically in the first example.
I am not trying to create FUD here - these are just things I see in my job. In reality, I do not think this is some gargantuan issue that we need to start putting a lot of effort into. I think it many of the security collision issues have to be taken care of on a management level. But it something that I and other security managers have to deal with on a fairly regular basis. So what can we do?
Stop waiting for an answer… I’m asking you! 
Vet
