A presentation about the reasons not to use an Intrusion Detection System

1. About the presentation
This presentation is created by Frank van Vliet and is presented at the ISC2
Secure Amsterdam conference. For any questions, don’t hesitate to contact
him at frank.vanvliet@certifiedsecure.nl.

2. Ethical hacking
Frank van Vliet (1982) is an ethical hacker, known for hacking sites like
FreeBSD.org and slashdot.org. Since 2003, he started working for Pine Digital
Security as Security Specialist; this meant performing attack and penetration
tests, source code audits and lecturing many workshops on secure
programming. Besides security tests, Pine Digital Security is also the major
provider of lawful interception solutions.
In 2006, I co founded the spin-off company Certified Secure. By capturing the
meaning of the word ‘security’ in checklists, Certified Secure is able to certify
companies based on the status of their security.
Besides my work as security professional, I also attend the Kerckhoffs Institute
master Computer Security which is provided by a joint effort of the University
of Twente, Nijmegen and Eindhoven. I’m currently writing my master thesis on
automated attacker profiling (intruder detection instead of intrusion detection).

3. No network is safe
Hackers can penetrate any network or system (given enough time). New
security vulnerabilities are found every day, and no software is programmed
100% secure. Some types of attacks are closely guarded hacker-secrets and
will not be publicly known for several years.
Also, hackers are not bound by any moral rules; they can attack any network.
They could hack your home network to enlarge their bot network, they could
hack your company network just for fun and personal education. They could
also attack to steal company secrets and other valuable information.
In the end, each and every network will have to be secured, so who is going
to do that?

4. How can we stop those hackers?
Most of us are working somehow in the security business. Some of you are
either a security professional, working for a security company, or work/study in
the world of academics.
We are often not directly end-responsible for the security of others’ networks,
but they turn to us for advise, performing security tests, new security research
or nice and shiny security products.
When something becomes available as a silver bullet in security, we like to
jump onboard and believe we’ve finally succeeded in securing something.

5. IDSs, the silver bullet
Intrusion Detection Systems are perfect, they’ll automatically protect your
network against any form of attack! I’ve been there, building an inline
signature based intrusion detection system which could also drop the
offending packets. It was the perfect black box to secure any network, if only…

6. Don’t add something to fix something else
There are security problems in any network, place any number of computers
together and you’ll have a bunch of problems; most systems are only up-to-
date when they are deployed, miss adequate firewalling, run insecure services,
etcetera.
What you should do, is to fix those problems: update each system and install
some mechanism for automatic updating (and testing of those updates
obviously), Implement firewalling based on deny all, permit only the minimum
required, perform source code audits and penetration tests on your services.
You cannot, however, add something to your network to solve those
problems…

7. It is actually a bad idea to deploy an IDS
Adding an Intrusion Detection Systems will not solve your problems, it is not a
silver bullet. There might be some legitimate reasons to implement an
Intrusion Detection System, but none of them will allow you to ignore the real
problems in your network. In most cases, it is actually a very bad idea to
deploy an Intrusion Detection System.

8. Wishful thinking does not stop real hackers
Let’s start of by stating that an Intrusion Detection System will not stop real
hackers attacking real networks. It is very wishful to think your magic box will
stop motivated hackers who know what they are doing.
As you know, there are generally two types of Intrusion Detection Systems,
the system working on signatures (Signature based IDSs) and the system
working profiles of normal traffic (Anomaly based IDSs). For both types, we’ll
discuss why they fail to stop real attackers on real networks.

9. There are no signatures for unknown attacks
First look at Signature based IDSs. They are basically glorified pattern
matchers, having a list of known attacks (signatures) and they match passing
traffic to the signatures. When the traffic matches a signature, it is seen as an
attack and reported. The matching traffic might even be dropped or a TCP RST
might be send. This last method obviously isn’t very helpful since the
destination will first process the attack, and then close the connection after
being exploited.
Somehow, this list of signatures must be generated and kept up to date. This
means they connect to a central server to download the latest and greatest
signatures, or one must manually update the list.
It’s easy to see that having a list of known attacks will never work, this list is
per definition out of date; you cannot create a signature of an attack before it
is known.

10. Each year, more vulnerabilities are disclosed
How often are new security problems found? MITRE published number about
the new vulnerabilities found each year. In 2006, this number was around
7000. It is easily seen that each year, more vulnerabilities are disclosed. This
must keep the maintainers of the lists of signatures quite busy.

11. An average of 18 new vulnerabilities a day
If we divide the number of vulnerabilities found each year by 365, we get the
average number of vulnerabilities found each day for each year. As you can
see, this is an average of 18 new vulnerabilities each day to be included in the
list of signatures. Obviously some vulnerabilities full outside the scope of a
Signature based IDS (for example the local vulnerabilities), but all
vulnerabilities must still be researched.

12. Snort takes 7 days to create signatures
The normal cycle for a vendor that creates signatures is the following:
1. The vulnerability is reported. This might be on public mailing lists like bugtraq or
full disclosure, or by direct announcements by product vendors.
2. The vulnerability is researched. It must be validated this vulnerability does
actually exist, methods of attacking this vulnerability must be created and tested.
3. A signature can be created matching all attacks for this problem. It is best to
write signatures based on the vulnerability instead of writing it on specific
methods of exploiting this problem.
4. Finally, the signatures must be distributed to all Intrusion Detection Systems,
deployed all over the world. This might be a push method (connecting to the
systems) or a pull method (having them connect to a central signature
repository).
This takes a lot of time; the latest snort rules (where you have to pay for) are
updated only once a week.

13. It could take years for a 0-day to publish
Even if the published vulnerabilities could be transformed directly to
signatures, there are a lot of security problems which are never published.
Hackers like to share so called 0-days, and are very protective of these. It
could literally take years before a 0-day for OpenSSH is published to the
public.
How is a Signature based IDS supposed to know of these problems?

14. Anomaly based IDSs have potential
Next to Signature based IDSs, there are Anomaly based IDSs. These systems
are the kind I like, they define what behavior is normal and detect deviations
of this normal pattern. They have the potential to stop 0-day exploits, and
don’t depend on a (commercial) vendor to provide a list of signatures.
However, such systems are not yet ready to be deployed on real networks.

15. Abnormal traffic is listed as an attack
To use an Anomaly based IDS, it is important to learn this system what is
considered ‘normal behavior’. This means it will need attack-free network
traffic that is representative for the network the IDS is going to protect. This
training traffic allows the IDS to create a profile of `normal behavior’.
When the training is complete and the profile of `normal behavior’ is created,
the IDS can receive new traffic and is able to distinguish between normal and
abnormal traffic. Most Anomaly based IDSs make this decision based on the
statistical distance between the new traffic and the stored profile. If the
distance is greater then a given threshold, the traffic is considered abnormal
and is listed as an attack.

16. Demonstration
A demonstration using fruit will clarify the actual working of an Anomaly based
IDS named POSEIDON. For more information, I suggest reading the following
paper:
POSEIDON: a 2-tier Anomaly-based Network Intrusion Detection System
by Damiano Bolzoni, Sandro Etalle, Pieter Hartel
http://eprints.eemcs.utwente.nl/1326/02/01610007.pdf

17. It is hard (manual) labor
The main problem of Anomaly based IDSs is to create the trainig set. Without
representative, attack free network traffic of your network, the IDS cannot
learn what normal behavior is and will not be able to tell the difference
between normal and abnormal traffic.
The only way to create a training set for a real network, is to capture it’s
network traffic for a period of time and then manually removing all attacks
from this traffic. One could use Signature based IDSs to assist, but it is hard
(manual) labor to create this training set.
Even worse, when the network changes, the training set is no longer
representative. This means that every time a server is added to the network,
or the website is changed, a new training set needs to be created.
It is infeasible to create training sets for real networks and keeping them up-
to-date.

18. Per definition, IDSs make a best guess
Intrusion Detection Systems that are listening on the network have no way of
knowing how a system receives and interpret their network packets. Per
definition, network based IDSs have to make a best guess.
Attackers like to exploit the situation where an IDS has to guess. When faced
with two choices, the IDS could also decide to test both cases for attacks. In
theory this is a nice solution, but in practice this does not scale when faced
with multiple options for each packet the IDS sees.

19. RFCs are implemented differently
For example, it could very well be that servers support different features to
encode their packets. Those features might be types of encoding like
encryption and compression.
Also, some servers understand Unicode characters, while others will only see a
set of ASCII characters. The Unicode-enabled servers will literally see different
data than servers without Unicode capabilities.
Furthermore, the implementation of the RFCs is known to be different from
product to product. The IDS can chose to stick to the exact definition by the
RFC, but the servers would interpret the packets differently based on the
software they use.

20. The IDS will never know for sure
Next to different features and RFC implementations, even identical servers can
interpret their packets differently. The most obvious reason for this is that
packets can be reordered by a router and switch located after the IDS
inspection point.
TCP allows packets to be ordered again based on their sequence numbers, but
if two packets arrive with overlapping sequence numbers only the first packet
is used (or the last based on the implementation of the RFC).
If the IDS is using a SPAN port on a router or switch, chances are that it is
already dropping packets. The aggregated network traffic, both in and out, of
all ports is most likely higher then the available bandwidth on the SPAN port.

21. What is the extra risk of using an IDS?
Until now, the main point of this presentation has been that real hackers will
not be stopped or detected by IDSs. But the question arises, `can’t I use an
IDS to defend against the lesser hackers?’. The answer to this question cannot
be given as a simple ‘yes’ or ‘no’.
Like all security solutions, it is a question of risk. Do you think the risk of
scriptkiddies penetrating your network must be addressed? Don’t you think
that this risk should be addressed using proper version management and
secure coding practices? And also important, what is the extra risk of using an
IDS in your network?
The following half of this presentation will answer this last question.

22. No software is secure
We all know that security vulnerabilities can be found in all software. It is
impossible to write 100% secure code that can withstand hackers in present
and future times. So we should also agree that the software of your IDS
contains security vulnerabilities.
But, having security vulnerabilities is just one input on the equation of risk.
Risk is calculated based on the vulnerabilities in software, the requirements on
hackers to exploit them and the impact of such an exploit.

23. Bypassing and compromising Snort
As an example, we take an open source Signature Based IDS named Snort. As
suggested in the previous slide, this product contains a lot of security
vulnerabilities. There are vulnerabilities know to bypass the IDS, but also many
vulnerabilities like buffer overflows and integer over/under flows actually
compromising the IDS.

24. Normally, you would limit attack surface
Normally, you would limit attack surface by using a firewall and disabling all
services you don’t really need. However with an IDS it is the other way
around. The IDS is implementing all possible services, and is listening on all
parts of the network. This gives attackers a lot of attack surface and gives
them easy access to the IDS.

25. A simple example network
In the case of a compromised IDS, it is good to reason about the impact of
this scenario. In this example case there is a simple network with just three
servers. More complicated networks would have multiple network segments
with internal firewalling etc.

26. All network traffic is compromised
When the IDS is compromised, the attacker has access to all network traffic
passing through this network. It doesn’t matter if the exploit targeting the IDS
was addressed to Server A, when an exploit compromises the IDS all network
traffic is compromised.

27. All servers are compromised
When the IDS is compromised, it is safe to say all systems in the network can
be compromised.

28. Sensitive information can be gathered
The network traffic contains many protocols that don’t use cryptography.
These protocols often contain usernames and passwords which can also be
used to access the systems on the network. Also, sensitive information can be
gathered by just reading the email and watching for web traffic on a network.
A special class of problems arise when an IDS is of the active type, capable of
‘preventing’ attacks by resetting connections. When an IDS is able to insert
packets in the network, it is capable of performing man in the middle attacks
compromising even encrypted channels of communication.

29. Some IDSs go one step further
Some IDSs go one step further, completely removing the security of encrypted
channels. When such an IDS is compromised, the attacker has the private key
of the SSL certificate. Now the attacker can compromise encrypted channels
without performing man in the middle attacks.

30. You are faced with a decision
In the end, you are faced with a decision. Is the risk you introduce with an
IDS worth the reduction of risk posed by scriptkiddies. Is this really your way
of improving the security of a network?

31. It is your job to stop hackers
In summary, you are faced with protecting networks against hackers.

32. IDS will not stop hackers
Intrusion Detection Systems will not stop real hackers, and will increase the
risk of a completely compromised network.

33. Fix the real problems
You don’t fix the problem with an IDS. If you want to improve the security of a
network, it would be best to solve the actual security problems.

34. Thanks for your attention
If you have any questions, please don’t hesitate to contact me on
frank.vanvliet@certifiedsecure.nl.