|
|
Line 3: |
Line 3: |
| NIDS are an [[IDS]] that monitor all traffic to and from all network devices. It will read incoming [[Packet|packets]] looking for suspicious patterns. Popular NIDs such as [[snort]] and [[Cisco IDS]] are used often-times in conjunction with a [[firewall]] to form an [[IPS]]. Also commonly used to send information to a [[SIM]] or [[SIM|SIMS]] | | NIDS are an [[IDS]] that monitor all traffic to and from all network devices. It will read incoming [[Packet|packets]] looking for suspicious patterns. Popular NIDs such as [[snort]] and [[Cisco IDS]] are used often-times in conjunction with a [[firewall]] to form an [[IPS]]. Also commonly used to send information to a [[SIM]] or [[SIM|SIMS]] |
| | | |
− | ==Snort==
| |
| | | |
− | Snort is a packet sniffer and intrusion detection system that can be used to add a layer of surveillance to your system. In this way, it is similar to tcpdump, but with some more advanced rule-setting capabilities for detecting certain forms of packets. Snort is one of the most widely used IDSes under Linux, and a port exists for the Windows [[Operating System]].
| |
− |
| |
− | ===Basic Packet Sniffing Utilities===
| |
− |
| |
− | Once installed, snort can be set up with basic packet sniffing functionality simply by typing "snort" into a terminal or command prompt. It will run in the default mode using the default interface - for me, this is eth0, the wired connection. A new interface can be specified with the -i option. For example, to run snort on the wireless interace:
| |
− |
| |
− | {{code|text=
| |
− | snort -i wlan0
| |
− | }}
| |
− |
| |
− | By default, the packets will be displayed to STDOUT as packets are capture, which isn't particularly useful. In order to log to a tcpdump-syntax file, you can use the -l option, for example:
| |
− |
| |
− | {{code|text=
| |
− | snort -l /var/log/sniff/
| |
− | }}
| |
− |
| |
− | In order to read the logs, use a program capable of reading tcpdump-style logs - with tcpdump, use the -r option to read - you may wish to pipe it through less for readability:
| |
− |
| |
− | {{code|text=
| |
− | tcpdump -r /var/log/sniff/snort.log.03229112 | less
| |
− | }}
| |
− |
| |
− |
| |
− | Some other useful options:
| |
− |
| |
− | * -v: show only packet headers
| |
− | * -vd: show bothc packet headers and data
| |
− |
| |
− | ===Rules===
| |
− |
| |
− | Under its default configuration, Snort really isn't much more useful than a packet sniffer - its power as an intrusion detection system comes from its power to process received packets and raise a flag based on a file containing directives on how to treat malformed & potentially malicious packets, which is known as a rule file.
| |
− |
| |
− | Enable processing a rule file in snort with the -c option, which takes the path to a rule file as its argument.
| |
− |
| |
− | A snort rule is composed of two parts: the rule header and the rule options. The rule header contains the action of the rule, its protocol, source and destination IP addresses and netmasks, and information regarding the source and target ports. The option section contains the details of the alert messages and information concerning which parts of the packet should be examined.[ftp://petrinet.dvo.ru/pub/Vyatta/build-iso/pkgs/vyatta-snort/debian/my/snort_rules.html]
| |
− |
| |
− | ====Rule Headers====
| |
− |
| |
− | <b>Rule Actions</b>
| |
− |
| |
− | There are available actions to a snort rule:
| |
− | *alert: generates an alert flag of some kind when the rule is matched
| |
− | *log: quietly logs the packet
| |
− | *pass: forget about the packet
| |
− |
| |
− | <b>Protocols</b>
| |
− |
| |
− | There are three protocol options snort will look for:
| |
− | *tcp
| |
− | *udp
| |
− | *icmp
| |
− |
| |
− | These are pretty self-explanatory.
| |
− |
| |
− | <b>IP Addresses</b>
| |
− |
| |
− | Source and destination IP addresses to apply the rule to can be specified next, in the format 'source IP -> destination IP'. It is possible to use CIDR notation - for example, to indicate anything from the internl network, you can use 192.168.1.0/24. You can also prepend an IP address with the ! operator to indicate any packet NOT from the stated IP address. Depending on the direction of the arrow (-> or <-), you can also specify whether the rule applies to incoming our outgoing traffic.
| |
− |
| |
− | <b>Port Number</b>
| |
− |
| |
− | The final part of the header for a rule is the port reference, which can be in several formats. If a number is given by itself, the rule will apply only to that port. A range of ports can also be specified with the colon.
| |
− |
| |
− | Based on this, here is a sample rule without the option section:
| |
− |
| |
− | {{code|text=
| |
− | alert tcp !192.168.1.0/24 any -> !192.168.1.0/24 31337 (OPTION DETAILS GO HERE)
| |
− | }}
| |
− |
| |
− | This particular rule flags an alert on any host from outside of the internal network trying to make a TCP connection on port 31337.
| |
− |
| |
− | ====Rule Option Section====
| |
− |
| |
− | The rule options dictate how a flag is handled, and what procedure is taken when a flag appears. They are encapsulated in parentheses after the rule header, and each option is seperated by a semicolon.
| |
− |
| |
− | Rule Options:
| |
− |
| |
− | <b>msg</b>
| |
− |
| |
− | {{code|text=
| |
− | msg: "message";
| |
− | }}
| |
− |
| |
− | Gives a message to print along with the packet dump.
| |
− |
| |
− | <b>logto</b>
| |
− |
| |
− | {{code|text=
| |
− | logto: "filename";
| |
− | }}
| |
− |
| |
− | log all packets with this flag to a special log file, specified.
| |
− |
| |
− | <b>minfrag</b>
| |
− |
| |
− | {{code|text=
| |
− | minfrag: "number";
| |
− | }}
| |
− |
| |
− | Sets the minimum size (bytes) of a fragmented packet. This is useful, as some forms of invasive port scanning use fragmented packets to evade firewalls and intrusion detection systems.
| |
− |
| |
− | <b>ID</b>
| |
− |
| |
− | {{code|text=
| |
− | id: "number";
| |
− | }}
| |
− |
| |
− | Searches for a match in the IP header. Good for combatting some programs that set these to specific values.
| |
− |
| |
− | <b>Content</b>
| |
− |
| |
− | {{code|text=
| |
− | content: "string";
| |
− | }}
| |
− |
| |
− | A very important option: searches for content in packets received. If the content is matched exactly, the option string continues - otherwise, it is terminated and the packet does not flag. Binary search strings can be represented as hexadecimal bytecode and enclosed with the pipe character '|'. Note that this is computationally expensive to run on each packet.
| |
− |
| |
− | <b>Depth</b>
| |
− |
| |
− | {{code|text=
| |
− | depth: "number";
| |
− | }}
| |
− |
| |
− | A content option modifier that specifies how much of the packet to search for the string match before giving up. Useful for making searches more efficient, as it is often unnecessary to search further than the first 20 bytes.
| |
− |
| |
− | <b>Flags</b>
| |
− |
| |
− | {{code|text=
| |
− | flags: "values";
| |
− | }}
| |
− |
| |
− | A very important feature for detecting scans. Most port scanners (including nmap) use strategically placed flags in a packet to gain information on the operating system. This option allows you to set certain flags to "watch out for".
| |
− |
| |
− | Flag Options:
| |
− | *F: FIN
| |
− | *S: SYN
| |
− | *R: RST
| |
− | *P: PSH
| |
− | *A: ACK
| |
− | *U: URG
| |
− | *2: reserved 2-bit
| |
− | *1: reserved 1-bit
| |
− |
| |
− | Note that this option fails unless ALL of the specified flags are set, so don't just set them all in one rule or it'll only flag a warning if someone sends a packet containing every flag - an unlikely occurrence.
| |
− |
| |
− | ====Example Rule====
| |
− |
| |
− | An example rule to make the syntax clear:
| |
− |
| |
− | {{code|text=
| |
− | alert tcp !192.168.1.0/24 80 -> 192.168.1.0/24 any(msg: "Data received on port 80."; logto: "/var/log/sniff/port-80/")
| |
− | }}
| |
| | | |
| | | |
| [[Category:Countermeasures]][[Category:Information]] | | [[Category:Countermeasures]][[Category:Information]] |