Nemesis is a packet generator, which can be
downloaded from the net. It comes in a zip file, nemesis-1.4beta3.zip. Unzip
the file to c:\ and then run the exe file nemesis.
On doing so, it comes back with usage
instructions. So we run it as
nemesis tcp
This command creates a tcp packet and then
displays a message, TCP packet injected. However, we are yet ignorant about the
packet this tool creates by default. Hence it is safer to use the -v option or
verbose where nemesis displays the packet it sends across.
nemesis tcp -v
TCP Packet Injection -=- The NEMESIS
Project Version 1.4beta3 (Build 22)
[IP] 196.254.34.0 > 196.254.34.0
[IP ID] 65286
[IP Proto] TCP (6)
[IP TTL] 255
[IP TOS] 00
[IP Frag offset] 0000
[IP Frag flags]
[TCP Ports] 65286 > 65286
[TCP Flags] SYN
[TCP Urgent Pointer] 0
[TCP Window Size] 4096
[TCP Seq number] 2293476
Wrote 40 byte TCP packet.
TCP Packet Injected
The output shows that nemesis creates a 40-byte bytes packet using some random IP addresses. Lets us now change each and every option in the above packet and include a payload too.
C:\nemesis-1.4beta3>nemesis tcp -v -s 1 -P vijay.txt -w 2 -u 3 -x 80 -y 6 -fSA
-t 4 -T 5 -I 7 -S 1.1.1.1 -D 70.0.0.3 -a 9
TCP Packet Injection -=- The NEMESIS
Project Version 1.4beta3 (Build 22)
[IP] 1.1.1.1 > 70.0.0.3
[IP ID] 7
[IP Proto] TCP (6)
[IP TTL] 5
[IP TOS] 0x04
[IP Frag offset] 0000
[IP Frag flags]
[TCP Ports] 80 > 6
[TCP Flags] SYN ACK
[TCP Urgent Pointer] 3
[TCP Window Size] 2
[TCP Ack number] 9
[TCP Seq number] 1
Wrote 67 byte TCP packet.
TCP Packet Injected
-s 1 make the sequence number 1 and -a sets
the acknowledgement number.
-P is followed by the payload of the
packet. Vijay.txt contians any arbitrary text that will be send as tcp data.
-w 2 makes the tcp window size 2
-u 3 set the urgent pointer offset into the
data as 3.
-x 80 sets the source port to 8 and -y set
the destination port to 6.
-f allows us to set the flags, S for SYN A
for ACK.
-t 4 is for the Type of Service
-T 5 for the Time to live TTL
-I 7 sets the id of the package to 7.
-S 1.1.1.1 set the source IP address and -D
set the sestination to 70.0.0.3. The machine running sort is on 70.0.0.3.
We can constantly keep making changes to
this packet and then send it across and see how snort responds to it. The above
command line argument can be placed in a.bat so that it is simpler to execute
the command each time.
Snort
has been installed into the subdirectory c:\snort by running the installer
snort_233_build14_installer.exe. To run snort we move to directory c:\snort\bin
and simply run it as:
snort
On doing so, we are presented with a list
of options that can be used besides snort telling us; we quote ' Uh, you need
to tell me to do something...'
So,
run snort as
>snort
-v
where
v stands for verbose. Then run our newly created packet from nemesis on IP
address 70.0.0.1 The output we see in snort is shown below.
05/25-14:18:56.650926
ARP who-has 70.0.0.3 (FF:FF:FF:FF:FF:FF) tell 70.0.0.1
05/25-14:18:56.650997
ARP reply 70.0.0.3 is-at 0:0:E8:DF:60:57
05/25-14:18:56.701956
1.1.1.1:80 -> 70.0.0.3:6
TCP
TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
The
first two packets are ARP based, the Address Resolution Protocol. This protocol
follows a simple logic. We are asking our machine with the ip address 70.0.0.1
to send a packet to 70.0.0.3. However, the ethernet address of a machine with
the ip address 70.0.0.3 is not known. Thus snort first sends a broadcast packet
from 70.0.0.1 asking for the ethernet address of machine with the IP address
70.0.0.3.
If
the computer is on the network, an ARP reply is received form the machine with
IP address 70.0.0.3 giving its ethernet address, i.e 0:0:E8:DF:60:57. Then,
nemesis sends a packet with the source ip as 1.1.1.1 at port 80 to 70.0.0.3 at
port 6. This has a TTL of 5, tos of 4 id 7 and total length 67. The sequence
number is 1, ack 9, window size 2 and flags A And S are on. This newly
generated packet is then sent out. Lets display some more of the packet.
snort
-vd
05/25-14:26:25.940785
1.1.1.1:80 -> 70.0.0.3:6
TCP
TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
56
69 6A 61 79 20 4D 75 6B 68 69 20 69 73 20 61
Vijay Mukhi is a
20
67 72 65 61 74 20 67 75 79 0A
great guy.
The
same packet is now sent across but now the -d option is added to snort. The -d
option displays the application layer, as a result we see the payload that is
present in vijay.txt.
snort
-vde
05/25-14:29:29.228783
0:0:E8:EE:EC:88 -> 0:0:E8:DF:60:57 type:0x800 len:0x51
1.1.1.1:80
-> 70.0.0.3:6 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
56
69 6A 61 79 20 4D 75 6B 68 69 20 69 73 20 61
Vijay Mukhi is a
20
67 72 65 61 74 20 67 75 79 0A
great guy.
The
-e displays, the help calls it, the second layer header info or the data link
layer. In our case, it is the ethernet header. The first is the source ethernet
address of the machine sending the packet, 70.0.0.1 is the machine running
nemesis. The second ethernet address is of the destination which arp receives,
0:0:E8:DF:60:57, the ethernet address of machine 70.0.0.3.
When
the destination IP address of the packet is changed to 70.0.0.4, snort shows
the following. We changed -D 70.0.0.3 to -D 70.0.0.4.
05/25-14:34:16.684193
ARP who-has 70.0.0.4 (FF:FF:FF:FF:FF:FF) tell 70.0.0.1
05/25-14:34:16.789271
ARP who-has 0.0.0.0 (FF:FF:FF:FF:FF:FF) tell 70.0.0.1
05/25-14:34:16.889793
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x51
1.1.1.1
-> 70.0.0.4 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67 MF
Frag
Offset: 0x0000 Frag Size: 0x002F
00
50 00 06 00 00 00 01 00 00 00 09 50 12 00 02
.P..........P...
EA
70 03 00 56 69 6A 61 79 20 4D 75 6B 68 69 20
.p..Vijay Mukhi
69
73 20 61 20 67 72 65 61 74 20 67 75 79 0A
is a great guy.
Firstly,
snort acts like a sniffer. Therefore it sniffs all traffic on a network besides
the ones destined for the machine it is based on. So, when machine 70.0.0.1
sends a packet for 70.0.0.4, snort watches it. The course of events, wherein
first 70.0.0.1 send out an ARP packet for ethernet address 70.0.0.4 is
tracked. Then when no reply is
received, it asks for IP address 0.0.0.0. Further when there is no response, it
sends out a broadcast packet with IP and TCP so that any machine can pick it
up.
It
is safer to use snort with the option -dev.
The
above is the first mode of snort as a packet sniffer.
Secondly,
snort acts as a packet logger.
>snort
-dev -l vijay
ERROR:
log directory 'vijay' does not exist
Fatal
Error, Quitting..
The
-l option demands logging of all packets in directory vijay. However, since
directory vijay does not exists it emits an error. We have no choice but to
create vijay in snort\bin.
Snort\bin>md
vijay
Now
execute the previous snort command and then inject a package from nemesis. You
will see the following. The packets as before get displayed on the screen in
addition to it being logged in the vijay directory. The directory vijay shows
us three entities. First, is ARP.ids which refer to the ARP packets as always.
ARP.ids
05/25-14:42:57.718056
ARP who-has 70.0.0.4 (FF:FF:FF:FF:FF:FF) tell 70.0.0.1
05/25-14:42:57.823351
ARP who-has 0.0.0.0 (FF:FF:FF:FF:FF:FF) tell 70.0.0.1
Then
there is a directory called 1.1.1.1,
the source IP address is on our packet.
05/25-14:42:57.923964
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x51
1.1.1.1
-> 70.0.0.4 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67 MF
Frag
Offset: 0x0000 Frag Size: 0x002F
00
50 00 06 00 00 00 01 00 00 00 09 50 12 00 02
.P..........P...
EA
70 03 00 56 69 6A 61 79 20 4D 75 6B 68 69 20
.p..Vijay Mukhi
69
73 20 61 20 67 72 65 61 74 20 67 75 79 0A
is a great guy.
This
is the same packet as before. Also there is a third directory 70.0.0.1, that
logs packets from this IP address.
Thus
each time a packet comes in, the source ip address decides which directory it
goes under. This is a neat way of cataloging the packets as per the source who
sends it.
---------------------
Create
a file a.bat as in
a.bat
rd
vijay /s
md
vijay
snort
-dev -l vijay -c a.conf
The
-c option tells snort to read the rules present in snort.conf and apply these
rules to all packets on the network. We also delete the directory vijay so that
we can start from scratch each time. We also change the -DM flag to -DF which
indicates no fragmentation in nemesis.
a.conf
alert
tcp any any -> any any (msg:"Rule 1"; )
Run
a.bat and in the vijay directory see the following
alert.ids
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/25-14:51:58.819959
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x51
1.1.1.1:80
-> 70.0.0.4:6 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67 DF
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
The
conf file carries snort rules. Each rule starts with the action snort has to
perform. alert means creating an alert . An alert is a notification when
something goes wrong. After tcp, the next two any are the source IP addresses
and port number. any is equivalent to all, which in english means match all
source IP addresses and port numbers on the packet. The -> is a sign towards
destination . The next two any any refer to destination IP address and port.
Thus
our rule matches all packets. The () denotes option and the keyword msg
displays a message in the alert file. Thus as any packet matches our rule, we
see Rule 1 in stars. The rest of the packet simply gets repeated.
a.conf
alert
tcp any any -> any any (msg:"Rule 1"; )
alert
tcp any any -> any any (msg:"Rule 2"; )
alert.ids
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/25-14:58:14.634010
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x51
1.1.1.1:80
-> 70.0.0.4:6 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67 DF
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
[**]
[1:0:0] Rule 2 [**]
[Priority:
0]
05/25-14:58:14.634010
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x51
1.1.1.1:80
-> 70.0.0.4:6 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67 DF
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
One
more rule is added but with changes in the msg. Thus we get two alerts for the
one packet saying Rule 1 and Rule 2. We can raise as many alerts we want for a
rule. The syntax for any option is keyword colon ending in a ;.
a.conf
alert
tcp any any -> any any (msg:"Rule 1";content:"Vijay"; )
alert
tcp any any -> any any (msg:"Rule 2";content:"sonal"; )
alert.ids
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/25-15:01:59.298876
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x51
1.1.1.1:80
-> 70.0.0.4:6 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:67 DF
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
We
now add a new option, content. This matches content of the packet. It is case
sensitive and as our payload carries Vijay Rule 1 matches but Rule 2 does not.
This is how an IDS can test for shellcode, viruses etc by looking at the
content that is flowing though.
We
change our payload file Vijay.txt to Vijay and sonal and get.
a.conf
alert
tcp any any -> any any (msg:"Rule 1";content:"Vijay"; )
alert
tcp any any -> any any (msg:"Rule 2";content:"sonal"; )
alert.ids.
[**]
[1:0:0] Rule 2 [**]
[Priority:
0]
05/25-15:05:51.710700
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:80
-> 70.0.0.4:6 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:56 DF
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/25-15:05:51.710700
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:80
-> 70.0.0.4:6 TCP TTL:5 TOS:0x4 ID:7 IpLen:20 DgmLen:56 DF
***A**S*
Seq: 0x1 Ack: 0x9 Win: 0x2
TcpLen: 20
The
above payload matches both the rules and therefore we get two alerts. Thus as
many alerts that match will get displayed.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D 1.1.1.2
vijay.txt
vijay
and sonal
alert
tcp any any -> any any
(msg:"Rule 1"; content: "VIJAY"; )
alert
tcp any any -> any any
(msg:"Rule 2"; content: "VIJAY"; nocase;)
[**]
[1:0:0] Rule 2 [**]
[Priority:
0]
05/27-10:47:30.727080
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
content keyword is case sensitive. The file vijay.txt contains vijay in lower
case and the rule contains VIJAY in upper case and hence no match. The second
rule uses the nocase keyword and hence there is a match. In this manner a case
insensitive match can be checked.
nemessis
nemesis
tcp -v -P vijay.txt -x 1025 -y 80 -S
1.1.1.1 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -x 1025 -y 81 -S
1.1.1.1 -D 70.0.0.5
a.conf
alert
tcp any any -> any 80 (msg:"Http Packet"; )
alert.ids
[**]
[1:0:0] Http Packet [**]
[Priority:
0]
05/26-10:12:17.205436
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:1025
-> 70.0.0.4:80 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
One
of the many things that we may want is an alert on every http packet received.
Nemesis sends two packets: one http
packet for IP address 70.0.0.4 and the destination port is 80 and the other
destined for port 81 with the IP address 70.0.0.5. The a.conf simply replaces
the word any with 80. This earlier meant that any port number would trigger the
event. Now only packets where the destination port number is 80 will trigger
the alert. Thus even though we have sent two packets and both get seen on the
console, only packet with IP address 70.0.0.4 or port 80 gets seen. Thus shows
how a specific port either source or destination can be filtered. Thus if we
are aware of a certain trojan using port 7777, an alert can be set for it.
nemesis
tcp -v -P vijay.txt -x 1025 -y 80 -S
1.1.1.1 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -x 1025 -y 1200 -S
1.1.1.1 -D 70.0.0.5
a.conf
alert
tcp any any -> any 1024: (msg:"Http Packet"; )
alert.ids
[**]
[1:0:0] Http Packet [**]
[Priority:
0]
05/26-10:22:46.664743
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:1025
-> 70.0.0.5:1200 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Here
we want to catch any packet with the destination port larger than 1024. IANA
has reserved the first 1024 port for reserved services and hence the source
port should be and must be larger than 1024 but not the destination port.
Normally if the destination port is larger than 1024 we can safely assume that
we are connecting to an unknown service or un-standardized servers.Trojans have
to listen on ports larger than 1024.
In
our conf file we simply write the port number as 1024: signifying no upper
limit. This then defaults to 65536 thereby allowing us to capture all packets
which have a destination port number larger than 1024. Thus packet IP dest
70.0.0.4 does not trigger the alert whereas IP packet 70.0.0.5 does.
nemesis
tcp -v -P vijay.txt -x 1025 -y 8000 -S
1.1.1.1 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -x 1025 -y 1200 -S
1.1.1.1 -D 70.0.0.5
a.conf
alert
tcp any any -> any 1024:2400 (msg:"Http Packet"; )
alert.ids
[**]
[1:0:0] Http Packet [**]
[Priority:
0]
05/26-10:28:48.206324
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:1025
-> 70.0.0.5:1200 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
now send two packets, one for port number 8000 the other for port number 1200.
In the conf file we specify a port number from 1024 to 2400. Thus the IP address
70.0.0.5 with port number 1200 triggers the alert. This example is to show you
the setting of maximum and minimum range.
nemesis
tcp -v -P vijay.txt -x 1025 -y 8000 -S
1.1.1.1 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -x 1025 -y 12 -S
1.1.1.1 -D 70.0.0.5
alert
tcp any any -> any !1024:2400 (msg:"Http Packet"; )
[**]
[1:0:0] Http Packet [**]
[Priority:
0]
05/26-10:32:30.374329
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:1025
-> 70.0.0.4:8000 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
! sign reverses the condition and therefore Ip address 70.0.0.4 with port
number 8000 triggers the alert and not ip address 70.0.0.5 with port number
1200.
alert
tcp any any -> any 21,23 (msg:"Services"; )
You
cannot specify different port numbers separated by commas.
nemesis
tcp -v -P vijay.txt -x 1025 -y 80 -S
1.1.1.1 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -x 10 -y 80 -S
1.1.1.1 -D 70.0.0.5
nemesis
tcp -v -P vijay.txt -x 1025 -y 1200 -S
1.1.1.1 -D 70.0.0.6
alert
tcp any 1024: -> any 80 (msg:"HTTP"; )
[**]
[1:0:0] HTTP [**]
[Priority:
0]
05/26-10:59:13.067022
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:1025
-> 70.0.0.4:80 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
For
an alert to be triggered on a http packet, the source port must be larger than
1024 and the destination port 80. The first IP address 70.0.0.4 matches as its
source port is 1025 larger than 1024 and the destination port 80. However, the
ip address 70.0.0.5 does not match as its source port is less than 1024 10 and
the last ip address 70.0.0.6 has both conditions not matching.
The
approach taken for the http protocol can now be implemented for a protocol that
could be a security risk. HTTP is not a security risk.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -S 2.2.2.2 -D 70.0.0.5
alert
tcp 1.1.1.1 any -> any any (msg:"Bad IP found"; )
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:03:58.737963
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Lets
apply the same logic of port numbers to IP addresses. We have identified IP
address 1.1.1.1 as the bad egg. So we alert whenever we get a packet from this
IP address. We send two packets from IP address 1.1.1.1 and 2.2.2.2 and only the
IP address 1.1.1.1 triggers the alert.
alert
tcp [1.1.1.1,2.2.2.2] any -> any any
(msg:"Bad IP found"; )
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:07:05.538656
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:07:06.028921
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
2.2.2.2:65286
-> 70.0.0.5:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
In
square brackets, two Ip addresses are added, therefore both packets trigger off
an alert. Using square brackets we can string multiple IP's together. Too bad
square brackets do not work with port numbers.
nemesis
tcp -v -P vijay.txt -S 1.1.1.0 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D 70.0.0.5
nemesis
tcp -v -P vijay.txt -S 1.1.1.2 -D 70.0.0.6
nemesis
tcp -v -P vijay.txt -S 1.1.1.3 -D 70.0.0.7
alert
tcp 1.1.1.1/32 any -> any any
(msg:"Bad IP found"; )
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:10:17.446850
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 70.0.0.5:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
send 4 packets with IP address 1.1.1.0 to 1.1.1.3 but only one 1.1.1.1 sends
the alert. This is because 1.1.1.1/32 matches one IP address only 1.1.1.1.
alert
tcp 1.1.1.1/31 any -> any any
(msg:"Bad IP found"; )
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:12:22.433408
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:12:22.914141
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 70.0.0.5:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Now
two packets match as 1.1.1.1/31 stands for 1.1.1.0 and 1.1.1.1.
nemesis
tcp -v -P vijay.txt -S 1.1.1.0 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D 70.0.0.5
nemesis
tcp -v -P vijay.txt -S 1.1.1.2 -D 70.0.0.6
nemesis
tcp -v -P vijay.txt -S 1.1.1.3 -D 70.0.0.7
nemesis
tcp -v -P vijay.txt -S 1.1.1.4 -D 70.0.0.7
nemesis
tcp -v -P vijay.txt -S 1.1.1.5 -D 70.0.0.7
alert
tcp 1.1.1.1/30 any -> any any
(msg:"Bad IP found"; )
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:14:16.218506
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:14:16.699272
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 70.0.0.5:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:14:17.179932
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.2:65286
-> 70.0.0.6:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:14:17.670646
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.3:65286
-> 70.0.0.7:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
1.1.1.1/30
stands for four IP addresses 1.1.1.10 to 1.1.1.3. The last one 1.1.1.4 does not
match. This is called CIDR or classless Inter Domain Routing. A class C address
is /24, class B /16 and class A /8. This is how internet addresses are given
out these days, you get a number of IP addresses which is a power of 2.
nemesis
tcp -v -P vijay.txt -S 1.1.1.0 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -S 1.1.2.1 -D 70.0.0.5
alert
tcp 1.1.1.1/24 any -> any any
(msg:"Bad IP found"; )
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:17:31.750052
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
assume that 1.1.1 is a class C address. Thus 1.1.1.1/24 matches any IP address
starting with 1.1.1. Even though we specified 1.1.1.1 and not 1.1.1.0 it
matches 1.1.1.0. The 1.1.2.1 does not match. As a result, an alert can be
triggered off on an entire class of addresses.
nemesis
tcp -v -P vijay.txt -S 1.1.1.0 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -S 2.2.2.2 -D 70.0.0.5
nemesis
tcp -v -P vijay.txt -S 3.2.2.2 -D 70.0.0.5
alert
tcp ![1.1.1.1/24,2.2.2.2] any -> any
any (msg:"Bad IP found"; )
[**]
[1:0:0] Bad IP found [**]
[Priority:
0]
05/26-11:21:19.657660
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
3.2.2.2:65286
-> 70.0.0.5:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Our
home network is the C class IP address 1.1.1 and thus we do not want any of our
machines triggering off an alert on them. Also 2.2.2.2 is on our network. Since these two blocks are not to be
considered, we use the negation operator to make sure that no machine on our
network triggers off an alert on them.
Thus
we have triggered alerts on source and destination ports and IP addresses. Lets
now generate alerts on protocol.
alert
icmp any any -> any any
(msg:"icmp packet detected"; )
[**]
[1:0:0] icmp packet detected [**]
[Priority:
0]
05/26-13:09:38.419103
0:0:E8:EE:EC:88 -> 0:0:E8:DF:60:57 type:0x800 len:0x4A
70.0.0.1
-> 70.0.0.3 ICMP TTL:128 TOS:0x0 ID:3945 IpLen:20 DgmLen:60
Type:8 Code:0
ID:512 Seq:256 ECHO
On
sending the same three packets on the network, we get no alert as we have
changed our protocol to icmp. Thus tcp packets will give us no alerts. We then
run ping on 70.0.0.1 as
ping
70.0.0.3
This
sends a large number of ping packets on the network thus triggering a large
number of alerts.
nemesis
tcp -v -P vijay.txt -S 1.1.1.0 -D 70.0.0.4
Vijay.txt
vijay
and sonal
alert
tcp any any -> any any (msg:"Rule 1";content:
"vijay";offset: 0;)
alert
tcp any any -> any any (msg:"Rule 2";content: "vijay";
offset: 1;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-13:22:46.566844
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
file a.conf has two rules. The offset keyword has a default value of 0 and
specifies the location in the payload the content should be searched. In the first rule, we specify that the
search for vijay should start from the beginning and thus we get a match. In
the second rule we start the search from the 1st byte or second byte in the
payload and thus rule 2 does not match. The offset is used to hasten the search
in cases when we are well acquainted that the content never starts from the
beginning.
alert
tcp any any -> any any (msg:"Rule 1";content:
"sonal";offset: 5; depth: 10;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-13:32:01.336824
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
depth keyword specifies the no. of bytes that should it check. Here above, we
are checking for sonal from bytes 6 to 16 i.e. we are checking from the 6th
byte, 10 more bytes.
alert
tcp any any -> any any (msg:"Rule 1";content:
"sonal";offset: 10; depth: 5;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-13:38:23.893098
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Here
a match is met as we are searching for sonal from bytes 5 to 15. The words
vijay and a and take up exactly 10 bytes.
alert
tcp any any -> any any (msg:"Rule 1";content:
"sonal";offset: 9; depth: 5;)
This
gives us no alert as we have missed the match by 1 byte. We start searching
from the space and not s of sonal. This is how we can search in the content
from a fixed offset and for a certain number of bytes only. If the depth is
less than the size of the string sonal in this case has a length 5, then snort
does a sanity check and gives an error.
alert
tcp any any -> any any (msg:"Rule 1";content: "|76
69|";)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-13:44:05.156019
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Many
a times we prefer testing bytes to string. For this purpose, we place these
bytes in the pipe sign. We trigger an alert as hex 76 and 69 stand for the
ascii characters v and i.
alert
tcp any any -> any any (msg:"Rule 1";content: "|76
69|ja|79|";)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-13:46:27.919219
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.0:65286
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We can mix and match ascii and binary
content. 79 is the ascii character y. This is very useful for finding certain
patters in shell code. This can also be used in finding out a nop sledge a series
of zeroes or no ops. Also certain assembler opcodes can also be detected. Every
exploit has a signature and we trigger an alert by finding a match of this
signature.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1
-x 80 -D 70.0.0.4
nemesis
tcp -v -P vijay.txt -S 70.0.0.4 -y 80 -D 1.1.1.1
alert
tcp any any <> 1.1.1.1 80 (msg:"Rule 1";)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-17:17:45.404962
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:80
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-17:17:45.975667
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
70.0.0.4:65286
-> 1.1.1.1:80 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
have sent two packets one with a Source IP 1.1.1.1 and port number of 80 and
the other with destination port 80 and iP address 1.1.1.1. Both packets trigger
off an alert as the direction <> says that either side can be source or
destination. Thus if either the source or destination IP and port match, an
alert gets triggered. There is, as we have seen before, a -> operator but no
<- operator.
config
classification: buffer-overflow,A buffer overflow code was detected,3
alert
tcp any any <> any any
(msg:"Rule 1";sid: 420; rev:6; classtype:
buffer-overflow;priority: 1; reference: bugtraq,120; )
[**]
[1:420:6] Rule 1 [**]
[Classification:
A buffer overflow code was detected] [Priority: 1]
05/26-17:41:25.731519
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:80
-> 70.0.0.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[Xref
=> bugtraq 120]
Now
that we are a bit comfortable, lets spend some time understanding the alert
output. The first line starts with two stars and ends with two stars basically
for *good luck*. The number refers to the modules within snort who generates
the alert. The number 1 means a general snort alert, 100 means the portscanner
and so on. We have no control on
number, it basically helps us to understand what part of snort wrote the
alert. Then comes the sid. This is a number that uniquely identifies snort rules.
There will be some millions of snort rules and each rule is given a number. The
first 100 are reserved, for what nobody knows. 100 to 1,000,000 are reserved
for rules that come with snort, *there are really thinking big here*. Larger
than 1,000,000 are for us lowly mortals. Our sid is 420 which is the second
parameter.
Every
rule can be revised, thus we the rev keyword which speaks about the revision
number. In our case this is the sixth revision. The classtype specifies what
type of event occurred to trigger this
alert. We use the classtype keyword with a classname. There are a large number
of classname defined along with snort which we will use later. To create a
classname we use the keyword config classification with the classname
buffer-overflow and follow this with a english explanation. The class name will
not be dispalyed but the english expalnation will be.
The
priority keyword is used to figure out how to treat this alert, this overrides
the priority of the classtype. Finally the reference keyword says where to look
to get more information on this exploit. In our case we have specified that
bugtraq archive 120 has more information.
Lots
of people maintain external identification systems where every exploit is given
a unique number basically to identify that we are talking about the samething.
Snort
supports bugtraq, cve, nessus, arachnids, mcafee and the general url. This can
aid us into knowing more about what happened.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -T 10
nemesis
tcp -v -P vijay.txt -S 1.1.1.2 -T 4
nemesis
tcp -v -P vijay.txt -S 1.1.1.3 -T 13
nemesis
tcp -v -P vijay.txt -S 1.1.1.4 -T 120
nemesis
tcp -v -P vijay.txt -S 1.1.1.5 -T 40
alert
tcp any any <> any any
(msg:"Rule 1"; ttl: 10; )
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-18:07:13.244019
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 196.254.34.0:65286 TCP TTL:10 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
send 5 packets with varying ttl's. The rule signals an alert only on those
packets that have a ttl of 10. Hence one alert is send with IP address 1.1.1.1.
alert
tcp any any <> any any
(msg:"Rule 1"; ttl:<5; )
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-18:10:58.373599
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.2:65286
-> 196.254.34.0:65286 TCP TTL:4 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Here
all those packets with a ttl of less than 5 are trapped, 1.1.1.2 sends off the
alert.
alert
tcp any any <> any any
(msg:"Rule 1"; ttl:10-15; )
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-18:12:20.631191
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 196.254.34.0:65286 TCP TTL:10 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-18:12:21.802452
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.3:65286
-> 196.254.34.0:65286 TCP TTL:13 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
A
range can be given with a - sign. Here we have packets with ttl's ranging from
10 to 15, i.e. 10 and 13, therefore we see two alerts.
alert
tcp any any <> any any
(msg:"Rule 1"; ttl:>50; )
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/26-18:13:55.531572
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.4:65286
-> 196.254.34.0:65286 TCP TTL:120 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Finally
all ttl's larger than 50 triggers one alert as we have one packet with a ttl of
120. In future normally all options allow us a single value or a range using -
or a higher and lower range.
alert
tcp any any <> any any
(msg:"Rule 1"; sameip; )
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D 1.1.1.1
nemesis
tcp -v -P vijay.txt -S 1.1.1.2 -D 1.1.1.1
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-10:09:41.114732
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.1:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Many
a times in the past we have heard of syn flloding where a syn packet is sent
but the 3 way handshake is not completed. Some guys found out that on the
Windows OS if a syn packet is sent with the same source and destination IP
address, all networking activities would stop and there was no option but a
reboot to set it right. This was called the land attack.
The
sameip keyword in the alert checks whether the source and destination IP
addresses are the same. We send two packets where the first has the same source
and destination IP addresses 1.1.1.1 and in the second they are different. The
first packet triggers off an alert.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D 1.1.1.2
nemesis
tcp -v -P vijay1.txt -S 1.1.1.1 -D 1.1.1.3
nemesis
tcp -v -P vijay2.txt -S 1.1.1.1 -D 1.1.1.4
vijay1.txt
one
vijay2.txt
two
alert
tcp any any -> any any
(msg:"Rule 1"; content: "vijay";)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-10:24:43.356907
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
send three packets and the alert.ids shows us only one alert as we have only
one packet that has the content vijay. However in the vijay subdirectory we see
a directory 1.1.1.1. This is because all three packets have the IP address of
1.1.1.1. Thus in the log file packets are found in directories, as mentioned
before, based on the source IP addresses. This makes sense as we can now simply
move into a directory to find all packets from a certain source. There is only
one file tcp_65286-65286.ids which has only one entry similar to the alert
file.
tcp_65286-65286.ids
[**]
Rule 1 [**]
05/27-10:24:43.356907
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
76
69 6A 61 79 20 61 6E 64 20 73 6F 6E 61 6C 0A
vijay and sonal.
Thus
alert corresponds to log and alert at the same time. The other two packets are
not logged as they do not match a condition.
Lets
take the buffer overflow. The first packet start with some valid bytes say
vijay but the actual exploit lies in the coming packets. Let see how to build
such a system.
activate
tcp any any -> any any (msg:"Rule
1"; content: "vijay"; activates: 5;)
dynamic tcp any any -> any any (msg:"Rule 2";activated_by: 5;
count: 2;)
alert.ids
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-10:32:30.439884
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
tcp_65286-65286.ids
[**]
Rule 1 [**]
05/27-10:32:30.439884
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
76
69 6A 61 79 20 61 6E 64 20 73 6F 6E 61 6C 0A
vijay and sonal.
[**]
Rule 2 [**]
05/27-10:32:31.000762
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x3C
1.1.1.1:65286
-> 1.1.1.3:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:45
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
6F
6E 65 0A 0A
one..
[**]
Rule 2 [**]
05/27-10:32:31.561681
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x3C
1.1.1.1:65286
-> 1.1.1.4:65286 TCP TTL:255 TOS:0x0 ID:65286 IpLen:20 DgmLen:45
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
74
77 6F 0A 0A two..
The
alert.ids file remains the same as before. This is because we have simply
triggered one alert. Our aim is to log the packets after the one we have found.
Take a look at the tcp_65286-65286.ids file. We see the next two packets logged
after the Rule 1 packet.
This
makes sense as we can now figure out the exploit in the log file thus not
cluttering alert file. In a sense we are logging packets after a condition has
been satisfied. The activate rule is a super set of alert. It is basically to
trigger an alert if the condition is met. In our case a packet with content
vijay will trigger off the alert.
We
also have used the keyword activates which looks for a rule that starts with
dynamic. This must have an activated_by keyword with the same number as the
activate rule. If found, execute it. As this rule uses the count keyword
followed by a value of 2, the next two packets get logged also. The dynamic
rule does not get called directly, it gets activated by an activate. In this
manner, one rule can trigger off a large number of other rules.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D 1.1.1.2
nemesis
tcp -v -P vijay1.txt -S 1.1.1.1 -D 1.1.1.3
nemesis
tcp -v -P vijay2.txt -S 1.1.1.1 -D 1.1.1.4
nemesis
tcp -v -P vijay2.txt -S 1.1.1.1 -D 1.1.1.5
We
now add a fourth packet but our log files remain the same as we only log the
next two packets.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -t 5
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -t 6
alert
tcp any any -> any any (msg:"Rule 1"; tos:5; )
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:17:54.036782
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x5 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
send two packets across, one with tos 5
and the other with tos 6. The tos keyword takes a single type of service and
matches it. Thus the packet with tos 5 matches and tos 6 fails.
alert
tcp any any -> any any (msg:"Rule
1"; tos:!0x5;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:20:54.974173
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x6 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
! or negation operator triggers the alert whenever we find a tos that is not 5,
as a result the second packet with tos 6 matches.
alert
tcp any any -> any any
(msg:"Rule 1"; tos:!5;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:22:25.599925
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x5 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:22:26.160705
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x6 ID:65286 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Every
piece of software that we have used so far has bugs, Microsoft or open source.
In the above conf file we have made only one change, we have removed the hex
notation. We always thought that 5 and 0x5 were the same. Snort thinks not and
if we remove the hex notation we get a match on all tos values. Can't figure
out what has gone wrong.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 6
alert
tcp any any -> any any
(msg:"Rule 1"; id:5;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:26:18.281239
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
-I option of nemesis allows us to set the id of a IP packet. Using this option,
we send two IP packets with id 5 and 6. This id field to the best of everyones
knowledge is never used by any protocol. Thus it can be safely ignored. However
some hackers, when they send packets use the same id consistently. Thus we use
the id keyword to alert on such packets. Using alerts can give rise to a large
number of false alarms. The snort manual states that the id 31337 is often used
by hackers. build an alert for this and we will start getting a large number of
false positives. Thus be careful in building alerts. Our advice is build a few
alerts but not generic ones. The id field does not even take a negation
operator. Take a look, the first packet with id 5 gets caught.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5
nemesis
tcp -v -P vijay1.txt -S 1.1.1.1 -D
1.1.1.3 -I 6
vijay.txt
vijay
and sonal
vijay1.txt
one
alert
tcp any any -> any any
(msg:"Rule 1"; dsize: >5;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:35:58.246689
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
send two payloads one with size 16 and the other with size 5. The dsize options
catches packets of a certain size. We want to catch all packets larger than 5
and hence use the dsize keywrd with >5. This helps in catching odd sized
packets.
alert
tcp any any -> any any
(msg:"Rule 1"; dsize: 3<>8;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:42:47.297106
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x3C
1.1.1.1:65286
-> 1.1.1.3:65286 TCP TTL:255 TOS:0x0 ID:6 IpLen:20 DgmLen:45
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
<> can be used as a range and thus 3 <> 8 catches all packets with
a payload size not counting TCP and IP of between 3 and 8. The second packet
has a payload 4 and thus it triggers off.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -fSA
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-11:48:11.096364
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
***A**S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
TCP protocol uses a full byte for flags but the last two from the MSB side
remain unused. There are 6 flags S for SYN, A ACK, R RST, F FIn, P PUSH and U
Urgent Pointer. The number 1 and 2 are for the two reserved bits. In nemesis,
the -f option is used for setting flags. Our packet has two flags set Syn and
Ack. The flags in turn give the TCP protocol the extra bytes. A connection is
started by the SYN flag and the Fin flag ends it. An Rst is sent whenever a
packet received is not valid.
The
flags keyword is used to test the flags and we have tested for the Syn and Ack
flags. As our packet has these flags on, an alert gets triggered.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -fS
We
simply send a packet with the Syn flag on but since we are testing for Syn and
Ack, there is no alert.
alert
tcp any any -> any any
(msg:"Rule 1"; flags:S;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:19:43.992223
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
An
alert is generated as the packet has a SYN and the rule also looks for it.
Thus, the default is an exact macth.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -fSAP
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA;)
To
iterate again we are sending three flags S, P and A but our alert checks for
only two S and A. There is no alert. This can get highly restraining as the
flags must exactly match. To trigger an event, the flags must be changed to
SAP.
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA*;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:24:54.733301
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
***AP*S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
* means or. Thus if any of the flags meet a match the alert is triggered.
alert
tcp any any -> any any
(msg:"Rule 1"; flags:S*;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:26:04.774856
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
***AP*S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
above rule works as long as the syn flag is on.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -fSAP
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 6 -fSA
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 7 -fP
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 8 -fA
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 9 -fS
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 10 -fSP
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA*;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:28:28.660888
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
***AP*S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:28:29.242084
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:6 IpLen:20 DgmLen:56
***A**S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:28:30.383703
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:8 IpLen:20 DgmLen:56
***A****
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:28:30.954243
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:9 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:28:31.525366
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:10 IpLen:20 DgmLen:56
****P*S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Our
rule dictates that either the Syn or Ack flags or both flags must be on in the
packet. Packet with id 5 passes as it has both flags on plus an extra push that
does not come in the way. ID 6 has both Syn and Ack and thus passes. Packet id
7 has only push and hence does not trigger an alert. Packets with id 8 and 9
only have Syn or Ack and hence trigger. Packet ID 10 has Syn and Push and
triggers the event. The * means all but even if one flag matches the trigger
goes on, the other flags do not matter.
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA+;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:33:06.698437
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
***AP*S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:33:07.269587
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:6 IpLen:20 DgmLen:56
***A**S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
The
plus means ‘and’ and therefore it makes sure that if all the flags are present
in the packet the alert sends. In our case, packets with id 5 and 6 are the
only ones that have both Syn and Ack present. Packet 5 may have an extra flag
push, but as it has s and a, it triggers the event. Without a +, it means an exact match no extra flags, the + is
less restrictive, it only says the flags must be there, extras flags will be ignored.
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:36:03.257786
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:6 IpLen:20 DgmLen:56
***A**S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Just
to reiterate, only packet id 6 has only S and A. Thus packet id 5 will not
match.
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA,P;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:37:14.198132
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
***AP*S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:37:14.768869
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:6 IpLen:20 DgmLen:56
***A**S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
We
can add a , after the flags to specify a list of flags to ignore. Thus when it
checks the packet it will check for a SYN and a ACK but will yet match if there
is a Push. Thus after the comma we place a series of flags that are to be
ignored.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -fSAPU
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -fSAP
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -fSP
alert
tcp any any -> any any
(msg:"Rule 1"; flags:SA,P;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:51:53.539290
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
***AP*S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
Our
rule is very clear, the packet must have the Syn and Ack flags on but if there
is a push this is allowed. Thus the only two valid combinations are SA and SAP.
The first packet has the U flag and hence does not match. The second matches as
it has S A and P which is optional. The third does not have the A and hence does not match. The P is optional.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -s 2
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -a 3
alert
tcp any any -> any any
(msg:"Rule 1"; seq: 2;)
alert
tcp any any -> any any
(msg:"Rule 2"; ack: 3;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-13:56:55.251161
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
******S*
Seq: 0x2 Ack: 0x22FEE4 Win: 0x1000
TcpLen: 20
[**]
[1:0:0] Rule 2 [**]
[Priority:
0]
05/27-13:56:55.822513
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x3 Win: 0x1000
TcpLen: 20
The
sequence number field is used by tcp to number the data sent by the packet. In
the three-way handshake, the sequence numbers are exchanged in order to verify
and validate the initial number given to the data sent across.
For
eg, if we have 30 bytes of data to send and a seq no of 12 is sent, we are
specifying that the first byte of data is no 13, the second is no 14, then no
15 and so on. The ACK number simply calls for data from such and such byte
across. Thus an ack of 18 informs that the other side has received bytes 13,
14, 15, 16 and 17 and the data from bytes 18 onwards should be sent. Thus seq
and ack are used for flow control and thus they are the backbone of tcp.
We
have two rules, any packet with a sequence number of 2 is to set off rule 1 as
we are using the keyword seq. The second rule uses the keyword ack to match a
packet with a ack no of 3. Nemesis uses the -s keyword to set the sequence
number to 3 and the second packet uses the ack keyword to set the ack number to
3.
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -s 2
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -a 3
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -a 3 -s 2
alert
tcp any any -> any any (msg:"Rule
1"; seq: 2; ack: 3;)
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-14:04:45.498954
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
******S*
Seq: 0x2 Ack: 0x3 Win: 0x1000
TcpLen: 20
In
nemesis when the -s or -a options are not set, the sequence number and ack no
is randomly generated. The options part of the rule acts like ‘and’ and in our
case both the sequence and ack nos must be set to 2 and 3. Only packet 3
triggers the alert.
This
option is useful to check when the seq and ack number are zero. These are
packets send by hackers to probe our system.
alert
tcp any any -> any any
(msg:"Rule 1"; window: 12;)
nemesis
tcp -v -P vijay.txt -S 1.1.1.1 -D
1.1.1.2 -I 5 -w 12
[**]
[1:0:0] Rule 1 [**]
[Priority:
0]
05/27-14:28:49.604309
0:0:E8:EE:EC:88 -> FF:FF:FF:FF:FF:FF type:0x800 len:0x46
1.1.1.1:65286
-> 1.1.1.2:65286 TCP TTL:255 TOS:0x0 ID:5 IpLen:20 DgmLen:56
******S*
Seq: 0x22FEE4 Ack: 0x22FEE4 Win: 0xC
TcpLen: 20
In
nemesis, the -w option set the window size and in snort, the window keyword
triggeres an alert for packets of a certain window size. The window size is to
be set by both ends on connection. If the window size is 2000, it means that
the other side will send 2000 bytes without awaiting an ack. Thus it will send
packets totaling 2000 bytes payload and if there is no ack in the forthcoming,
it will resend the packet. The window keyword only has a negation operator.
We
installed nmap on machine 70.0.0.1 and ran it as
nmap
70.0.0.3
This
does a port scan on ip address 70.0.0.3.
Now
we our IDs to inform us whenever a port-scan is attempted on any machine on our
network.
preprocessor
flow:
preprocessor
sfportscan:
There
is a concept of a preprocessor in snort, which receives data before the rules
kick in. The preprocessor is the first entity that receives the packet and it
can store the packet data internally. For example it can wait for a TCP packet
with the syn flag on, it now knows that a connection is to be established. It
can save the entire connection packets and release them when a FIN is send. In
this way, it monitors a session.
For
a port scan it can monitor which host is sending a Syn but not sending a ack.
This host would also be sending multiple syns to port at random. To activate
the preprocessor that monitors scans, we use the sfportscan preprocessor with
no options. This preprocessor relies on the flow preprocessor to work.
[**]
[122:1:0] (portscan) TCP Portscan [**]
05/27-14:49:24.358004
4D:41:43:44:41:44 -> 4D:41:43:44:41:44 type:0x800 len:0xA6
70.0.0.1
-> 70.0.0.3 PROTO255 TTL:0 TOS:0x0 ID:19638 IpLen:20 DgmLen:152
An
alert is given signifying a TCP portscan from IP address 70.0.0.1.