Fight to Your Strengths
When I studied American Kenpo in San Antonio, TX, my instructor Curtis Abernathy expressed similar sentiments. He said "Make the opponent fight your fight. Don't try to out-punch a boxer. Don't try to out-kick a kicker. Don't try to wrestle a grappler." And so on.
I thought about these concepts today waiting in another airport. I wondered what sorts of strengths network defenders might have, and if we could try forcing the adversary into fighting our fight and not theirs.
Here are some preliminary thoughts on strengths network defenders might have, and how they can work against intruders.
- Knowledge of assets: An intruder pursuing a targeted, server-side attack will often try to locate a poorly-configured asset. The act of conducting reconnaissance to locate these assets results in the opponent fighting your fight -- if you and/or your defensive systems possess situational awareness. It is not normal for remote hosts to sweep address space for active hosts or individual hosts for listening services. Defenders who manually or automatically take defensive actions when observing such actions can implement blocks that will at least frustrate the observed source IP.
- Knowledge of normal behavior: An intruder who compromises an asset will try to maintain control of that asset. This may take the form of an outbound IRC-based command-and-control channel, an inbound or outbound encrypted channel, or many other variations. To the extend that the intruder does not use a C&C channel that looks like normal behavior for the victim, the intruder is fighting your fight. Whenever you constrain network traffic by blocking, application-aware proxying, and throttling, you force the intruder into using lanes of control that you should architect for maximum policy enforcement and visibility.
- Diversity: Targets running Windows systems or PHP-enabled Web applications are much more likely to be compromised and manipulated by intruders. Attack tools and exploits for these platforms are plentiful and well-understood by the enemy. If you present a different look to the intruder, you are making him fight your fight. An intruder who discovers a target running an unknown application on an unfamiliar OS is, at the very least, going to spend some time researching and probing that target for vulnerabilities. If you possess situational awareness, diversity buys time for defensive actions.
- Situational awareness: A well-instrumented network will possess greater knowledge of the battlespace than an intruder. A network architected and operated with visibility in mind provides greater information on activity than one without access to network traffic. Unless the intruder implements his own measures to expand his visibility (compromising a switch to enable a SPAN port, controlling a router, etc.), the defender will know more about the scope of an attack than the intruder. Of course, the intruder will have absolute knowledge of his activities because he is executing them, possibly via an encrypted channel.
These are some initial ideas recorded in an airport. I may augment them as time permits.
Notice that if you don't know your assets or normal behavior, if you run the same vanilla systems as the rest of the world, and you don't pay attention to network activity, you have zero strengths in the fight beyond (hopefully) properly configured assets. We all have those, right?
At the risk of involving myself in a silly debate, I'd like to briefly mention how these factors affect the decision to run OpenSSH on a nonstandard port. Apparently several people with a lot of free time have been vigorously arguing that "security through obscurity" is bad in all its forms, period. I don't think any rational security professional would argue that relying only upon security through obscurity is a sound security policy. However, integrating security through obscurity with other measures can help force an intruder to fight your fight. Here's an example.
I'm sure you've seen many brute force login attacks against OpenSSH services over the past year or two years. I finally decided I'd seen enough of these on my systems, so I moved sshd to nonstandard ports. Is that security through obscurity? Probably. Have I seen any more brute force attacks against sshd since changing the port? Nope. As far as I'm concerned, a defensive maneuver that took literally 5 seconds per server has been well worth it. My logs are not filling with records of these attacks. I can concentrate on other issues.
Now, what happens if someone really takes an interest in one or more of my servers? In order to find sshd, he needs to port scan all 65535 TCP ports. That activity is going to make him fight my fight, because scanning is way outside the normal profile for activity involving my servers. Will he eventually find sshd? Yes, unless my systems automatically detect the scan and block it. Are there ways to make the intruder's ability to connect to sshd even more difficult? Sure -- take a look at Mike Rash's Single Packet Authorization implementations. The bottom line is that a defensive action which cost me virtually nothing has increased the amount of work the intruder must perform to attack sshd.
If I knew my action to change sshd's port could be discovered by the intruder with minimal effort (perhaps they have visibility of the change via illicit monitoring) then obscurity has been lost and the change is not worthwhile.
As a final thought, it's paramount to consider cost when making security decisions. If altering the sshd port had required buying new software licenses, hardware, personnel training, etc., it would not have been worth the effort.
I would be interested in hearing your thoughts on ways to get the intruder to fight your fight. These are all strictly defensive measures, since offense is usually beyond the rules for most of us.
Comments
"Unless the intruder implements his own measures to expand his visibility (compromising a switch to enable a SPAN port, controlling a router, etc.), the defender will know more about the scope of an attack than the defender. Of course, the defender will have absolute knowledge of his activities because he is executing them, possibly via an encrypted channel."
Is this what they were supposed to say?
"Unless the intruder implements his own measures to expand his visibility (compromising a switch to enable a SPAN port, controlling a router, etc.), the defender will know more about the scope of an attack than the INTRUDER. Of course, the INTRUDER will have absolute knowledge of his activities because he is executing them, possibly via an encrypted channel."
Design also gives you a fifth strength - the people who work with, build, and maintain those systems will also better understand how they interoperate and why the security design is laid out as it is. That gives a second line of defense beyond the security analyst, and that depth can detect attacks and exceptions that an analyst misses. Perhaps more importantly, if means that your entire IT organization is part of your security effort.
As for changing the port for SSH - my belief is that at times we get so hung up on the tags - "security by obscurity" that we cease to see the valid strategies that they can cover. Simply because we denigrate the people who rely solely on it doesn't mean that it isn't part of a valid defensive scheme.
Moving a known, often attacked or exploited service to a non-standard port isn't just security by obscurity though. It is a useful defense against simple minded, automated exploits. That's a valid strategic decision in my book, as the enemy who only strikes at known assets can't hit them if he doesn't know they're there. Until automated brute force utilities advance to include full range port scans and service finger printing, it makes sense. I consistently recommend moving any well known service that is frequently attacked, and which can be shifted within the organization. Oracle, MySQL, and SSH are all good places to start - low hanging fruit, to say the least. This move often stops worms from spreading inside of organizations.
As you pointed out, once you cut out the noise, you can focus on the attacks that actually have some intelligence behind them. That gives you more power - you can focus your resources and you're more likely to recognize the real threats.
In the past, I've also done things as simple as change the response from a web server to defeat automated scanners. Why look like an attractive vulnerable IIS server when you can look like something a lot more obscure when the automated probe looks at you? A simple change can cause some automated probes to use the wrong exploits on your server, or to ignore it entirely - you're just exploiting their vulnerability to being told a simple mistruth. You usually can't change your web services port for public exposure, but you can change how your attackers see you!
Unfortunately, there isn't a way to make your systems look scary enough to make attackers run away...
http://deeptrust.blogspot.com
And yes, that particular silly argument you mention makes kittens cry...I think people just have very fundamental differences in how they view, define, and *need* security in their orgs. It's not wrong until someone won't accept only their own view and nothing else... Security and IT are so varied that even as logical as our field is, it is still full of creativity and subjectivity in solving problems in a myriad different ways.
Notice that if you don't know your assets or normal behavior, if you run the same vanilla systems as the rest of the world, and you don't pay attention to network activity, you have zero strengths in the fight beyond (hopefully) properly configured assets.
Since I've worked in infosec consulting (starting with vulnerability assessments and pen tests, and then moving into IR/CF investigations), most of the folks I've encountered DO NOT have any of these strenghts.
In the words of Metallica..."sad, but true". Wait...is that copyrighted? ;-)