Archive for the ‘security’ tag

Threat intelligence: OTX, Bro, SiLK, BIND RPZ, OSSEC  

Posted at 8:15 am in Uncategorized

Building a toolbox around threat intelligence can be done with freely available tools. Shared information about malicious behaviour allows you to detect and sometimes prevent activity from – and to – Internet resources that could compromise your systems’ security.

I’ve already described how to use lists of malicious domain names in a BIND RPZ (Response Policy Zone). Adding an information feed like AlienVault OTX (Open Threat Exchange) to the mix further extends the awareness and detection capabilities.

AlienVault is probably most known for their SIEM (Security Information and Event Management) named Unified Security Management™, with a scaled-down open source version named Open Source Security Information and Event Management (OSSIM). They also provide a platform for sharing threat intelligence, namely Open Threat Exchange (OTX). OTX is based on registered users sharing security information, for instance domains and hostnames involved in phishing scams, IP addresses performing brute force SSH login attempts, etc. The information is divided into so-called pulses, each pulse a set of information items considered part of the same malicious activity. For example, a pulse can contain URLs to a site spreading drive-by malware, the IP addresses of their C&C, along with hashes of the files. By selecting which pulses and/or users to subscribe to, the registered information in each pulse will be available through a feed from their API.

Carefully reviewing which users/pulses to subscribe to – there’s always a risk of false positives – I’m now regularly receiving an updated feed. This feed is parsed and currently split into two files: One RPZ file containing hostnames and domains for use with BIND, and one file containing IP addresses for use with SiLK.

As explained in an earlier post, OSSEC will let me know if someone (or something) makes DNS requests for a domain or hostname registered as malicious. Extending this to include the DNS records obtained from OTX was simply a matter of defining a new RPZ in BIND. Depending on how this is used (block? redirect? alert?), a whitelist should be in place to prevent accidental blocking of known good domains. One pulse describes all the Internet resources a client infected by a certain exploit will contact, including some certificate authorities which are not necessarily considered evil.

The file with IP addresses can be used directly with a firewall, by logging or even blocking or throttling traffic to/from the IP addresses in question. For rear-view mirror analysis it can be used with SiLK, to find out if there has been any network traffic to or from any of these addresses. To do this, you will first have to create an IP set with the command rwsetbuild:

# rwsetbuild /some/path/ip-otx.txt /some/path/ip-otx.set

 

Now we can use this set file in our queries. For this query I’ve manually selected just a few inbound matches:

# rwfilter --proto=0-255 --start-date=2016/01/01 \
  --sipset=/some/path/ip-otx.set --type=all \
  --pass=stdout | rwcut -f 1-5
            sIP|            dIP|sPort|dPort|pro|
   185.94.111.1|  my.ip.network|60264|   53| 17|
   216.243.31.2|  my.ip.network|33091|   80|  6|
   71.6.135.131|  my.ip.network|63604|  993|  6|
   71.6.135.131|  my.ip.network|60633|  993|  6|
   71.6.135.131|  my.ip.network|60888|  993|  6|
   71.6.135.131|  my.ip.network|32985|  993|  6|
   71.6.135.131|  my.ip.network|33060|  993|  6|
   71.6.135.131|  my.ip.network|33089|  993|  6|
   71.6.135.131|  my.ip.network|33103|  993|  6|
   71.6.135.131|  my.ip.network|33165|  993|  6|
   71.6.135.131|  my.ip.network|33185|  993|  6|
   71.6.135.131|  my.ip.network|33614|  993|  6|
   71.6.135.131|  my.ip.network|33750|  993|  6|
   71.6.135.131|  my.ip.network|60330|  993|  6|
  185.130.5.224|  my.ip.network|60000|   80|  6|
  185.130.5.224|  my.ip.network|60000|   80|  6|
  198.20.99.130|  my.ip.network|    0|    0|  1|
  185.130.5.201|  my.ip.network|43176|   53| 17|
  129.82.138.44|  my.ip.network|    0|    0|  1|
  185.130.5.224|  my.ip.network|60000|   80|  6|
  185.130.5.224|  my.ip.network|60000|   80|  6|

 

When you need more details about the listed address or other indicators, OTX provides a search form to find the pulse(s) in which the indicator was registered.

OTX can be used with Bro as well, and there are at least two Bro scripts for updating the feeds from the OTX API. The one that works for me is https://github.com/hosom/bro-otx. The script will make Bro register activity that matches indicators from an OTX pulse.

Sample log entries, modified for readability:

my.ip.network 59541 some.dns.ip    53 - - - union83939k.wordpress.com
                                            Intel::DOMAIN DNS::IN_REQUEST
my.ip.network 40453 54.183.130.144 80 - - - ow.ly
                                            Intel::DOMAIN HTTP::IN_HOST_HEADER
74.82.47.54   47235 my.ip.network  80 - - - 74.82.47.54
                                            Intel::ADDRConn::IN_ORIG

 

This article mentions just a few components that can be combined. Obviously there’s a lot of possibilities for integrating and interfacing between different systems. There are several companies that provide threat intelligence feeds, some for free and some for paying customers. Depending on the product(s), a SIEM would be able to combine and correlate the different kinds of threat intelligence to detected events.

Written by bjorn on March 9th, 2016

Tagged with , , , , , , , , , ,

ClamAV client/server setup  

Posted at 8:37 pm in Uncategorized

Note: This may very well be well-known information, but I found it difficult to get exact answers from the official ClamAV documentation, available man pages, and other kinds of documentation. The most useful hint originated from a mailing list thread considering ClamAV version 0.70, which is getting rather outdated.

My original issue was getting antivirus functionality with mod_security and Apache on a Raspberry Pi server. Due to memory constraints it seems Apache and ClamAV (my version at the time of writing: 0.99) do not coexist happily on the same RPi unit. The obvious solution: Run the ClamAV daemon on a separate device, and set up mod_security with client-side scanning.

The command-line client for antivirus scanning with the ClamAV daemon is named clamdscan. In older Debian releases like Squeeze and Wheezy, clamdscan is included in Debian’s clamav-daemon package, so the daemon will be installed even though you only need the client. This has been fixed in Debian Jessie and above, where clamdscan has become a separate package.

Both the ClamAV daemon (clamd) and the scanner client (clamdscan) have the same configuration file, unless otherwise specified. In Debian this is /etc/clamav/clamd.conf. Getting the client/server relationship configured is a matter of defining the socket on which they communicate. If the client and daemon (server) is running on the same system, the most efficient communication happens over a Unix socket (clamd.conf setting: LocalSocket). On different systems, however, you will need to use the settings TCPAddr and TCPSocket:

TCPAddr defines the IP address (and not TCP address, which would be a port number) on which the server should listen and/or which the client should make contact. Note that the documentation states that TCPAddr is used to define the IP address(es) clamd should listen on, and that it’s by default disabled. However, when setting TCPSocket and leaving TCPAddr unconfigured, clamd will listen on all IP addresses (0.0.0.0/:::). The documentation also makes no mention that the setting is used by clamdscan.

TCPSocket is the TCP port on which the communication takes place.

The following diagram illustrates the relationship:

ClamAV-client-server

Note: On a Squeeze/Wheezy Debian system, setting TCPAddr to a non-local IP address in clamd.conf will naturally make clamd (clamav-daemon) complain. You should disable clamav-daemon and clamav-freshclam on a client-only system:

# update-rc.d -f clamav-daemon remove
update-rc.d: using dependency based boot sequencing
# update-rc.d -f clamav-freshclam remove
update-rc.d: using dependency based boot sequencing

 

After configuring as specified above, antivirus functionality should be tested with clamdscan. On the client node:

# clamdscan -v klez.exe 
klez.exe: W32.Elkern.C FOUND
----------- SCAN SUMMARY -----------
Infected files: 1

 

On the server node, from the ClamAV log:

Sat Mar 5 20:31:59 2016 -> instream(local):
W32.Elkern.C(16bc8fcec023b05b38af3580607bb728:92499) FOUND

 

Finally, I reconfigured the “runav.pl” file in mod_security by changing from clamscan to clamdscan.

 

Written by bjorn on March 5th, 2016

Tagged with , , , , ,

Honeynet outbound probes  

Posted at 8:42 am in Uncategorized

My Cowrie honeypot is now seeing a surge of outbound SSH tunnel probes, both towards different mail servers but also towards a specific web server, probably with the purpose of informing about a successful intrusion. The honeypot has seen outbound attempts before, but not as persistent as with this bot from .ru.

Cowrie fakes successful SSH tunneling, so the bot is at least kept somewhat busy. The honeypot is also in a very tight network environment with limited possibilities for outbound connections.

Here are some examples, formatted for readability:

2016-02-22 01:43:00+0100 [SSHService ssh-connection on
  HoneyPotTransport,1580,193.169.52.214] direct-tcp connection
  request to 69.50.231.136:25
2016-02-22 01:43:01+0100 [SSHService ssh-connection on
  HoneyPotTransport,1580,193.169.52.214] direct-tcp connection
  request to 202.108.6.242:587
2016-02-22 01:43:54+0100 [SSHChannel None (883) on
  SSHService ssh-connection on HoneyPotTransport,1580,193.169.52.214]
  direct-tcp forward to 64.233.164.108:465 with data
  '\x16\x03\x01\x00S\x01\x00\x00O\x03\x01V\x15\xbc\xc0\x0c
   \x8fK\xf4\x9d\xb4\xecx\xaf\x13t;\xdeR\xf6c\r6\x93sv\xc7
   \xacXq\xd0\xe8\x02\x00\x00(\x009\x008\x005\x00\x16\x00
   \x13\x00\n\x003\x002\x00/\x00\x07\x00\x05\x00\x04\x00
   \x15\x00\x12\x00\t\x00\x14\x00\x11\x00\x08\x00\x06\x00\x03\x01\x00'
2016-02-22 02:00:28+0100 [SSHChannel None (979) on
  SSHService ssh-connection on HoneyPotTransport,1580,193.169.52.214]
  direct-tcp forward to 37.1.206.139:25000 with data
  'POST / HTTP/1.1\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0;
   Windows NT 5.1; SV1)\r\nContent-Type: application/x-www-form-urlencoded\r\n
   Connection: close\r\nContent-Length: 21\r\nHost: work.a-poster.info\r\n\r\n'
2016-02-22 03:39:18+0100 [SSHChannel None (0) on
  SSHService ssh-connection on HoneyPotTransport,1589,193.169.52.212]
  direct-tcp forward to 37.1.206.139:80 with data
  'POST / HTTP/1.1\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0;
   Windows NT 5.1; SV1)\r\nContent-Type: application/x-www-form-urlencoded\r\n
   Connection: close\r\nContent-Length: 21\r\nHost: work.a-poster.info\r\n\r\n
   data=ffddaffeccedabae'

 

Written by bjorn on February 22nd, 2016

Tagged with , , ,

Live visualizing Mikrotik firewall traffic with Logstalgia  

Posted at 9:54 pm in Uncategorized

Previously I’ve written about visualizing firewall activity. Revitalizing a fireplot graphing tool gives a nice day-to-day overview, but after being reminded of Logstalgia in this Imgur post I wanted to give live visualization a shot.

Logstalgia is a neat tool for visualizing activity, by feeding it log files or live feeds. It’s originally designed for parsing web server logs, but it also accepts a generic format that allows for other purposes as well. By writing a short Perl script that acts like a syslog server (receiver) and converting the input to a format that Logstalgia accepts, my Mikrotik router is now live reporting any connection attempt to or through the firewall. For the visualization below I triggered a portscan to create some activity, or the video would be rather boring.

To make this work, the firewall must somehow identify traffic that’s being denied (unless you only log blocked traffic). The script will then pass only these log records to Logstalgia. I’ve been testing this with a Mikrotik device, but any firewall able to log to or through syslog will work fine.

Original syslog input

Feb 6 21:42:36 BLOCK: in:ether1 out:(none), src-mac 00:00:00:6a:f3:9c,
proto ICMP (type 8, code 0), 38.71.2.11->192.168.10.10, len 28

 

Logstalgia formatted output:

1454791356|38.71.2.11|ICMP:8/0|200|10

 

I’m starting the perl script and Logstalgia like this:

./syslog2logstalgia | logstalgia -800x640 --disable-progress -x \
--no-bounce --hide-response-code --sync \
-g "TCP,URI=TCP,45" -g "UDP,URI=UDP,45" -g "ICMP,URI=ICMP,10" \
--hide-paddle

 

Note that visualizing firewall logs with Logstalgia has been done by a lot of other people. Howtos for other firewall products may be available via your favourite search engine.

Written by bjorn on February 6th, 2016

Tagged with , , , , ,

Logging WordPress activity to OSSEC  

Posted at 11:53 pm in Uncategorized

Today I came across this blog article, explaining how to make WordPress log suspicious activity to an audit log file, which in turn can be monitored by OSSEC. Everything mentioned in the article was all fine and dandy, until I read the last paragraph: “Note that for this feature to work, you have to use our fork of OSSEC […]“.

Being less than enthusiastic about replacing my existing OSSEC (version 2.8.3) installation with a fork (even if the fork happens to originate from OSSEC’s founder), I wanted to make this work with what I’ve already got. Following the main instructions from the blog article, I installed the sucuri-scanner plugin but did not request an API key – at this point, at least. Then, by providing an absolute path to an existing log file, to which the web server has write access, I activated the plugin’s audit log exporter.

The same absolute path was added to the OSSEC agent‘s ossec.conf (/var/ossec/etc/ossec.conf) file as a syslog file:

 <localfile>
   <log_format>syslog</log_format>
   <location>/var/log/wp/site/audit.log</location>
 </localfile>

 

So far, so good – now to make the OSSEC manager correctly decode and parse the log events.

First, I replaced the whole wordpress_rules.xml file with the one provided by the OSSEC fork. I found the updated wordpress_rules.xml file on https://bitbucket.org/dcid/ossec-hids/, and from there by navigating the source tree (source → ossec-hids/etc/rules/). The exact file location in the repository could change with future versions and commits, so there’s not much of a point in providing an exact URL. Apart from a signature ID collision (two signatures had sid 9507) this updated file was an improvement over the wordpress_rules.xml that came with OSSEC 2.8.3. The file is too large to inline here.

The final piece of the puzzle was to provide a useful decoder. I’ve added the following to the manager‘s /var/ossec/rules/local_decoder.xml:

<decoder name="wordpressaudit">
 <parent>windows-date-format</parent>
 <use_own_name>true</use_own_name>
 <prematch offset="after_parent">WordPressAudit </prematch>
 <regex offset="after_prematch">^\S+ \S+ : (\w+): (\S+); </regex>
 <order>action, srcip</order>
</decoder>

 

And bingo, it works. Failed WordPress logins, along with some other weird activities – and normal as well, if you so wish – will now be identified by OSSEC and you can set the severity levels accordingly. Here’s an example of the OSSEC alert log’s detection of a failed login (formatted for readability):

** Alert 1454537692.8654637: mail - syslog,wordpress,authentication_failed,
2016 Feb 03 23:14:52 (webserver.example.com) 10.0.0.10->/var/log/wp/site/audit.log
Rule: 9501 (level 7) -> 'WordPress authentication failed.'
Src IP: 192.168.0.42
2016-02-03 22:14:51 WordPressAudit www.example.com bjorn@ruberg.no : Error:
  192.168.0.42; User authentication failed: EvilUser

 

and even

** Alert 1454541645.146379: mail - syslog,wordpress,syscheck,
2016 Feb 04 00:20:45 (webserver.example.com) 10.0.0.10->/var/log/wp/site/audit.log
Rule: 9508 (level 7) -> 'WordPress post updated.'
2016-02-03 23:20:44 WordPressAudit www.example.com bjorn@ruberg.no : Notice:
  bjorn, 192.168.100.100; Post was updated; identifier: 4096; name: Some Article Name

 

Written by bjorn on February 3rd, 2016

Tagged with , , , , ,

Localized SSH bruteforce attempts  

Posted at 10:24 pm in Uncategorized

Lately, my honeypot has seen an upsurge in SSH bruteforce login attempts. Among quite a few attackers, one particular IP address in Italy – 79.0.43.89 – is seen more often than the others. I’m seeing login attempts from this IP on other systems as well, so this is a busy one.

What’s funny about this round is that the attackers seem to use localized name lists, as I’ve registered a lot of Norwegian-looking names. The attacker/botnet script tests SSH logins with login name and the number 1 appended to it as a password (e.g. adam / adam1), so if your password is your login name + 1 you should change it ASAP 🙂

It’s also worth noting that there are only boys’ names on the list…

This is the most recent extract:

adam
aleksander
anders
andre
andreas
arne
aslak
bendik
bjorn
christian
daniel
eirik
erik
feliks
gabriel
geir
gunnar
henrik
henry
inge
isak
jacob
jason
jo
johan
jonas
junior
knut
konrad
kristian
lars
lasse
magnus
marius
markus
martin
ole
pal
peter
philip
runar
sander
sigve
simen
sindre
snorre
stian
sveinung
thor
thorbjorn
tom

Written by bjorn on December 18th, 2015

Tagged with , ,

Malware detection with DNS RPZ and OSSEC  

Posted at 2:06 pm in Uncategorized

Building upon a sysadvent article I wrote at work, I’ve set up a dedicated Response Policy Zone using the freely available data files from the Malware Domain Blocklist. There are different ways to do this, but for this particular purpose I’ve imported the text file and generated a single zone file locally. BIND supports up to 32 RPZs, so in my config I’ve set this up as a separate zone, referenced as “malware”.

Below is the zone definition:

zone "malware" {
  type master;
  file "/etc/bind/db.malwaredomains";
};

 
Defining the “malware” zone as an RPZ (I have two response policy zones, one simply named rpz and now this one named malware):

options {
  response-policy { zone "rpz"; zone "malware"; };
};

 
Configure logging. The zones defined in the above response-policy {} setting fall under the rpz logging category.

logging {
  channel named-rpz {
    file "/var/log/bind/rpz.log" versions 3 size 250k;
    severity info;
  };
  category rpz {
  named-rpz;
  };
};

 
In the BIND log files, requests for domains in the malware zone are logged in the RPZ log file, suffixed with the zone reference, namely “malware”.

client 127.0.0.1#53547 (czgtgj.com): rpz QNAME Local-Data rewrite czgtgj.com via czgtgj.com.malware

 
After testing that attempts to reach malware sites are indeed logged by the DNS server, I configured OSSEC to tail BIND’s malware query log. For this I had to write a decoder and define logging rules in OSSEC, shown below. These could probably be drastically improved.

The end result is exactly as I wanted: If someone (or something) on my network is trying to reach a resource within a domain registered as affiliated with malware, OSSEC will react and alert by email, raise an alarm in your SIEM, or whatever else you want OSSEC to do.

From /var/ossec/etc/local_decoder.xml:

<decoder name="malware-dns">
  <prematch>^client </prematch>
</decoder>
<decoder name="malware-dns-lookup">
  <parent>malware-dns</parent>
  <regex offset="after_parent">^(\.+)#\d+ \((\.+)\): \.+.malware$</regex>
  <order>srcip, extra_data</order>
</decoder>

 
From /var/ossec/rules/malware_dns_rules.xml:

<group name="syslog,bind">
  <rule id="110201" level="0">
    <decoded_as>malware-dns</decoded_as>
    <description>Malware DNS group</description>
  </rule>
  
  <rule id="110202" level="8">
    <if_sid>110201</if_sid>
    <match>malware$</match>
    <description>Malware DNS lookup</description>
  </rule>
</group>

 
From /var/ossec/etc/ossec.conf:

<rules>
  [...]
  <include>malware_dns_rules.xml</include>
</rules>

 
Now, if something should reach out to a malware domain, I will get an email from my OSSEC server:

Received From: server->/var/log/bind/rpz.log
Rule: 110202 fired (level 8) -> "Malware DNS lookup"
Portion of the log(s):

client 127.0.0.1#52162 (czgtgj.com):
rpz QNAME Local-Data rewrite czgtgj.com via czgtgj.com.malware

 

Written by bjorn on December 8th, 2015

Tagged with , , , , , ,

Installing Bro, the network security monitor, on a Raspberry Pi  

Posted at 8:23 pm in Uncategorized

In the continuing quest to install security software on Raspberry Pis, testing their capacity to be used as small nodes that can be placed here and there on demand, the time has come for installing Bro.

The hardware/OS in question is a Raspberry Pi 2, with 1G RAM and 4 CPU cores. It’s running the Jessie version of Raspbian.

The Bro project kindly provides precompiled Debian packages, but only for the i386 and amd64 architectures. Luckily they also provide the source files and build instructions for Debian!

So I followed the instructions listed here but instead of adding the regular repo (starting with “deb“) to /etc/apt/sources.list.d/bro.list, I changed it to deb-src. After that I added the Bro repo key. Commands shown below:

# echo 'deb-src http://download.opensuse.org/repositories/network:/bro/Debian_8.0/ /' \
  >> /etc/apt/sources.list.d/bro.list
# wget http://download.opensuse.org/repositories/network:bro/Debian_8.0/Release.key \
  -O - | apt-key add -

 

Time to update the repo status and then install the dependencies required for the build:

# apt-get update
# apt-get build-dep bro

 

Depending on what you already have running on your RPi, this could be a short or long list of packages. On mine, running Raspbian Jessie, this is what had to be installed:

bison cmake cmake-data libarchive13 libbison-dev libpcap-dev libpython-dev
libpython2.7-dev libssl-dev python-dev python2.7-dev swig swig2.0

 

When that’s done, it’s time for the real job: Build Bro from source with Debian build instructions. This will take some time, on my RPi2 it took ~100 minutes. Below is the command required:

# apt-get source --compile bro

 

When that job has completed, you will find some .deb packages in your current directory. You will need to install them all (except for the dev package), like this:

# dpkg -i bro_2.4.1-0_armhf.deb bro-core_2.4.1-0_armhf.deb \
broctl_2.4.1-0_armhf.deb libbroccoli_2.4.1-0_armhf.deb

 

The Bro software will have been installed under /opt/bro, so that’s where you need to go to start using it. Other people write better Bro documentation than I do so I will leave that to them. A quickstart probably won’t hurt, so after making your local changes to /opt/bro/etc/node.conf you can start Bro as shown below. Logs will appear in /opt/bro/logs/current/.

# /opt/bro/bin/broctl 
Hint: Run the broctl "deploy" command to get started.
Welcome to BroControl 1.4
Type "help" for help.
[BroControl] > deploy
checking configurations ...
installing ...
removing old policies in /opt/bro/spool/installed-scripts-do-not-touch/site ...
removing old policies in /opt/bro/spool/installed-scripts-do-not-touch/auto ...
creating policy directories ...
installing site policies ...
generating standalone-layout.bro ...
generating local-networks.bro ...
generating broctl-config.bro ...
generating broctl-config.sh ...
updating nodes ...
stopping ...
stopping bro ...
starting ...
starting bro ...
[BroControl] > status
Getting process status ...
Getting peer status ...
Name Type Host Status Pid Peers Started
bro standalone localhost running 16514 ??? 01 Nov 22:19:57
[BroControl] >

 

Written by bjorn on November 1st, 2015

Tagged with , , , ,

Honeypot password attempts  

Posted at 10:58 am in Uncategorized

After running a small SSH-only honeypot for a week or so, I’m a bit surprised with the complexity of some of the attempted passwords. The passwords that are most frequently attempted are quite simple, as shown in the top 5 passwords for the root account:

root
[no password]
123456
synopass
!Q@W#E

These are less obvious:

dmiwoqewq4561e3wq
get_remote_ipaddr
(yes, really!)
IF1AT9v6VaYmBkMneylI
NJglWpmSQ60etyio
sheiph7cus1ieChi
SmartGen!VDI2013
VodaHoriALeBlbe45*
WSX831102edc3831rfv
zxczxczxczcxzxcxzczxc
zxczxczxczxczcxzxczxc
zxczxczxczxczxczcxzxc

Some of these seem to be used by the same botnets, as they follow similar curves in Dshield‘s observations. The three last ones (zxc...) have not yet been listed by Dshield.

Written by bjorn on October 17th, 2015

Tagged with , , ,

VIsualizing firewall activity  

Posted at 7:35 am in Uncategorized

Inspired by the efforts of a previous Redpill Linpro colleague, Espen Grøndahl, I’ve revived (or rather re-invented) his project “Fireplot”. By analyzing and filtering firewall logs, Fireplot graphs attempts to access blocked firewall ports, visualizing unexpected and unwanted activity towards my network.

Fireplot

Firewall activity visualization – click image for original size

The Y axis is logarithmic, since activity towards lower ports is often more interesting. Over 24 hours, one graph per day, TCP activity is plotted in green and UDP activity in light blue. Note the horizontal line showing SSH (TCP port 22) and telnet (TCP port 23) probes. The graph also shows a very regular probing for UDP port 7.

I’m currently parsing logs from a Mikrotik firewall/router, but since the data gathering is merely a matter of an appropriate regular expression it shouldn’t be difficult to make it graph iptables logs or other firewall-ish log data.

The Perl code is very much in beta state at the moment, so I won’t publish any code just yet. Stay tuned for updates. Meanwhile, visit Lars Strand’s inspiring article on the original project!

Written by bjorn on October 8th, 2015

Tagged with , , , , ,