In tuning your IDS, you might want to take the "low hanging fruit" approach first. Once you have the system up and running, and your alerting is working properly, start by finding signatures that generate a lot of alerts and can be positively confirmed as false positives. For example, say you get a ton of ICA alerts to a Citrix Server. That is the function of the server, so that type of traffic is expected and normal.
How do you want to tune this? You want to be efficient and not make the system inspect any more traffic than it has to, and also be mindful you don't do it in a way that filters out traffic you might want to see. You might decide to change the signature and modify it so it only alerts on connections from external or non-trusted networks to an internal host. This would affect all Citrix Servers on your network, which might be what you want. You need to determine risk vs efficiency here.
Or you might want to apply a filter to only your internal sensors for any traffic to that server(s). If you want even less risk, you might write your filter to ignore only your internal network segments going to those servers.
You may maintain different sets of signatures for different types of sensors, too. You could have a library for external Internet servers, another for internal servers, and yet another for the corporate frame or intranet. By doing so you can exclude signatures that would require a lot of tuning. It all depends on your risk model for that connection.
Another way to tune out alerts you may not care about would be to disable ones not relevant to your network. If all of your Internet facing servers run Windows, you could disable signatures for exploits against Linux or Solaris. If you're strictly a IIS shop, you may not care about blind attacks against Apache Web servers. On the other hand, it IS hostile traffic directed at you. You have to determine how much risk you're willing to accept to increase the performance of your system.
I've heard of network security admins who say they're not willing to accept ANY risk, and they want to run every signature available for their system. This is a really bad idea for a couple of reasons.
Tuning is done primarily for two reasons. One, to filter out the background noise of false positives or true positives that have no effect on you, and two, to streamline the performance of your sensors. Each signature you apply means your sensor has to inspect packets traversing it for those particular attributes. Running all signatures puts a huge load on your sensors, and generates so many alerts it's very difficult to focus on the relevant ones.
There are a lot of ways to tune an IDS, and you won't ever reach a point where you sit back and say "I'm finally done tuning this thing.."
An IDS needs constant care, maintenance and tuning. If you're the lone network security person where you work, you may find you spend a significant part of your day working on it. It will need tuning as new signatures are added, new circuits are deployed and new applications are rolled out. Oh, and on top of all this, you need to allow a little time to actually LOOK at the alerts. That's pretty important too!
Thursday, September 24, 2009
Wednesday, September 23, 2009
IDS Detection
The most common way an IDS detects malicious traffic is through the use of signatures. A signature is a string that the IDS looks for in a packet and does a comparison for. If the string matches, the IDS alerts. The string can be a simple ASCII string, such as "cat /etc/passwd", or it can be a regular expression which allows much more granular control, or a binary match.
There are many ways to evade signature-based detection, using different forms of encoding, fragmentation, and other forms. IDS must be able to combat these methods to ensure what it sees will match what the packet ultimately looks like when it reaches the destination host.
Some IDS use pre-processors, modules that massage the data before running it through the rules base for efficiency. For example, if an attacker fragments his traffic with overlapping fragments (a fragment that overwrites part of a previous fragment) an IDS has to be able to reconstruct that packet the same way the host that receives it would. Some systems favor the original fragment that would have been overwritten, and some the fragment that overwrites the previous. Knowing which way your server will reconstruct this traffic is very important. Snort, for example, reassembles the packets both ways, since you may have Windows-based, Unix-based or other operating systems on the host. Others, like Dragon, force you to choose one method or the other. As long as all the systems on a segment being monitored are all on the same platform, this isn't a problem.
Signatures also specify other attributes, like which direction the packet is coming from, ports, protocols and more. Each one tunes the signature to be more specific, eliminating possible false positives.
The IDS engine does detection with built-in parameters that doesn't require a separate signature. For example, there may be an ICMP module in your IDS that alerts on packets over a certain size, or a certain number of packets in a time frame all going to one host to detect a ping flood. It may look for scanning by keeping track of the number of different hosts an external address tries to connect to one one port, or the number of ports on one host it tries to connect to (port sweeps and port scans).
Stateful inspection is important here. An IDS needs to be able to keep track of state to determine if packets are part of an existing connection or a new connection. Shell code being bounced off a server without a connection ever being made might cause the analyst to take notice and investigate what else the attacker might be doing, whereas shell code being passed on an established TCP connection would be cause to take action immediately.
Anomaly-based detection uses profiles to try and establish a baseline of what is "normal" traffic, and alerts you when traffic not fitting that profile occurs. Let's say you have a Web server that is primarily used by a few customers in the same country as you, in the morning hours Monday through Friday. The rest of the time there is little to no traffic to the box. Then one Saturday morning at 3:00 AM, the box is inundated with traffic from another country. There may be nothing in that traffic that triggers a signature or the IDS engine, but the deviation from the norm is curious at the least and probably alarming. Anomaly detection tries to determine events of this type.
This is obviously a very simplistic overview. There is much more that could be said for each type of detection, and other types like heuristics, protocol-decoding, etc., that you can read about if you'd like to learn more.
There are many ways to evade signature-based detection, using different forms of encoding, fragmentation, and other forms. IDS must be able to combat these methods to ensure what it sees will match what the packet ultimately looks like when it reaches the destination host.
Some IDS use pre-processors, modules that massage the data before running it through the rules base for efficiency. For example, if an attacker fragments his traffic with overlapping fragments (a fragment that overwrites part of a previous fragment) an IDS has to be able to reconstruct that packet the same way the host that receives it would. Some systems favor the original fragment that would have been overwritten, and some the fragment that overwrites the previous. Knowing which way your server will reconstruct this traffic is very important. Snort, for example, reassembles the packets both ways, since you may have Windows-based, Unix-based or other operating systems on the host. Others, like Dragon, force you to choose one method or the other. As long as all the systems on a segment being monitored are all on the same platform, this isn't a problem.
Signatures also specify other attributes, like which direction the packet is coming from, ports, protocols and more. Each one tunes the signature to be more specific, eliminating possible false positives.
The IDS engine does detection with built-in parameters that doesn't require a separate signature. For example, there may be an ICMP module in your IDS that alerts on packets over a certain size, or a certain number of packets in a time frame all going to one host to detect a ping flood. It may look for scanning by keeping track of the number of different hosts an external address tries to connect to one one port, or the number of ports on one host it tries to connect to (port sweeps and port scans).
Stateful inspection is important here. An IDS needs to be able to keep track of state to determine if packets are part of an existing connection or a new connection. Shell code being bounced off a server without a connection ever being made might cause the analyst to take notice and investigate what else the attacker might be doing, whereas shell code being passed on an established TCP connection would be cause to take action immediately.
Anomaly-based detection uses profiles to try and establish a baseline of what is "normal" traffic, and alerts you when traffic not fitting that profile occurs. Let's say you have a Web server that is primarily used by a few customers in the same country as you, in the morning hours Monday through Friday. The rest of the time there is little to no traffic to the box. Then one Saturday morning at 3:00 AM, the box is inundated with traffic from another country. There may be nothing in that traffic that triggers a signature or the IDS engine, but the deviation from the norm is curious at the least and probably alarming. Anomaly detection tries to determine events of this type.
This is obviously a very simplistic overview. There is much more that could be said for each type of detection, and other types like heuristics, protocol-decoding, etc., that you can read about if you'd like to learn more.
Friday, September 18, 2009
IDS Monitoring
How do you monitor the network with an IDS?
There are a couple of different ways, depending on what segment you wish to monitor and your budget. The first way is via a network tap. A tap is a device that sits in-line and duplicates all packets to another interface or multiple interfaces for monitoring.
There are several different types of taps: passive or active, half duplex or full, single device or multiple.
A passive tap allows you to monitor all packets going through the device by copying the packets to one port (full-duplex) or two (half-duplex). Full duplex taps must use a time of arrival algorithm to aggregate the stream on the monitoring port. Simplex taps use two monitoring ports, once for each network port. You must use channel bonding on the monitoring device to aggregate them back into one stream.
An active tap allows you to put packets from the monitoring device back through the tap onto the network. This is used for active response in IDS, that is, shooting down certain traffic you wish to stop. This is usually done by sending spoofed RST (reset) packets to both ends of the connection and tearing it down.
Some taps (called regeneration taps by some vendors) can regenerate the traffic stream to multiple network ports, allowing more than device to monitor it. You may, for example, use a four device tap at an Internet ingress point, and patch one port to your IDS, another to a packet auditing system like IDABench or Shadow, another to an analysis/statistics box for the network team and leave the fourth available for some future use, such as vendor troubleshooting.
SPAN ports, or port mirroring, are done on the switch. A span port is a switch port that is set up to receive copies of all packets seen by another port. Though easy to set up and not requiring any additional cost, there are disadvantages to span ports as opposed to taps. Span ports can drop packets such as runt packets (undersized), giants (oversized packets), and packets with CRC errors. Also, if a switch gets overloaded and experiences high utilization, the SPAN port will be the first place the switch will start dropping packets. If you are under an attack that creates large amounts of traffic, you may start losing packets at the very time it's critical to see them.
In the next post, I'll cover the different ways an IDS can detect malicious traffic.
There are a couple of different ways, depending on what segment you wish to monitor and your budget. The first way is via a network tap. A tap is a device that sits in-line and duplicates all packets to another interface or multiple interfaces for monitoring.
There are several different types of taps: passive or active, half duplex or full, single device or multiple.
A passive tap allows you to monitor all packets going through the device by copying the packets to one port (full-duplex) or two (half-duplex). Full duplex taps must use a time of arrival algorithm to aggregate the stream on the monitoring port. Simplex taps use two monitoring ports, once for each network port. You must use channel bonding on the monitoring device to aggregate them back into one stream.
An active tap allows you to put packets from the monitoring device back through the tap onto the network. This is used for active response in IDS, that is, shooting down certain traffic you wish to stop. This is usually done by sending spoofed RST (reset) packets to both ends of the connection and tearing it down.
Some taps (called regeneration taps by some vendors) can regenerate the traffic stream to multiple network ports, allowing more than device to monitor it. You may, for example, use a four device tap at an Internet ingress point, and patch one port to your IDS, another to a packet auditing system like IDABench or Shadow, another to an analysis/statistics box for the network team and leave the fourth available for some future use, such as vendor troubleshooting.
SPAN ports, or port mirroring, are done on the switch. A span port is a switch port that is set up to receive copies of all packets seen by another port. Though easy to set up and not requiring any additional cost, there are disadvantages to span ports as opposed to taps. Span ports can drop packets such as runt packets (undersized), giants (oversized packets), and packets with CRC errors. Also, if a switch gets overloaded and experiences high utilization, the SPAN port will be the first place the switch will start dropping packets. If you are under an attack that creates large amounts of traffic, you may start losing packets at the very time it's critical to see them.
In the next post, I'll cover the different ways an IDS can detect malicious traffic.
Thursday, September 17, 2009
IDS - The Intrusion Detection System
I'm going to take the next few posts to talk about IDS, Intrusion Detection Systems. I'll discuss it from the ground up for those who are new to Network Security.
An Intrusion Detection System is a host or piece of software that monitors either network traffic streams or logs and processes on one box for malicious activity. There are two distinct types of systems, NIDS and HIDS.
NIDS - Network Intrusion Detection System: A NIDS monitors network traffic. It can be placed about anywhere there is a need for it, but the most common placement is at an ingress point where Internet traffic comes into the network. There is some debate as to the optimal placement at an Internet choke point, as to whether it should monitor inside the firewalls or outside, but my experience is most experts agree if you only have one, inside is better. (Having one inside and one outside is, of course, even better).
There are several reasons for this. A NIDS that is placed inside the firewall is seeing traffic that was not dropped (either by design or unintentionally) by the various layers of border perimeter defenses. That traffic has traversed one or more border routers and was not prohibited by Access Control Lists, and has successfully passed one or more firewalls without being blocked by a rule. The assumption is this is normal, wanted traffic such as a customer accessing your web site. However, since ACL's block certain IP's and firewalls allow traffic to certain IP's on certain ports, this may just as easily be someone trying to exploit a vulnerability in the web sites application code. For discussion purposes, we're assuming the firewall in question isn't a multi-purpose appliance with IDS on board. Some firewall software also has a limited IDS signature set built in that may catch and block certain very well known attacks. A lot of network administrators are hesitant to run even this limited functionality because of the fear of blocking legitimate traffic by mistake.
A NIDS outside the firewall would alert as well. But you would be uncertain without checking logs on the firewall or a packet auditing system whether the traffic was allowed, or blocked by the firewall. With an internal IDS, you know instantly.
Another very good reason to have an internal NIDS is for tracing back internal compromises and outbreaks/infections. Let's say one of your end user desktop PC's get's popped and becomes part of a bot net. The code on the machine begins to connect out to the botnet controller to notify it that it's under control and to download other software or receive instructions. Assuming you use internal RFC 1918 IP addressing, that traffic will route out to your firewall, be translated to the hide address of your firewall and on to the Internet. Let's say your hide address is 66.66.66.1.
All hosts on your internal network would get translated to this IP address going out to the Internet.
A NIDS outside your firewall would only see the packets after they had been translated. Which of the desktops is infected and calling out to the botnet? Again, you'd have to rely on logs on your network infrastructure equipment, which is not only time consuming, but depending on how logging is set up, may not even help you. Because of sheer size of full logging, a lot of shops only log drops on the firewall and denies on routers, not allowed packets. A a packet that is accepted may not (probably not) even be logged.
But your internal NIDS sees the packets before the firewall, and hence, before they are translated, so your alert will identify the internal IP address, allowing you to easily trace back to the machine and do your incident response and shut it down.
In the next few posts, I'll cover different ways to monitor traffic, the different ways an IDS detects malicious traffic or activity, a few basics on tuning sensors and what Host-based Intrusion Detection is.
An Intrusion Detection System is a host or piece of software that monitors either network traffic streams or logs and processes on one box for malicious activity. There are two distinct types of systems, NIDS and HIDS.
NIDS - Network Intrusion Detection System: A NIDS monitors network traffic. It can be placed about anywhere there is a need for it, but the most common placement is at an ingress point where Internet traffic comes into the network. There is some debate as to the optimal placement at an Internet choke point, as to whether it should monitor inside the firewalls or outside, but my experience is most experts agree if you only have one, inside is better. (Having one inside and one outside is, of course, even better).
There are several reasons for this. A NIDS that is placed inside the firewall is seeing traffic that was not dropped (either by design or unintentionally) by the various layers of border perimeter defenses. That traffic has traversed one or more border routers and was not prohibited by Access Control Lists, and has successfully passed one or more firewalls without being blocked by a rule. The assumption is this is normal, wanted traffic such as a customer accessing your web site. However, since ACL's block certain IP's and firewalls allow traffic to certain IP's on certain ports, this may just as easily be someone trying to exploit a vulnerability in the web sites application code. For discussion purposes, we're assuming the firewall in question isn't a multi-purpose appliance with IDS on board. Some firewall software also has a limited IDS signature set built in that may catch and block certain very well known attacks. A lot of network administrators are hesitant to run even this limited functionality because of the fear of blocking legitimate traffic by mistake.
A NIDS outside the firewall would alert as well. But you would be uncertain without checking logs on the firewall or a packet auditing system whether the traffic was allowed, or blocked by the firewall. With an internal IDS, you know instantly.
Another very good reason to have an internal NIDS is for tracing back internal compromises and outbreaks/infections. Let's say one of your end user desktop PC's get's popped and becomes part of a bot net. The code on the machine begins to connect out to the botnet controller to notify it that it's under control and to download other software or receive instructions. Assuming you use internal RFC 1918 IP addressing, that traffic will route out to your firewall, be translated to the hide address of your firewall and on to the Internet. Let's say your hide address is 66.66.66.1.
All hosts on your internal network would get translated to this IP address going out to the Internet.
A NIDS outside your firewall would only see the packets after they had been translated. Which of the desktops is infected and calling out to the botnet? Again, you'd have to rely on logs on your network infrastructure equipment, which is not only time consuming, but depending on how logging is set up, may not even help you. Because of sheer size of full logging, a lot of shops only log drops on the firewall and denies on routers, not allowed packets. A a packet that is accepted may not (probably not) even be logged.
But your internal NIDS sees the packets before the firewall, and hence, before they are translated, so your alert will identify the internal IP address, allowing you to easily trace back to the machine and do your incident response and shut it down.
In the next few posts, I'll cover different ways to monitor traffic, the different ways an IDS detects malicious traffic or activity, a few basics on tuning sensors and what Host-based Intrusion Detection is.
Tuesday, September 15, 2009
Nice...really nice!
September 13, Ars Technica – (International) FTC forces Sears, Kmart out of the spyware business. The Federal Trade Commission (FTC) has busted a strange set of spyware purveyors — U.S. retailing giants Sears and Kmart. The FTC recently approved its final consent order against the companies (which share the same owner) over an episode that can only be chalked up to incompetence of a truly epic scope. Sears Holding Management Company decided that it could really use a lot more marketing data to fuel its decision-making process, so it began offering visitors to sears.com and kmart.com a special invite — sign up for “My SHC Community,” download a piece of “research” software, and earn 10 American dollars. All one had to do was turn over to the company every single bit of information about one’s Web browsing. This was not just about the websites visited, or even about specific URLs; the “research” software transmitted the complete contents of a browsing session, even secure sessions. This meant that Sears and its data collection partner would have access to the “contents of shopping carts, online bank statements, drug prescription records, video rental records, library borrowing histories, and the sender, recipient, subject, and size for web-based e-mails,” said the FTC. Among other things — the software also collected non-Web information about the user’s personal computer. Sears did tell people that it would track their “online browsing,” but when security researchers looked into the software in early 2008, they charged that the disclosure was mostly buried in legalese. Under the settlement with the FTC, Sears has now agreed to destroy all data gained from the experiment and stop collecting data from any software still running in the wild. In addition, if it wants to do any tracking in the future, the company has committed to “clearly and prominently disclose the types of data the software will monitor, record, or transmit. This disclosure must be made prior to installation and separate from any user license agreement. Sears must also disclose whether any of the data will be used by a third party.” Source: http://arstechnica.com/tech-policy/news/2009/09/ftc-forces-sears-kmart-out-ofthe- spyware-business.ars
Monday, September 14, 2009
New Vista Worm Possible?
There's a discussion about the possibility of a new Vista worm here. Microsoft hasn't released a patch for it, and it's estimated there are 200 million Vista boxes on the Internet which could be possible targets.
Apple Patches
Apple releases 47 patches for iPhones, Macs, Quicktime.. Link here. While it's a very good thing Apple is patching their software, you have to wonder about the perception that Apple's stuff isn't as insecure as the rest of devices and software out there. That is a large number of patches...
Security Update 2009-005, link , is starting to look like Microsoft's Black Tuesday, isn't it?
Security Update 2009-005, link , is starting to look like Microsoft's Black Tuesday, isn't it?
Thursday, September 3, 2009
Mandatory Messenger Upgrade Coming
September 1, SCMagazine – (International) Microsoft mandates Messenger upgrade for security flaws. Users of Microsoft’s Windows Live Messenger instant messaging software soon will be required to upgrade to the latest version to close vulnerabilities that could enable an attacker to execute remote code. On September 1, Microsoft pushed out the newest version, Windows Live Messenger 14.0.8089. The upgrade addressed vulnerabilities in Microsoft’s Active Template Library (ATL), used in the development of the IM program, the company said in a blog post on August 27. Microsoft is not aware of any attacks currently targeting the ATL vulnerability in Live Messenger, a Microsoft spokesperson told SCMagazineUS.com on September 1. Beginning in the middle of this month, users of Messenger versions 8.1, 8.5 and 14.0 must upgrade, with a deadline of the end of October. Users will be prompted to install the new version when they sign into one of the vulnerable versions of Live Messenger, Microsoft said. If users do not upgrade, they may not be able to connect to the IM service. “It will take several weeks for the upgrade process to be completed, as the upgrade will be rolled out to customers over the course of several weeks,” Microsoft said. Users of Live Messenger version 14.0 will not see any visible changes with the upgrade. But for users of Windows Live Messenger versions 8.1 or 8.5, the update also includes additional non-security features, Microsoft said. The vulnerabilities in ATL affect not only Live Messenger but numerous programs developed with ATL. In late July, Microsoft issued two out-of-band security patches to address the ATL bugs in http://www.scmagazineus.com/microsoft-mandates-messenger-upgrade-forsecurity- flaws/article/147932/
Subscribe to:
Posts (Atom)