Plaisirs et désillusions du monde moderne
I’ve just finished my talk on Linux kernel packet capture technologies at Kernel Recipes 2015. I would like to thanks the organizer for their great work. I also thank Frank Tizzoni for the drawing
In that talk, I’ve tried to do an overview of the history of packet capture technologies in the Linux kernel. All that seen from userspace and from a Suricata developer perspective.
You can download the slides here: 2015_kernel_recipes_capture.
I’ve been invited by SaLUG to Lecce to give some talks during their Geek Evening. I’ve done a talk on nftables and one of suricata.
The nftables talk was about the motivation behind the change from iptables.
Here are the slides: Nftables
The talk on Suricata was explaining the different feature of Suricata and was showing how I’ve used it to make a study of SSH bruteforce.
Here are the slides:
Suricata, Netfilter and the PRC.
Thanks a lot to Giuseppe Longo, Luca Greco and all the SaLUG team, you have been wonderful hosts!
I’ve been playing lately on analysis SSH bruteforce caracterization. I was a bit frustrated of just getting partial information:
But having username without having the password is really frustrating.
So I decided to try to get them. Looking for a SSH server honeypot, I did find kippo but it was going too far for me
by providing a fake shell access. So I’ve decided to build my own based on paramiko.
pshitt, Passwords of SSH Intruders Transferred to Text, was born. It is a lightweight fake SSH server that collect authentication data sent by intruders. It basically collects username and password and writes the extracted data to a file in JSON format. For each authentication attempt, pshitt is dumping a JSON formatted entry:
{"username": "admin", "src_ip": "116.10.191.236", "password": "passw0rd", "src_port": 36221, "timestamp": "2014-06-26T10:48:05.799316"}
The data can then be easily imported in Logstash (see pshitt README) or Splunk.
As I want to really connect to the box running ssh with a regular client, I needed a setup to automatically redirect the offenders and only them to pshitt server. A simple solution was to used DOM. DOM parses Suricata EVE JSON log file in which Suricata gives us the software version of IP connecting to the SSH server. If DOM sees a
software version containing libssh, it adds the originating IP to an ipset set.
So, the idea of our honeypot setup is simple:
Getting the setup in place is really easy. We first create the set:
ipset create libssh hash:ip
then we start DOM so it adds all offenders to the set named libssh:
cd DOM ./dom -f /usr/local/var/log/suricata/eve.json -s libssh
A more accurate setup for dom can be the following. If you know that your legitimate client are only based on OpenSSH then you can
run dom to put in the list all IP that do not (-i) use an OpenSSH client (-m OpenSSh):
./dom -f /usr/local/var/log/suricata/eve.json -s libssh -vvv -i -m OpenSSH
If we want to list the elements of the set, we can use:
ipset list libssh
Now, we can start pshitt:
cd pshitt ./pshitt
And finally we redirect the connection coming from IP of the libssh set to the port 2200:
iptables -A PREROUTING -m set --match-set libssh src -t nat -i eth0 -p tcp -m tcp --dport 22 -j REDIRECT --to-ports 2200
Here’s an extract of the most used passwords when trying to get access to the root account:
And here’s the same thing for the admin account attempt:
Both data show around 24 hours of attempts on an anonymous box.
Thanks to paramiko, it was really fast to code pshitt. I’m now collecting data and I think that they will help to improve the categorization of SSH bruteforce tools.
The slides of my lightning talk at SSTIC are available: Let’s talk about SELKS. The slides are in French and are intended to be humorous.
The presentation is about defensive security that needs to get sexier. And Suricata 2.0 with EVE logging combined with Elasticsearch and Kibana can really help to reach that target. If you want to try Suricata and Elasticsearch, you can download and test SELKS.
The talk also present a small tool named Deny On Monitoring which demonstrate how easy it is to extract information from Suricata EVE JSON logging.
Suricata 2.0-rc2 is out and it brings some progress on the JSON side. The logging of SSH protocol has been added:
and the format of timestamp has been updated to be ISO 8601 compliant and it is now named timestamp instead of time.
Ulogd, the Netfilter logging daemon has seen similar change as it is now also using a ISO 8601 compliant timestamp for the . This feature is available in git and will be part of ulogd 2.0.4.
Thanks to this format change, the integration with logstash or splunk is easier and more accurate.
This permit to fix one problem regarding the timestamp of an event inside of the event and logging manager. At least in logstash, the used date was the one of the parsing which was not really
accurate. It could even be a problem when logstash was parsing a file with old entries because the difference in timestamp could be huge.
It is now possible to update logstash configuration to have a correct parsing of the timestamp. After doing this the internal @timestamp and the timestamp of the event are synchronized as show on the following screenshot:
To configure logstash, you simply needs to tell him that the timestamp field in JSON message is a date. To do so, you need to add a filter:
date {
match => [ "timestamp", "ISO8601" ]
}
A complete logstash.conf would then looks like:
input {
file {
path => [ "/usr/local/var/log/suricata/eve.json", "/var/log/ulogd.json" ]
codec => json
type => "json-log"
}
}
filter {
if [type] == "json-log" {
date {
match => [ "timestamp", "ISO8601" ]
}
}
}
output {
stdout { codec => rubydebug }
elasticsearch { embedded => true }
}
In splunk, auto detection of the file format is failing and it seems you need to define a type to parse JSON in
$SPLUNK_DIR/etc/system/local/props.conf:
[suricata] KV_MODE = json NO_BINARY_CHECK = 1 TRUNCATE = 0
Then you can simply declare the log file in $SPLUNK_DIR/etc/system/local/inputs.conf:
[monitor:///usr/local/var/log/suricata/eve.json] sourcetype = suricata [monitor:///var/log/ulogd.json] sourcetype = suricata
you can now build search events and build dashboard based on Suricata or Netfilter packet logging:
Building a Suricata ruleset with iptables has always been a complicated task when trying to combined the rules that are necessary for the IPS with the firewall rules. Suricata has always used Netfilter advanced features allowing some more or less tricky methods to be used.
For the one not familiar with IPS using Netfilter, here’s a few starting points:
So the ruleset needs to send all packets to the IPS. A basic ruleset for an IPS could thus looks like:
iptables -A FORWARD -j NFQUEUE
With such a ruleset, all packets going through the box are sent to the IPS.
If now you want to combine this with your ruleset, then usually your first try is to add rules to the filter chain:
iptables -A FORWARD -j NFQUEUE iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT # your firewall rules here
But this will not work because of point 2: All packets sent via NFQUEUE to the IPS are or blocked or if accepted, leave the FORWARD chain directly and are going for evaluation to the next chain (mangle POSTROUTING in our case).
With such a ruleset, the result is that there is no firewall but an IPS in place.
As mentioned before there is some existing solutions (see Building a Suricata ruleset for extensive information). The simplest one is to dedicated one another chain such as mangle to IPS:
iptables -A FORWARD -t mangle -j NFQUEUE iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT # your firewall rules here
No conflict here but you have to be sure nothing in your system will use the the mangle table or you will have the same problem as the one seen previously in the filter chain. So there was no universal and simple solution to implement an IPS and a firewall ruleset with iptables.
In Nftables, chains are defined by the user using nft command line. The user can specify:
In our case, we want to act on forwarded packets. And we want to have a chain for filtering followed by a chain for IPS. So the setup is simple of chain is simple
nft -i
nft> add table filter
nft> add chain filter firewall { type filter hook forward priority 0;}
nft> add chain filter IPS { type filter hook forward priority 10;}
With this setup, a packet will reach the firewall chain first where it will be filtered. If the packet is blocked, it will be destroy inside of the kernel. It the packet is accepted it will then jump to the next chain following order of increasing priority. In our case, the packet reaches the IPS chain.
Now, that we’ve got our chains we can add filtering rules, for example:
nft add rule filter firewall ct state established accept nft add rule filter firewall tcp dport ssh counter accept nft add rule filter firewall tcp dport 443 accept nft add rule filter firewall counter log drop
And for our Suricata IPS, that’s just trivial:
nft add rule filter IPS queue
The complete support for the queue target will be available in Linux 3.14. The syntax looks as follow:
nft add rule filter output queue num 3 total 2 options fanout
This rule sends matching packets to 2 load-balanced queues (total 2) starting at 3 (num 3).
fanout is one of the two queue options:
For a complete description of queueing mechanism in Netfilter see Using NFQUEUE and libnetfilter_queue.
If you want to test this before Linux 3.14 release, you can get nft sources from nftables git and use next-3.14 branch.
For reference, here are the priority values of some important internal operations and of iptables static chains:
For example, one can create in nftables an equivalent of the raw PREROUTING chain of iptables by doing:
# nft -i
nft> add chain filter pre_raw { type filter hook prerouting priority -300;}
I’ve been playing lately with logstash using data from the ulogd JSON output plugin and the Suricata full JSON output as well as standard system logs.
Ulogd is getting Netfilter firewall logs from Linux kernel and is writing them in JSON format. Suricata is doing the same with alert and other traces. Logstash is getting both log as well as sytem log. This allows to create some dashboard with information coming from multiple sources. If you want to know how to configure ulogd for JSON output check this post. For suricata, you can have a look at this one.
Ulogd output is really new and I was experimenting with it in Kibana. When adding some custom graphs, I’ve observed some strange things and decided to investigate.
TCP window size at the start of the connection is not defined in the RFC. So every OSes have choozen their own default value. It was thus looking interesting to display TCP window to be able to find some strange behavior. With the new ulogd JSON plugin, the window size information is available in the tcp.window key. So, after doing a query on tcp.syn:1 to only get TCP syn packet, I was able to graph the TCP window size of SYN packets.
Most of the TCP window sizes are well-known and correspond to standard operating systems:
The first uncommon value is 16384. Graph are clickable on Kibana, so I was at one click of some interesting information.
First information when looking at dashboard after selection TCP syn packet with a window size of 16384 was the fact, it was only ssh scanning:
Second information is the fact that, according to geoip, all IPs are chinese:
When looking at the details of the attempt made on my IP, there was something interesting:
For all hosts, all requests are done with the same source port (6000). This is not possible to do that with a standard ssh client where the source port is by default choosen by the operating system. So or we have a custom standard software that perform a bind operation to port 6000 at socket creation. This is possible and one advantage would be to be easily authorized through a firewall if the country had one. Or we could have a software developped with low level (RAW) sockets for performance reason. This would allow a faster scanning of the internet by skipping OS TCP connection handling. There is a lot of posts regarding the usage of port 6000 as source for some scanning but I did not find any really interesting information in them.
On suricata side, most of the source IPs are referenced in ET compromised rules:
Analysing my SSH logs, I did not see any trace of ssh bruteforce coming from source port 6000. But when selecting an IP, I’ve got trace of brute force from at least one of the IP:
These attackers seems to really love the root account. In fact, I did not manage to find any trace of attempts for user different than root for IP address that are using the port 6000.
Getting back to my ulogd dashboard, I’ve displayed more info about the used scanning sequence:
The host scans the box using a scanner using raw socket, then it attacks with a few minutes later with SSH bruteforce tool. The bruteforce tool has a TCP window size at start of 65535. It indicates that a separated software is used for scanning. So we should have an queueing mechanism between the scanner and the bruteforce tool. This may explains the duration between the scan and the bruteforce. Regarding TCP window size value, 65535 seems to indicate a Windows server (which is coherent with TTL value).
Capturing a sample traffic did not give to much information. This is a scanner sending a SYN and cleanly sending a reset when it got the SYN, ACK:
14:27:54.982273 IP (tos 0x0, ttl 103, id 256, offset 0, flags [none], proto TCP (6), length 40)
218.2.22.118.6000 > 192.168.1.19.22: Flags [S], cksum 0xa525 (correct), seq 9764864, win 16384, length 0
14:27:54.982314 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
192.168.1.19.22 > 218.2.22.118.6000: Flags [S.], cksum 0xeee2 (correct), seq 2707606274, ack 9764865, win 29200, options [mss 1460], length 0
14:27:55.340992 IP (tos 0x0, ttl 111, id 14032, offset 0, flags [none], proto TCP (6), length 40)
218.2.22.118.6000 > 192.168.1.19.22: Flags [R], cksum 0xe48c (correct), seq 9764865, win 0, length 0
But it seems the RST packet after the SYN, ACK is not well crafted:
Knowing the the behavior was scanning from 6000 and starting a normal scanning, I’ve focused the Suricata dashboard on one IP to see if I had some more information:
One single IP in the list of the scanning host is triggering multiple alerts. The event table confirmed this:
Studying the geographical repartition of the Libssh alert, it appears there is used in other countries than China:
So, libssh is not a discriminatory element of the attacks.
A custom attack tool has been been deployed on some Chinese IPs. This is a combination of a SSH scanner based on RAW socket and a SSH bruteforce tool. It tries to gain access to the root account of system via the ssh service. On an organisational level, it is possible there is a Chinese initiative trying to get the low-hanging fruit (system with ssh root account protected by password) or maybe it is just a some organization using some compromised Chinese IPs to try to get control other more boxes.
Perf is a great tool to analyse performances on Linux boxes. For example, perf top will give you this type of output on a box running Suricata on a high speed network:
Events: 32K cycles 28.41% suricata [.] SCACSearch 19.86% libc-2.15.so [.] tolower 17.83% suricata [.] SigMatchSignaturesBuildMatchArray 6.11% suricata [.] SigMatchSignaturesBuildMatchArrayAddSignature 2.06% suricata [.] tolower@plt 1.70% libpthread-2.15.so [.] pthread_mutex_trylock 1.17% suricata [.] StreamTcpGetFlowState 1.10% libc-2.15.so [.] __memcpy_ssse3_back 0.90% libpthread-2.15.so [.] pthread_mutex_lock
The functions are sorted by CPU consumption. Using arrow key it is possible to jump into the annotated code to see where most CPU cycles are used.
This is really useful but in the case of a function like pthread_mutex_trylock, the interesting part is to be able to find where this function is called.
This stack overflow question lead me to the solution.
I’ve started to build suricata with the -fno-omit-frame-pointer option:
./configure --enable-pfring --enable-luajit CFLAGS="-fno-omit-frame-pointer" make make install
Once suricata was restarted (with pid being 9366), I was then able to record the data:
sudo perf record -a --call-graph -p 9366
Extracting the call graph was then possible by running:
sudo perf report --call-graph --stdio
The result is a huge detailed report. For example, here’s the part on pthread_mutex_lock:
0.94% Suricata-Main libpthread-2.15.so [.] pthread_mutex_lock
|
--- pthread_mutex_lock
|
|--48.69%-- FlowHandlePacket
| |
| |--53.04%-- DecodeUDP
| | |
| | |--95.84%-- DecodeIPV4
| | | |
| | | |--99.97%-- DecodeVLAN
| | | | DecodeEthernet
| | | | DecodePfring
| | | | TmThreadsSlotVarRun
| | | | TmThreadsSlotProcessPkt
| | | | ReceivePfringLoop
| | | | TmThreadsSlotPktAcqLoop
| | | | start_thread
| | | --0.03%-- [...]
| | |
| | --4.16%-- DecodeIPV6
| | |
| | |--97.59%-- DecodeTunnel
| | | |
| | | |--99.18%-- DecodeTeredo
| | | | DecodeUDP
| | | | DecodeIPV4
| | | | DecodeVLAN
| | | | DecodeEthernet
| | | | DecodePfring
| | | | TmThreadsSlotVarRun
| | | | TmThreadsSlotProcessPkt
| | | | ReceivePfringLoop
| | | | TmThreadsSlotPktAcqLoop
| | | | start_thread
| | | |
| | | --0.82%-- DecodeIPV4
| | | DecodeVLAN
| | | DecodeEthernet
| | | DecodePfring
| | | TmThreadsSlotVarRun
| | | TmThreadsSlotProcessPkt
| | | ReceivePfringLoop
| | | TmThreadsSlotPktAcqLoop
| | | start_thread
| | |
| | --2.41%-- DecodeIPV6
| | DecodeTunnel
| | DecodeTeredo
| | DecodeUDP
| | DecodeIPV4
| | DecodeVLAN
| | DecodeEthernet
| | DecodePfring
| | TmThreadsSlotVarRun
| | TmThreadsSlotProcessPkt
| | ReceivePfringLoop
| | TmThreadsSlotPktAcqLoop
| | start_thread
logstash an opensource tool for managing events and logs. It is using elasticsearch for the storage and has a really nice interface named Kibana. One of the easiest to use entry format is JSON.
Suricata is an IDS/IPS which has some interesting logging features. Version 2.0 will feature a JSON export for all logging subsystem. It will then be possible to output in JSON format:
For now, only File log is available in JSON format. This extract meta data from files transferred over HTTP.
Peter Manev has described how to connect Logstash Kibana and Suricata JSON output. Installation is really simple, just download logstash from logstash website, write your configuration file and start the thing.
Kibana interface is really impressive:
But at the time, I started to look at the document, a few things were missing:
This one was easy. You simply have to edit the logstash.conf file to add a section about geoip:
input {
file {
path => "/home/eric/builds/suricata/var/log/suricata/files-json.log"
codec => json
# This format tells logstash to expect 'logstash' json events from the file.
#format => json_event
}
}
output {
stdout { codec => rubydebug }
elasticsearch { embedded => true }
}
#geoip part
filter {
if [srcip] {
geoip {
source => "srcip"
target => "geoip"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
mutate {
convert => [ "[geoip][coordinates]", "float" ]
}
}
}
It adds a filter that check for presence of srcip and add geoip information to the entry. The tricky thing is the add_field part that create an array that has to be used when adding a map to kibana dashboard. See following screenshot for explanation:
You may have the following error:
You must specify 'database => ...' in your geoip filter"
In this case, you need to specify the path to the geoip database by adding the database keyword to geoip configuration:
#geoip part
filter {
if [srcip] {
geoip {
source => "srcip"
target => "geoip"
database => "/path/to/GeoLiteCity.dat"
add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}" ]
}
mutate {
convert => [ "[geoip][coordinates]", "float" ]
}
}
}
Once the file is written, you can start logstash
java -jar /home/eric/builds/logstash/logstash-1.2.2-flatjar.jar agent -f /home/eric/builds/logstash/logstash.conf --log /home/eric/builds/logstash/log/logstash-indexer.out -- web
See Logstash Kibana and Suricata JSON output for detailed information on setup.
Before logstash 1.3.1, fixing the space issue was really complex. Since that version, all indexed fields are provided with a .raw field that can be used to avoid the problem with spaces in name. So now, you can simply use in Kibana something like geoip.country_name.raw in the definition of graph instead of geoip.country_name. Doing that United States does not appear anymore as United and States.
Fixing the space issue for lostash previous to 1.3.1 was far more complicated for an old guy like me used to configuration files. If finding the origin of the behavior is easy fixing it was more painful. A simple googling shows me that by default elasticsearch storage split string at spaces when indexing. To fix this, you have to specify that the field should not be analyzed during indexing: "index":"not_analyzed"
That was looking easy at first but logstash is not using a configuration file for indexing and mapping. In fact, you need to interact with elasticsearch via HTTP requests. Second problem is that the index are dynamically generated, so there is a template system that you can use to have indexes created the way you want.
Creating an template is easy. You simply do something like:
curl -XPUT http://localhost:9200/_template/logstash_per_index -d '
{
"template" : "logstash*",
MAGIC HERE
}'
This will create a template that will be applied to all newly created indexes with name matching “logstash*”. The difficult part is to know what to to put in MAGIC HERE and to check if “logstash*” will match created index. To check this, you can retrieve all current mappings:
curl -XGET 'http://localhost:9200/_all/_mapping'
You then get a list of mappings and you can check the name. But best part is that you can get a base text to update the mapping definition part. With Suricata file log and geoip activated, the following configuration is working well:
curl -XPUT http://localhost:9200/_template/logstash_per_index -d '
{
"template" : "logstash*",
"mappings" : {
"logs" : {
"properties": {
"@timestamp":{"type":"date",
"format":"dateOptionalTime"},
"@version":{"type":"string"},
"dp":{"type":"long"},
"dstip":{"type":"ip"},
"filename":{"type":"string"},
"geoip":{
"properties":{
"area_code":{"type":"long"},
"city_name":{"type":"string", "index":"not_analyzed"},
"continent_code":{"type":"string"},
"coordinates":{"type":"string"},
"country_code2":{"type":"string"},
"country_code3":{"type":"string"},
"country_name":{"type":"string", "index":"not_analyzed"},
"dma_code":{"type":"long"},
"ip":{"type":"string"},
"latitude":{"type":"double"},
"longitude":{"type":"double"},
"postal_code":{"type":"string"},
"real_region_name":{"type":"string", "index":"not_analyzed"},
"region_name":{"type":"string", "index":"not_analyzed"},
"timezone":{"type":"string"}
}
},
"host":{"type":"string"},
"http_host":{"type":"string"},
"http_referer":{"type":"string"},
"http_uri":{"type":"string"},
"http_user_agent":{"type":"string", "index":"not_analyzed", "omit_norms":true, "index_options":"docs"},
"ipver":{"type":"long"},
"magic":{"type":"string", "index":"not_analyzed", "omit_norms":true, "index_options":"docs"},
"md5":{"type":"string"},
"path":{"type":"string"},
"protocol":{"type":"long"},
"size":{"type":"long"},
"sp":{"type":"long"},
"srcip":{"type":"ip"},
"state":{"type":"string"},
"stored":{"type":"boolean"},
"tags":{"type":"string"},
"timestamp":{"type":"string"}
}
}
}
}'
I’ve added some “index”:”not_analyzed” and improved the type for some of the fields. For example, srcip has been defined as an IP address. This allow to do range searching in Kibana like
["192.168.42.24" TO "192.168.42.45"]
Next point is to update the index format. To to so, you can get the name of current index, delete it and recreate it. To get the name you can use le mapping listing:
curl -XGET 'http://localhost:9200/_all/_mapping'
The return is something like:
{"logstash-2013.10.27":{"logs":{"properties":
So now, we can destroy this index named “logstash-2013.10.27” and have it recreated with the correct
settings:
curl -XDELETE 'http://localhost:9200/logstash-2013.10.27' curl -XPUT 'http://localhost:9200/logstash-2013.10.27'
We need data to be reindexed so:
curl -XGET 'http://localhost:9200/logstash-2013.10.27/_refresh'
It may also be a good idea to wait for new data as it seems to trigger update in what elasticsearch is sending.
The 5th of December 2012, I’ve setup suricata in AF_PACKET IPS mode between a WiFi interface and an Ethernet interface. The result was surprising as it was leading to a crash after some time:
The issue was linked with the defrag option of AF_PACKEt fanout. I’ve proposed a patch the 7th Dec 2012 and after a discussion with David Miller and Johannes Berg, Johannes has proposed a better patch which was included in official tree. So the problem is fixed for kernel superior or equal to 3.7.
Here’s the list of affected kernel:
If you can’t update to a not affected kernel, you can set defrag to no in af-packet configuration to avoid the issue:
af-packet:
- interface: wlan0
# In some fragmentation case, the hash can not be computed. If "defrag" is set
# to yes, the kernel will do the needed defragmentation before sending the packets.
defrag: no