Online Book Reader

Home Category

Linux Firewalls - Michael Rash [113]

By Root 513 0

Successful translation.

Here is the resulting iptables rule in the FWSNORT_FORWARD chain.

$IPTABLES -A FWSNORT_FORWARD -d 192.168.10.0/24 -p udp --dport 27444 -m string

--string "l44adsl" --algo bm -m comment --comment "sid:237; msg: DDOS Trin00 Master

to Daemon

default password attempt; classtype: attempted-dos; reference: arachnids,197; rev: 2;

FWS:1.0;" -j LOG --log-ip-options --log-prefix "[1] SID237 "

Because this is a UDP signature, there is no notion of an established connection, and hence the signature belongs in the FWSNORT_FORWARD chain instead of the FWSNORT_FORWARD_ESTAB chain. In addition, even though the default policy in this book (see "Default iptables Policy" on page 20) does not accept UDP packets destined for port 27444, fwsnort can still detect packets that match the Trin00 signature because a connection does not have to be established before data can be sent (as in the case of TCP signatures). That is, we don't need an ACCEPT rule before data can be sent over the UDP socket from the client. This is a fundamental difference between TCP and UDP sockets.

Now, from the ext_scanner system, we execute the following command to see if the signature triggers:

[ext_scanner]$ echo "l44adsl" | nc -u 71.157.X.X 27444

The iptables log faithfully reports the signature match:

[iptablesfw]# grep SID237 /var/log/messages | tail -n 1

Jul 19 22:18:24 iptablesfw kernel: [1] SID237

IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00:30:48:80:4e:37:08:00 SRC=144.202.X.X DST=

71.157.X.X LEN=36 TOS=0x00 PREC=0x00 TTL=64 ID=42386 DF PROTO=UDP SPT=54494 DPT=

27444

LEN=16

In bold above is the iptables log prefix [1] SID237 from the ext_scanner system—indeed, fwsnort has detected the (simulated) attack.

Detecting Linux Shellcode Traffic

Because exploit developers sometimes share some of the same shellcode, the shellcode.rules file in the Snort signature set looks for this common base of bytes in network traffic. The content field in the following signature shows a smattering of common shellcode used against Linux systems:

alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE Linux

shellcode"; content:"|90 90 90 E8 C0 FF FF FF|/bin/sh"; reference:arachnids,343;

classtype:

shellcode-detect; sid:652; rev:9;)

Translating this signature with fwsnort --snort-sid 652 builds the iptables command below. While the original Snort rule applies to all IP traffic, the destination port requirement forces iptables to match only on TCP or UDP packets.

Here is the translated Snort rule applied to TCP traffic:

$IPTABLES -A FWSNORT_FORWARD -d 192.168.10.0/24 -p tcp --sport ! 80 -m string

--hex-string "|90 90 90 E8 C0 FF FF FF|/bin/sh" --algo bm -m comment --comment "sid:

652; msg:

SHELLCODE Linux shellcode; classtype: shellcode-detect; reference: arachnids,343; rev:

9; FWS:1.0;" -j LOG --log-ip-options

--log-tcp-options --log-prefix "[1] SID652 "

To trigger the signature match within iptables, first execute the fwsnort.sh script on the iptablesfw system, and then execute the Perl command below from the ext_scanner system. As required by the signature, the source port of the TCP session built by Netcat is not port 80, since it chooses a random high port above 1024 according to how the local TCP stack instantiates a client TCP socket:

[iptablesfw]# /etc/fwsnort/fwsnort.sh

[+] Adding shellcode rules.

Rules added: 2

[ext_scanner]$ perl -e 'print "\x90\x90\x90\xE8\xC0\xFF\xFF\xFF/bin/sh"' | nc 71.157.

X.X 80

The simulated attack is caught by iptables, and this log message appears:

[iptablesfw]# grep SID652 /var/log/messages | tail -n 1

Jul 19 23:48:18 iptablesfw kernel: [1] SID652 IN=eth0 OUT=eth1 SRC=144.202.X.X

DST=192.168.10.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=570 DF PROTO=TCP SPT=54629 DPT=80

WINDOW=92 RES=0x00 ACK PSH URGP=0 OPT (0101080A2B3139EFAD325718)

This shows that fwsnort, with guidance from the Snort signature set, is effective at detecting the simulated attack.

Detecting and Reacting to the Dumador Trojan

In recent years, malware authors have elevated the stakes

Return Main Page Previous Page Next Page

®Online Book Reader