HOWTO : Detect and Prevent ICMP Tunnel Attack on Suricata

Recently, I read an article about ICMP Tunnel attack. It demo how to upload a file by encoding the content with Base64 via ICMP protocol.

There is a suricata rule for detecting large ICMP packet but it is disabled by default (dated Oct 26, 2015) currently, which is :

#alert icmp any any -> any any (msg:"GPL ICMP Large ICMP Packet"; dsize:>800; reference:arachnids,246; classtype:bad-unknown; sid:1000029; rev:5;)

We can enable it by removing the "#" in front of the rule and change it to "drop".

However, it cannot detect the packet that is encoded with Base64. I draft the following Suricata rule and make it to "drop" base on the previous rule :

drop icmp any any -> any any (msg:"LOCAL ICMP Large ICMP Packet (Base64)"; dsize:>800; content:"="; pcre:"/^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{4})$/"; reference:url,www.notsosecure.com/2015/10/15/icmp-tunnels-a-case-study/; classtype:bad-unknown; sid:1000028; rev:1;)

That's all! See you.

HOWTO : Self-signed Certificate on Suricata

Problem

The most common weakness of Intrusion Detection and Prevention System is encrypted traffic inspection. The encrypted SSL/TLS traffic requires signed certificate for decryption. Some malicious activities may use self-signed certificate for the SSL/TLS connection.

Solution

How we can do that? If you are running Suricata as IPS, you can do it very easy with the reference of this blog. The rule will detect self-signed certificate without concerning of port number.

Make sure you have configure the Suricata properly according to the blog.

You can also use this rule for other purpose too.

Quick Reference

self-signed-cert.lua

The suricata rule is :

alert tls any any -> any any (msg:"SURICATA TLS Self Signed Certificate"; flow:established; luajit:self-signed-cert.lua; tls.store; classtype:protocol-command-decode; sid:999666111; rev:1;)

HOWTO : LuaJIT on Suricata

That's all! See you.

HOWTO : Detect and Prevent SSH Tunnel On Suricata

Problem

The most common weakness of Intrusion Detection and Prevention System is encrypted traffic inspection. The SSH encrypted traffic requires private/public keys for encryption/decryption and it is very hard to obtain the private key from attackers.

Solution

How we can do that? If you are running Suricata as IPS, SSH Dynamic, Reverse and Port Forwarding tunnel will be detected by the following rules :

# ssh (port 5228=Google Talk, port 6697=IRC)
alert tcp any any -> any 22 (msg:"LOCAL SSH connect"; flow:established,to_server; app-layer-protocol:ssh; sid:1000008; rev:1;)

drop tcp any any -> any 22 (msg:"LOCAL not SSH but Port 22"; flow:established,to_server; app-layer-protocol:!ssh; sid:1000009; rev:1;)

drop tcp any any -> any ![22,5228,6697] (msg:"LOCAL SSH but not Port 22"; flow:established,to_server; app-layer-protocol:ssh; sid:1000010; rev:1;)

The first rule will alert you that there is a SSH connection to the port 22. The second rule will block the traffic the not SSH protocol but connect to port 22. The last rule will block the SSH connection that are not connecting to port 22, 5228 or 6697, where port 5228 is Google Talk and port 6697 is IRC.

If you do not use standard port 22 for SSH, please change the value when necessary.

Reference

SSH Brute Force and Suricata
Protocol Anomalies Detection

That's all! See you.

HOWTO : LuaJIT on Suricata

What is LuaJIT?

LuaJIT is a Just-In-Time Compiler (JIT) for the Lua programming language. Lua is a powerful, dynamic and light-weight programming language. It may be embedded or used as a general-purpose, stand-alone language.

LuaJIT can be used as scripting lauguage for Suricata detection rules. Emerging Threats creates some lua scripts for Suricata at here.

Lua is not enabled by default on Suricata. You need to re-compile it to make it works.

If you compile Suricata from GitHub, you can :

Compile and Install of LuaJIT :

The current version at the writing is 2.0.4.

cd ~
git clone http://luajit.org/git/luajit-2.0.git
cd luajit-2.0
make
sudo make install

Compile and Install of Suricata on Ubuntu 14.04.3 LTS :

cd ~
git clone git://phalanx.openinfosecfoundation.org/oisf.git
cd oisf
git clone https://github.com/ironbee/libhtp.git

./autogen.sh
./configure --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/ --enable-luajit \
--enable-geoip --with-libnss-libraries=/usr/lib --with-libnss-includes=/usr/include/nss/ \
--with-libnspr-libraries=/usr/lib --with-libnspr-includes=/usr/include/nspr \
--with-libcap_ng-libraries=/usr/local/lib --with-libcap_ng-includes=/usr/local/include \
--with-libluajit-includes=/usr/local/include/luajit-2.0/ \
--with-libluajit-libraries=/usr/local/lib/

make clean
make
sudo make install
sudo ldconfig

Works with ET Lua scripts :

# install lua related packages
sudo apt-get -y install cmake lua-zip lua-zip-dev lua-zlib lua-zlib-dev \
luarocks libzzip-dev libzzip-0.13 lua-apr lua-apr-dev lua-socket \
lua-socket-dev lua-sec lua-sec-dev lua-rex-gnu lua-rex-gnu-dev \
lua-rex-pcre lua-rex-pcre-dev lua-bitop lua-bitop-dev liblua5.1 \
libzip-dev

sudo apt-get -y install cmake build-essential

sudo luarocks install struct
sudo luarocks install bitlib

sudo cp /usr/lib/x86_64-linux-gnu/liblua5.1.so /usr/local/lib/liblua.so

# compile and install ltn12ce
cd ~
git clone https://github.com/mkottman/ltn12ce.git
cd ltn12ce
mkdir build && cd build
cmake ..
make
sudo make install
sudo mkdir -p /usr/local/lib/lua/5.1/ltn12ce
sudo cp ~/ltn12ce/build/src/ltn12ce/core.so /usr/local/lib/lua/5.1/ltn12ce

# compile and install zlib
cd ~
wget http://zlib.net/zlib-1.2.8.tar.gz
tar -xzvf zlib-1.2.8.tar.gz
cd zlib-1.2.8
./configure
make
sudo make install

# compile and install lua-zlib
cd ~
git clone https://github.com/brimworks/lua-zlib.git
cd lua-zlib
make linux
sudo mkdir -p /usr/lib/lua/5.1
sudo mkdir -p /usr/local/lib/lua/5.1
sudo cp zlib.so /usr/local/lib/lua/5.1
sudo make install

sudo cp /usr/lib/x86_64-linux-gnu/lua/5.1/zip.so /usr/local/lib/lua/5.1
sudo mkdir -p /usr/local/lib/lua/5.1/apr
sudo cp /usr/lib/x86_64-linux-gnu/lua/5.1/apr/core.so /usr/local/lib/lua/5.1/apr


Make sure the ET lua scripts and related rules are placed at "/etc/suricata/rules" and the "luajit-drop.rules" or "luajit.rules" is loaded in suricata.yaml.

Bug Fix on ET Lua scripts :

Please note that CVE-2015-1770.lua and CVE-2015-2375.lua have a small bug when using with luajit. You can fix them like this :

sudo sed -i -e 's/activeX%d+\\.xml/activeX%d+.xml/g' /etc/suricata/rules/CVE-2015-1770.lua
sudo sed -i -e 's/table%d+\\.xml/table%d+.xml/g' /etc/suricata/rules/CVE-2015-2375.lua

Finally, if you are using Snorby, you need to copy the all rules files (except lua scripts) to another place, such as "/etc/suricata/rules/snorby" for Snorby; otherwise, Snorby cannot display the rules when requested. Meanwhile, you need to edit "/var/www/snorby/config/snorby_config.yml" for the new rules path.

One more thing, the value of "prealloc" at "flow" section at suricata.yaml should not more than "4000000"; otherwise, the lua scripts cannot be loaded.

After that, restart Suricata.

That's all! See you.

HOWTO : ClamAV For Suricata

Suricata is an Intrusion Detection and Prevention System and it can work with ClamAV too. One of the features of Suricata is using MD5 hash with the file. We can use ClamAV signature MD5 hash for every file download inspection. We can also save the malicious file for further analysis.

Install and Configure of ClamAV

sudo apt-get update
sudo apt-get install clamav
sudo update-rc.d clamav-freshclam disable

We will not use ClamAV engine for Suricata but use ClamAV MD5 signature instead.

Prepare ClamAV MD5 Signature for Suricata

sudo nano /usr/bin/nsm_clamav_md5



sudo chmod +x /usr/bin/nsm_clamav_md5

Create cron job :

sudo crontab -e

0 03 * * * /usr/bin/nsm_clamav_md5

* The cron job will run the script (nsm_clamav_md5) at 0300 hours every day and it should be earlier than the Suricata rules update script/procedure.

Create your Suricata Local Rule

sudo nano /etc/suricata/rules/local.rules

Append the following to the file :

# rules for file extraction
# this rule drop all the file that matches the clamav md5 hash
drop http any any -> any any (msg:"LOCAL Malicious file - Clamav MD5 Hash"; flow:established; filestore; filemd5:blacklist_md5; classtype: suspicious-filename-detect; sid:1000000; rev:1;)

Configure suricata.yaml

sudo nano /etc/suricata/suricata.yaml

Make the following settings as the following :



* If you do not like to save the malicious file for further analysis, you can disable the "file-store" setting at suricata.yaml and remove the "filestore" keyword from the local.rules.

Make It To Work Together

sudo nsm_clamav_md5

Restart suricata or reboot the box. For Croissants, you can restart the Suricata by issuing the following command :

sudo restart suricata

The Suricata will block the malicious files from downloading when the MD5 hash is matched and the malicious files will be saved at /var/log/suricata/files for further inspection.

Known Issue

libhtp 0.5.x cannot handle the file download re-try with browser at the moment. It is recommended that all users should not re-try to download any file when it cannot be downloaded in the beginning. According to the developer of libhtp, 0.6.x can handle this problem.

Another limitation is that Suricata can detected the malicious files (MD5 hash) that known to ClamAV only.

Reference

Filemd5 and white or black listing with MD5 hashes

That's all! See you.

Cloudflare Or Not Cloudflare?

Cloudflare is very famous in against DDoS attacks. Their by-product is the IP address of the protected sites are hidden if the owner of the protected sites are setting it correctly. However, it is not very easy to set it correctly when the owners do not fully understand well the services that Cloudflare is provided.

Many website owners choose to use Cloudflare services including criminals. There are a lot of methods to resolve the IP address of the websites that behind Cloudflare protection, such as CrimeFlare. Almost all these methods are targeted to the mis-configuration of Cloudflare. Some of the methods do not work as Cloudflare has been fixed the problem long time ago.

Recently, there is a new method to resolve the IP address of the websites that behind Cloudflare, that is Cloudflare IP resolver. However, if the webmaster or sysadmin is clever enough, this method is also failed.

No matter how, this new method is also a killer to Cloudflare for sure.

Finally, when you think that your system is very very secure, your system will be very danger.

That's all! See you.