scip Cybersecurity Forecast
For the past 15 years, the subject of Intrusion Prevention Systems (IPS) has been present in the heads of those who work in applied computer security. However, just like Intrusion Detection Systems (IDS) they’ve been a bit neglected as of late. The subject seemed too complex and too difficult to handle.
The subjects rose back to popularity with their simplification and professionalization. There are numerous approaches to the subjects by just as many vendors. Traditionally, an IDS/IPS is used as a sensor in a network.
HP TippingPoint is one of those HIDS/HIPS-Systems (it’s even being advertised as a NGIPS – a Next Generation Intrusion Prevention System). The commercially available product comes with 7000 Protection Filters that use a traditional pattern recognition to detect attack attempts. Users can bundle those filters together into profiles, tie them to certain interfaces (for example, they can be used to monitor inbound traffic only) and apply actions to these profiles (such as permit, block, notify, trace).
This article will focus on the Protection Filters that TippingPoint provides. HP’s approach and the program’s structure is being looked at dissected.
The title of a filter is following the simple structure of
ID: Name. The typical filters to detect classic anomalies in ICMP are named:
The ID is four characters long and is being incremented with every newly introduced filter. Numbers lower than 1000 will be prefixed with zeroes. There are over 7000 filters, but there are holes in the IDs. This is most likely due to there being filters that were never released or retracted. There are filters with IDs higher than 10000. This has had no impact on the zero-prefixing-convention.
If a vulnerability is published via ZDI (Zero Day Initiative), the corresponding ID will be added in parentheses. Other sources, such as OSVDB or CVE are unfortunately not included. Similarly, there is no database publicly accessible database of the filters that could facilitate linking filters to other sources. Therefore the association of filters with specific vulnerabilities is very difficult at this point. A similar problem can be observed with Qualys. That is just one of the reasons why open databases should be prioritized.
The filters are assigned to categories. The following table will explain those categories:
|Traffic that is generated by automated tools that exploit vulnerabilities. These are first and foremost these are effective exploits that possess a clearly defined and thus identifiable pattern. But this category also includes classic attack-tools such as Loki, DDoS-Tools like TFN/Stacheldraht as well as Malware like Nimda.
|A rather small category that tries to recognise phishing-behaviour. It tackles both generic grabbing of credit card numbers as well as company-specific phishing (such as PayPal or eBay).
|Any kind of traffic that is used in an attack scenario to obtain information about the target. This includes network based surveys (such as Route-Tracing with low TTL-values) as well as application-specific techniques (Read sources via ColdFusion etc.)
|Traffic that is usually either whitelisted or blacklisted in generic baselines. This includes advanced types of ICMP, classic attack vectors on FTP as well as specially crafted web operations.
|Software components that are used to spy on users in either a broad sense or a very targeted fashion. This includes certain backdoors, among them the Zeus Botnet. This category also includes familiar downloaders and toolbars.
|A listing of malware that propagates viral infections. Naturally, this is only detected in the propagation inside the network.
| A big category that should detect attacks. It watches out for generic markers (such as access to
gcc) and also for specific properties that can be applied to dedicated vulnerabilities and the attack techniques that are associated with them.
The categorization is sometimes not easy to understand. For example:
0079: ICMP: Echo Reply is filed under Security Policy even though it would fit better into Reconnaissance. Some DDoS-Tools and worms would probably be a better fit in Virus than in Exploits.
Like other products, there’s a market-driven mixing between Intrusion Prevention and Malware Detection. This is obvious when looking at the category Virus. Even though it can be an advantage to have an IPS recognize malware early on, this solution does not – at least not as of writing this – replace a real anti-virus solution. The list of viruses the IPS detects is too limited and too short. In addition to that, the IPS is focussed on the spread of the virus and not on the subsequent actions.
HP propagates a so-called Default Profile. This is their recommended profile, that should be used to prove basic protection in most environments without having any negative impact on operations. This means that 32.6% of all filters are being activated. The remaining 67.4% remain inactive because they could be too aggressive.
|Various ICMP-Types are not being considered which opens the door to classic DoS- and rerouting attacks.
|Invalid TCP Traffic: Possible Recon Scan (FIN no ACK)
|FIN-Scans cannot be detected and should be preferred to other Portscan methods.
|0340-0387 (Unix), 0495-0504 (Win), 0928-0935 (Unix)
|HTTP: Shell Command Execution
|The generic rules for recognizing command injections on webservers is inactive.
| Same with the generic rules for elevated access on the MSSQL database: They’re almost all inactive. An exception here is the access to
|Invalid TCP Traffic: Source Port 0
|Access with the source port tcp/0 are not being detected as a separate thing. This could enable an attacker to launch a covert attack.
|RPC: Portmap Request
|Generic RPC Portmap-Requests, for TCP as well as UDP, are not considered. A covert investigation is therefore possible.
| Some classic attack vectors concerning FTP aren’t even considered. Among them are accessing
|Rservices: Attempted rlogin/rsh
|Access to rlogin/rsh is not considered either. This misses successful as well as failed login attempts as well as classic exploits.
|HTTP: ../.. Directory Traversal
|One of the more common ways in which a directory traversal attack is being used is also not being detected. Therefore, the system doesn’t even require further encoding attempts.
|Portscans are – probably because of the high impact they have on performance – not considered by default. This is true for both TCP and UDP.
|The same is true for search runs, which are ignored by default. This concerns TCP, UDP, ICMPv4 and ICMPv6.
Also, among other things, filters that are considered simple that produce very few false positives are deactivated. Among them are (short list of highlights):
A lot of vulnerabilities that are specific to an application or a product are also ignored. Among those are (again, just a short list of highlights):
Those are not listed in the table above due to their high number and diversity. It is to be assumed that the filters have produced an above-average number of false positives in this context and have thus been disabled. Or they used too much of the resources. It is thus the job of the user to enable them.
This shows that users shouldn’t trust HP’s recommendations blindly. In a secure environment, there’s also the specifics of the company that need to be considered. New filters have to be reviewed, tested and then deployed securely.
HP TippingPoint is an interesting system that leaves a good impression when it comes to certain levels. From a performance and security standpoint, it certainly is worth checking out. The filters that are included with the software can help to set up a security baseline in a company quickly and efficiently.
Still, our tests have shown that some standard settings have been negligently ignored and thus, they even enable attackers by introducing new ways for them to attack. Classic attack vectors are becoming interesting again. And if an attacker knows which configuration of a system awaits him, he will be able to launch a lot of successful attacks completely undetected.
The closed nature of the system makes it nigh impossible to determine further details about the behaviour of the filters and to optimize them where needed. That’s the big disadvantage that can only be tackled by open – in the ideal case even the source code is open – systems. This is a way of thinking that shouldn’t just be applied to IDS/IPS.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here