Intrusion Detection Systems
Intrusion Detection Systems
ghost | 4706 Reads | Intrusion Detection Systems
Getting right to the point, altho this will expect a little knowledge of TCP/IP and the stack, most even real n00bs should understand the underlining concept.
Firewall, host and system logs dont often give you enought Information about incoming attacks, or in time as the case maybe. and what use are logs if you dont check them often.. as so many people forget to do. Firewalls drop all blocked packets and this alone is not enough to determine the type and content of incoming attacks. port scaning comes to mind..
When logging and alerting of ongoing attacks is required it is at this point you need to start thinking about some form of IDS. Now IDS works much like a packet filter like say iptables in Unix-like systems or other software based “firewall” in “” coz they’re not really firewalls altho labeled as such. but rather than logging/storing all passing packets, an IDS looks at the payload of the packets, then checks this against its set of rules and then triggers a response based on weather the packet’s contents/payload is deemed hostile.
IDS dose this by using its engine/rulesets to look at typical signatures of hostile network traffic, the ports, packet types weather SYN, ACK etc.. frequency, fragmentaion, and other such verables. to determine weather the current situation is hostile or not, when a match is found the IDS will log the attack, and offer some form of notifying the sysadmin that an attack is current on his system.
One bit of good news for the would be attacker, because the above system seems rather fool proof. Is that attacks are very diverse this broadness means it is possible to trick the IDS in to giving false positives. but this overhead can be kept to a min by a skilled sysadmin, pen testing and running exploites against your systems is also a good way to test your IDS’s rules and config.
A good e.g would be NetBios traffic on port 139. (I’ll use Unix-like systems here as thats what i perfure and well there better) Now normaly there is no need for this kind of traffic to be entering your LAN from the web unless your a fool and think its a good idea. So blocking 139 with your firewalls and filtering is a must do step. you may also want to know more info about whats going on with 139. Now a good IDS system can trigger packet capture and logging of a connection/‘s when a hostile event occures. allowing the sysadmin to review it later. Any one that has used a packet sniffer will know the kind of data you mite find in these logs such as commands, data used by buffer overflow’s perhaps, data tunneling, backdoor access etc.
A more technical example would perhaps be a wave of packets with unsual TCP/IP flags or even unspecified ones. for instance network scanners such as nmap can do what is called host ID fringerprinting, witch can be used as a method of OS detction by using an undefined TCP/IP flag in the TCP header (TCP headers and IP headers are diff) of a SYN packet. TCP/IP stacks on different OS’s process the TCP headers slightly different, this is turn can be used to determine the OS type.
An IDS can easily find and detect these types of attacks, and the rules for detecting such an attack would be very simple, a trigger for any undefined TCP/IP flags and a note to the sysadmin would have the job done.
Placement of IDS this is an important and often over looked aspect of IDS, and that is “Were do i put the damn thing”Ideally you want it before the firewall, to log attacks before the firewall rules drop the packets your watching for. But this area of placement, means you will be bugged by it often, and for nothing other than some kid that learnt about nmap in yahoo chat. So care in the analysis of the data it produces is a must. Past the firewall in to the DMZ the IDS here can only detect attacks against the DMZ and not anything that is headed in to the internal LAN. Now if you place an IDS on you internal LAN any data it picks up will be serious, since there should be no unauthorised traffic on your LAN. Placement mainly depends on the topogly of your network, if your using multiple-firewalls and set zones in your LAN you need to place some form of IDS in each zone. Networks of this architecture to me are the safest and most secure, also makes admin overhead low as set areas have there set job. and sertian zone’s may require different levels of security within there firewalls and IDS alike. This allows the sysadmin to setout what ports, services need to be in use, and allows the sysadmin to know excatly when somthing is doing somthing its not sposed to.
There are loads of IDS systems out there, like ISS realsecure, Netprowler etc as commercial offerings and not really somthing you get to play with unless you have bags of cash, altho as a hacker they mite play with you. Of more intrest to the geek/hacker there are a few good open source IDS systems, such as SNARE and SNORT.
SNARE (System iNtrusion Analysis and Reporting Environment) is a linux based app thats a loadable kernel module and has its own GTK based gui.
SNORT has been around for some time and covers more platforms that the above including win32 based systems, snort in itself is a txt so i wont touch on it much here.
there you go folks tryed to keep it shortish soz bout the spelling etc.. its early and i’ve had a lot of beer
