Showing posts with label Wheezy. Show all posts
Showing posts with label Wheezy. Show all posts

Thursday, February 19, 2015

Chasing MTUs


Setting up (configuring) the right MTU (maximum transmission unit) size when running Suricata IDS/IPS.

Sometimes you can end up in a situation as follows :


capture.kernel_packets    | AFPacketeth12              | 1143428204
decoder.pkts                    | AFPacketeth12             | 1143428143
decoder.invalid                | AFPacketeth12              | 416889536

a whole lot of  decoder.invalid. Not good. What could be the reason for that? One thing you should check right away is the MTU of the traffic that is being mirrored.

What does it mean? Well there is the MTU that you set up on the server that you run Suricata on and there is the MTU that is present in the "mirrored" traffic.

What is the difference?Why should it matter?
It matters because if not set correct  it will result in a lot of decoder.invalids (dropped by Suricata) and you will be missing on a lot of traffic inspection.
Example: if  on the sniffing interface that you run Suricata on has a MTU set as 1500  and in the traffic that you mirror you have jumbo frames (MTU 9000) - most likely your decoder.invalids will show a whole lotta love in your stats.log.

How can you adjust the MTU on the interface (NIC) ? (example)
First a have  look what is the current value:
ifconfig eth0
then adjust it
ifconfig eth0 mtu 1514

By the way - what could be the max size of the MTU (and what sizes there are in general)  -
(short answer - 9216)


This is the easy part :). There are situations where you do not know what is the MTU of the "mirrored" traffic. There is a few ways to find this  - ask the network team/guy, make a phone call or two, start manually testing and setting it on the NIC to find a middle ground ....however you can also make use of the procedure shown below (in order to get the byte size of the MTU):


On your Server/Sensor
1)
Stop Suricata.

2)
Change the MTU to 9216
(the interface that Suri is sniffing on)

example - ifconfig eth0 mtu 9216
(non boot persistent)

3)
install tcpstat - if you do not have it
apt-get install tcpstat

5)
run the following (substitute the interface name with yours - that Suri is sniffing on)
tcpstat -i eth0 -l -o "Time:%S\tn=%n\tavg=%a\tstddev=%d\tbps=%b\tMaxPacketSize=%M\n"  5
6)
Give it a minute or two
If there are Jumbo frames you should see that in the output (something like) -
"MaxPacketSize=9000", if not you should see whatever the max size is.

7)
Adjust your interface MTU accordingly  - the one that Suri is sniffing
on. -> Start Suri

8)
Let it run for  a while - lets say 1 hr. Have a look at the decoder.invalid stats in stats.log

NOTE: Do NOT just set the MTU to 9216 directly ("just to be on the safe side"). Only set it that high if needed !!

NOTE: This example below is not using the "-l" option of tcpstat as denoted in point 5) above - look at man tcpstat for more info



(tested on Ubuntu/Debian)
That's all ....feedback welcome.









Sunday, December 7, 2014

Suricata - disable detection mode


There is a trick for using Suricata IDS/IPS that has come in handy - in my experience that I thought  would share and might be useful to others.

My HW was CPU 1x E5-2680 with 64 GB RAM ,  NIC a  82599EB 10-Gigabit SFI/SFP+ and mirroring about 9,5Gbps:





So I wanted to get a better understanding of what is the max log output from Suricata in that particular environment without putting detection into consideration. Just pure event logging and profiling - DNS,HTTP,TLS,SSH, File transactions, SMTP all of these.

Suricata offers just that - with a really low need for HW (having in mind we are looking at 9,5Gbps). What i did was compile suricata with the "--disable-detection" switch. What it does it simply disables detection(alerts) in Suricata  - however every other logging/parsing capability is preserved ( DNS,HTTP,TLS,SSH, File transactions, SMTP). So i downloaded a fresh copy:

git clone git://phalanx.openinfosecfoundation.org/oisf.git && cd oisf/ &&  git clone https://github.com/ironbee/libhtp.git -b 0.5.x

then

./autogen.sh && ./configure --disable-detection   &&  make clean && make && make install &&  ldconfig

enabled all JSON outputs in the eve-log section in suricata.yaml. I confirmed that detection was disabled:


and started Suricata.

Careful what you asked for :) - I was getting 10-15K logs per second :

 root@suricata:/var/log/suricata# tail -f  eve.json |perl -e 'while (<>) {$l++;if (time > $e) {$e=time;print "$l\n";$l=0}}'
1
6531
13860
10704
10877
10389
10664
10205
9996
14798
15427
14223

And the HW(CPU/RAM/HDD) usage was not much at all:


As you can see - 30-40% CPU with a third of RAM  usage.

 I used this command to count logs per second  -
tail -f  eve.json |perl -e 'while (<>) {$l++;if (time > $e) {$e=time;print "$l\n";$l=0}}'
more about similar commands and counting Suricata logs you could find here:


So this can came in handy in a few scenarious:
  • you can  actually do a  "profiling" run on that particular set up in order to size up a SIEM specification 
  • and/or you can size up your prod IDS/IPS deployment needs
  • you can also just feed all those logs info to an existing log analysis system

Thanks

Sunday, April 6, 2014

Upgrading Debian Wheezy's kernel



Upgrade form Debian Wheezy 64 bit (with GDM3/xfce) 3.2.0 to 3.14.0 kernel level/version.
(
you might also want to take a look at this tutorial as well if you are interested in creating kernel.xx.xxx.deb ready for installation packages-
http://pevma.blogspot.se/2014/07/kernel-upgrade-for-debian.html
)
First we need some tools:
apt-get install gcc libncurses5-dev bc ca-certificates pkg-config make flex bison build-essential autoconf automake
Make sure everything is updated/upgraded:
 apt-get update && apt-get upgrade
 apt-get dist-upgrade
 Just to get read of some cached space:
 apt-get clean

 Download and build the kernel:
 wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.14.tar.xz
 tar xvfJ linux-3.14.tar.xz -C /usr/src
 cd /usr/src/linux-3.14/
 yes "" | make oldconfig


 This could take 20 min:
 make
Make and install the modules and the kernel
 make modules_install install
Verify:
root@debian64:~# ls -lh /boot
total 149M
-rw-r--r-- 1 root root 129K Apr  5 19:28 config-3.14.0
-rw-r--r-- 1 root root 127K Feb  1 20:16 config-3.2.0-4-amd64
drwxr-xr-x 3 root root  12K Apr  5 19:30 grub
-rw-r--r-- 1 root root 129M Apr  5 19:30 initrd.img-3.14.0
-rw-r--r-- 1 root root  10M Mar 11 09:26 initrd.img-3.2.0-4-amd64
-rw-r--r-- 1 root root 2.3M Apr  5 19:28 System.map-3.14.0
-rw-r--r-- 1 root root 2.1M Feb  1 20:16 System.map-3.2.0-4-amd64
-rw-r--r-- 1 root root 3.1M Apr  5 19:28 vmlinuz-3.14.0
-rw-r--r-- 1 root root 2.8M Feb  1 19:51 vmlinuz-3.2.0-4-amd64
root@debian64:~#

 your /boot/grub/grub.cfg should have a similar section (notice the new 3.14.0) :



 Make sure you have at least one non root user
 reboot


 If you want to log into the Desktop Manager as root:
 log in with the non root user.

 su root
 vim  /etc/pam.d/gdm3

 comment out (like shown)
 #auth   required    pam_succeed_if.so user != root quiet_success
 save the file

 change the root password
 passwd root
 reboot

 You can log in as root if you want to.
 Make sure you are with running the latest packages:
 apt-get update && apt-get upgrade
root@debian64:~# uname -a
Linux debian64 3.14.0 #1 SMP Sat Apr 5 19:19:46 EDT 2014 x86_64 GNU/Linux
root@debian64:~#

 Done.