Tag Archives: Visualization

Mapping OSSEC Alerts with AfterGlow

AfterGlowThis week is the third annual OSSEC week! A good initiative to promote this open source log management solution. This post is my first contribution to the OSSEC community, I hope to publish more posts if I’ve enough time. OSSEC is a excellent tool to collect and analyze the events generated by your (multiple) hosts and applications. But, being based on a command line interface, OSSEC lacks of “visibility” (IMHO). As you know, “one picture is worth a thousands words“. That’s why displaying a “map” of your alerts could be very helpful to quickly detect suspicious activity or to analyze security incidents. My goal was to add a feature like the one presents in the ArcSight ESM tool (called “Event Graph“).

OSSEC proposes for a while an interface with Picviz. Picviz is a nice tool but the integration is very basic and does not allow to filter some events.  The generated graphs can become quickly unreadable if you have a lot of alerts. I’m a big fan of another visualization tool called AfterGlow. Basically, this tool helps to understand the relations that you have between “objects“. In the context of OSSEC, the useful objects are:

  • The attackers (source IP address or user)
  • The alert description
  • The destination (the OSSEC location based on the agent name / log source)

Some examples:

  [12.34.56.78] -> [Attempt to access forbidden file or directory.] -> [web1->/var/log/apahe2/access.log]
  [10.0.0.1] -> [SSHD authentication success.] -> [unix1->/var/log/auth.log]
  [9.8.7.6] -> [Access attempt blocked by Mod Security.] -> [web1->/var/log/apahe2/error.log]

My first idea was to add an interface like the one implemented for Picviz (using a named pipe). But the required information is already available in the OSSEC MySQL database (if you enabled this feature). To feed Afterglow with OSSEC data, I’m using a Perl script which read the database. The script syntax is:

  Usage: ./alerts2afterglow.pl --dbpass=password [--dbhost=127.0.0.1] [--dbport=3306]
     [--dbname=ossec] [--dbuser=ossec] [--logfile=./alerts2afterglow.log]
     [--exclude-alerts=id1[,id2,...]] [--time-interval="30 minute"]
     [--do-reverse] [--show-duplicate] [--help] [--debug]

The most important parameters are:

  • –time-interval” allows to specify the amount of alerts to export starting from now(). Supported values are “second”, “minute”, “hour”, “day” or “week”.
  • –exclude-alert” allows to exclude a list of OSSEC alert IDs. This is useful to remove “noise” from your graphs. IDs are separated by commas.
  • –do-reverse” allows to perform a reverse DNS lookup of all IP addresses extracted from the database. Sometimes, it’s easier to interpret the source of the attacks

To generate a complete graph, combine the Perl script with Afterglow and a dot rendering tool:

  $ ./alerts2afterglow.pl --dbpass=xxx \
                          --exclude-alerts=3302,3303 \
                          --time-interval="1 hour" \
        | ./afterglow.pl -c ossec.properties \
        | circo -v -Tgif -o /var/www/ossec-alerts-1h.gif

And here are some examples of generated maps:

OSSEC Alerts

(Click to enlarge)

OSSEC Alerts 2

(Click to enlarge)

The Perl script is available here. Comments and contributions are welcome!

Post #BruCON Network Analyzis

NetworkBruCON is over! As usual, when I attended a security conference, I’m trying to write a small wrap-up for me followers. With BruCON, it’s completely different: I’m on the other side of the stage. For the “0×03” edition, I was again involved in the “bits & bytes” stuff. I did not attended talks always between two requests or small problems to solve… and I like this!

So, building a network for a security/hackers conference is a great challenge. You have to provide a (as much as possible) free Internet access but, for legal reasons, you have to keep an eye (even both!) on the visitors behavior. To achieve this, we kept a trace of all network flows generated during the conference. For privacy reason, we do not keep the payloads, just the IP headers (source IP/port & destination IP/port with timestamps). The audience of a security conference are normally good skilled people regarding security. I analyzed the data captured during the two days (Monday 19th and Tuesday 20th). Here are some facts…

First, a few words about our setup. We provided three different networks: A public Wi-Fi available to all the visitors, a private Wi-Fi dedicated to the crew, speakers and “VIP’s” and a wired network for trainings, workshops, the crew. Our Internet pipe (1Gbits) was provided by Belnet, the Belgian national research network with IPv4 as well as IPv6. The traffic was captured and analyzed in real time by a network sniffer which provided interesting statistics:

The “Internet traffic” is the traffic exchanged between the different networks. The “Incoming traffic” represents the traffic from the Internet (the users downloads) and the “Outgoing traffic” represents the traffic sent to the Internet. The peaks are the tests performed by our video team with higher quality streaming.

Internal Traffic

Incoming Traffic

Outgoing TrafficWhat about the flows between hosts and the Internet? The following maps represents the traffic exchanged on Monday and Tuesday.

Network Mapping 2011/09/19

(Click to view in full size)

Network Mapping 2011/09/20

(Click to view in full size)

Were our visitors aware of their own security? For the second time, we run a wall of sheep during the conference. We sniffed the public Wi-Fi network (and only this one!) for interesting traffic. Again and again, some people still use unsafe protocols! A visitor sent thousands of SNMP requests over the network during the event. I suppose this guy was using a corporate laptop with a running network tool in the background. Note that the traffic capture was executed live and no data was saved nor divulged outside of the BruCON network team.

Here are the top detected protocols:

Protocol Detected Occurrences
SMB 4894
IMAP 1159
HTTP 481
FTP 340
POP 63
TELNET 30
NNTP 8

The web traffic was also analyzed. The traffic sent over the well-known ports (80, 8000, 8080, 3128, 443)  was inspected to extract URLs. Here again, only the URLs were extracted, the HTTP content was not inspected nor stored.

Here is the top-30 of the most visited sites:

URLs Detected Occurrences
pwn3d.be 2751
www.google.com 2624
search.twitter.com 2392
www.google.be 2137
www.facebook.com 1761
193.191.65.51 1546
api.twitter.com 1331
notify8.dropbox.com 1546
pixel.quantserve.com 1065
notify2.dropbox.com 882
platform.twitter.com 791
static.ak.fbcdn.net 729
brucon.openamd.org 710
api.openbeacon.net 681
notify1.dropbox.com 679
twitter.com 662
notify7.dropbox.com 660
profile.ak.fbcdn.net 623
cdn.api.twitter.com 613
mail.google.com 598
notify6.dropbox.com 586
clients1.google.com 553
www.youtube.com 515
suggestqueries.google.com 506
www.msftncsi.com 495
fxfeeds.mozilla.com 472
csi.gstatic.com 465
notify9.dropbox.com 465
connect.facebook.net 461
ocsp.verisign.com 454

The top URL (pwn3d.be) was in fact the wall of sheep. I saw lot of people keeping an eye on this page. The IP address was an address from the DHCP pool used by visitors. Otherwise, nothing fancy, the classic websites remains the same. Interesting to see how many people are using Dropbox!

But, it is sometimes interesting to search for the most obscure URLs (read: accessed only one time) or what occurs below the radar. Funny: did a visitor make some only shopping (c-and-a.com) during the conference? ;-)

URLs
media.rtl.be
br.yahoo.com
br.m.yahoo.com
p4.dkqv3d2fqxlpe.ailhxnhx2lw7xjgs.595488…
debianadmin.com
www.pandasecurity.com
p4.dkqv3d2fqxlpe.ailhxnhx2lw7xjgs.if.v4….
www.windowsreference.com
static.zanox.com
api.zanox.com
platinum-suisseid-g2.ocsp.swisssign.net
IndC1DigitalID-crl.verisign.com
crl.swisssign.net
cache.pandasoftware.com
static.googleusercontent.com
pool.pebblemedia.adhese.com
content.landingpage.be
m.iszene.com
c.tifbs.net
postview.c-and-a.com

Of course, we installed an IDS to capture suspicious traffic. The top detected events follow:

Signatures Occurrences
MS-SQL probe response overflow attempt 9162
POLICY poll.gotomypc.com access 2343
DNS SPOOF query response with TTL of 1 min. and no authority 875
MISC MS Terminal Server no encryption session initiation attempt 288
MISC MS Terminal server request 150
NETBIOS SMB-DS repeated logon failure 103
MS-SQL version overflow attempt 48
RPC portmap status request UDP 30
NETBIOS DCERPC ISystemActivator path overflow attempt little endian 18
WEB-CLIENT PNG large image height download attempt 10
ATTACK-RESPONSES id check returned root 6
MISC AFS access 6
MS-SQL ping attempt 6
WEB-CLIENT Windows Media Player directory traversal via Content-Disposition attempt 6
INFO Connection Closed MSG from Port 80 4
WEB-CLIENT PNG large colour depth download attempt 2
MISC Source Port 20 to <1024 1

Did we face security incidents? For sure, I detected classic stuff:

  • Rogue access points (broadcasting the “brucon” SSID)
  • Port scans
  • Gateway ARP spoofing

A few words about IPv6? We offered IPv6 via router advertisements. 10% of the visitors accepted the RA and got an IPv6. As the BruCON website is running on IPv6, it was the preferred protocol during the event:

BruCON IPv6 Traffic

(Click to view in full size)

To conclude, some tips if you are to deploy a network during a security conference in a “wild environment“:

  • Internet is mandatory. Your visitors expect to have a powerful and reliable Internet access. Be prepared to the worst! Our DNS/DHCP crashed in the middle of the conference! Have backup plans and alternative solutions!
  • Do not offer open Wi-Fi. Protect it via a WPA(2) key. The goal is not to avoid people to use it. The goal is to prove your “due care” in case of problems.
  • In the same way, capture the traffic (via netflow, tcpdump or any other tool) to keep a trace of who did what and when. Don’t store the packets payload for privacy and performance (storage requirements) reasons.
  • Keep an eye on your network, all the time. It’s like leaving hot milk on the fire.
  • Try to keep control of all the infrastructure from A to Z. Ex: have access on a core router will help you to quickly implement basic access-lists to drop offensive users or protocols.
  • Be reachable: broadcast a phone number and/or e-mail address where people could report suspicious activities.
  • After the conference, burn a DVD with all your evidences (with SHA1/MD5 hashes).

Iptables Logs Mapping on GoogleMaps

Google VisibilityMy Linux servers are all protected by a local iptables firewall. This is an excellent firewall which implements all the core features that we are expecting from a decent firewall system. Except… logging and reporting! By default, iptables send its logs using the kernel logging facilities. Those can be intercepted by common Syslog daemons: Events are collected and stored in a flat file. Note that some Syslog implementations, like rsyslog, have a built-in mechanism to store logs into a MySQL database. But, messages are stored “as is” without processing or normalization; this makes them difficult to use. Of course, solutions exists to parse Syslog flat files and generate firewalls stats (have a look at fwlogwatch) but I’m looking for something more “visual”. Visibility is a key point!

My idea is to store the iptables events into a MySQL database but with some parsing, which means that every important information (source IP, destination IP, ports, …) can be indexed and re-used in queries later. As usual, the goal is to give more value to the huge amount of logs produced by iptables. Example of an interesting information: To know from where is coming the traffic to my server and map it on a Google map. To achieve this, iptables has fortunately another way to send logs to the user space: the ULOG target:

The ULOG target is used to provide user-space logging of matching packets. If a packet is matched and the ULOG target is set, the packet information is multicasted together with the whole packet through a netlink socket. One or more user-space processes may then subscribe to various multicast groups and receive the packet. This is in other words a more complete and more sophisticated logging facility that is only used by iptables and Netfilter so far, and it contains much better facilities for logging packets. This target enables us to log information to MySQL databases, and other databases, making it much simpler to search for specific packets, and to group log entries. (Source: linuxtopia.org)

To collect the packets sent using the ULOG target, a daemon exists and is called – logically – ulogd. It allows you to store the received packets to the following destinations:

  • Databases (MySQL, SQLite, PostgressSQL)
  • Flat files
  • pcap files

By the way, the last option is really cool and allow you to store a dump of all packets in specific conditions and analyze them later using your best pcap file processor (tcpdump, Wireshark, …) In my case, I just store the packets into a MySQL DB. First download and install the ulogd software (The example below is based on an Ubuntu Server):

  # apt-get install ulogd ulodg-mysql

Create a MySQL database. Here on the same host but you can use a remote DB server:

  # cat <<END | mysql -u root -p
  create database ulogd;
  grant all privileges on ulogd.* to "ulogd"@"localhost" identified by "strOngP4ss";
  END
  # mysql -u root -p ulogd </usr/share/doc/ulogd/mysql.table

Configure ulogd to send packets to the MySQL database via the configuration file “ulogd.conf“:

  # cat ulogd.conf
  nlgroup=1
  logfile="/var/log/ulog/ulogd.log"
  loglevel=1
  rmem=131071
  bufsize=150000
  plugin="/usr/lib/ulogd/ulogd_BASE.so"
  plugin="/usr/lib/ulogd/ulogd_MYSQL.so"
  [MYSQL]
  table="ulog"
  pass="str0ngP4ss"
  user="ulogd"
  db="ulogd"
  host="localhost"

If you need help, check out the ulogd manpage for details. Start the daemon:

  # service ulogd start

Now, let’s reconfigure your iptables rulebase to log packets using the ULOG target. Important recommendation: take care when logging your packets! Using a MySQL database might have a huge impact on the system performance! In my example, I’ll just log the incoming traffic. Ubuntu uses some kind wrapper to manage your firewall. It is called “UFW” or “Uncomplicated FireWall“. It’s convenient for basic configuration tasks but limited for specific changes like here. It’s not possible to enable the ULOG support via ufw, you will have to manually change the “before.rules” file. Add the following line:

  # allow logging to ulogd
  -A ufw-before-input -i eth0 -j ULOG --ulog-nlgroup 1 --ulog-prefix ULOG

And restart ufw! You should see immediately packets logged into your MySQL DB. Now, we have a database full of very interesting information! Let’s extract and add more value to some of them. The schema below gives an overview of the components:

ulogd Architecture

(Click to enlarge)

A small Perl script will extract the source IP addresses based on a specific SQL query like:

  • The last 10000 IP addresses which hit the port 80
  • The IP addresses detected for the last 10 minutes

The IP addresses will be geo-localized using the MaxMind database and its Perl API. I’m using  the GeoLiteCity database. The Perl script will produce a XML file containing all the information required by the Google:

  <?xml version="1.0" encoding="UTF-8" ?>
  <markers entries="2526">
  <marker country_code="US" country_name="United States" lng="-122.2995" lat="47.5839"/>
  <marker country_code="BE" country_name="Belgium" lng="4.3500" lat="50.6667"/>
  <marker country_code="BE" country_name="Belgium" lng="4.3500" lat="50.6667"/>
  <marker country_code="US" country_name="United States" lng="-122.3933" lat="37.7697"/>
  <marker country_code="BE" country_name="Belgium" lng="4.3500" lat="50.6667"/>
  <marker country_code="FR" country_name="France" lng="2.3333" lat="48.8667"/>
  ...
  </markers>

As you can see, only the coordinates will be used by Google. IP addresses are no used! (better for confidentiality). Last step, generate the GoogleMaps using the API. This will be achieved with some lines of Javascript. Here is the final result:

GoogleMaps Vizualisation

(Click to see a live map)

I did not write the HTML and Javascript code myself. This is grabbed from the Orange Security Blog where Jean-François Audenard wrote a similar post a few weeks ago about mapping botnets on GoogleMaps. Many thanks to him for allowing me to re-use it here.

Finally, it’s quite easy to automate the process with a simple crontab to create a new XML files every x minutes and perform an auto-refresh of the HTML page. Don’t forget to cleanup the MySQL data by removing the old logs (my main system logged 4.6M of packets in two days!)

Resources:

  • The Perl script to generate the XML file
  • The HTML page to geneate the GoogleMap