After fixing hardware problems that had my home network sensor out of commission for the better part of a year, I recently got the system inline again. Because the sensor had been down for so long, I was running a fairly old version of Snort, 2.9.0.3, along with barnyard 0.2.0. I decided the first thing I should do after updating the OS itself was update Snort and Barnyard.
I won't go through the process in detail since there are many resources online for installing and configuring Snort. The main thing I will point out is that you should always look in the docs/ directory for information on installing and upgrading. If you're updating from a previous version, pay particular attention to changes and new features. Another important thing to do is look closely at the snort.conf provided with a given version in
I had two main problems when I updated, one with Snort and one with Barnyard2. Since Snort is the main piece of the puzzle here, I updated it prior to Barnyard. After updating to Snort-2.9.2.1 and fixing the configuration, I was able to run Snort successfully using the options I normally had previously. However, as soon as I put the sensor back inline and Snort started processing packets, Snort would exit with an error.
Can't acquire (-1) - ipq_daq_acquire: ipq_read=-1 error Failed to receive netlink message!
A quick search revealed that I had to remove the ip_queue module. JJ Cummings on the #snort channel pointed out to me that NFQ is the more recent option than IPQ. I am using Slackware-current, so even though it is a maintained distribution it is also not surprising that I was using an older option. Slackware also did not have a couple of the required libraries to compile DAQ with support for NFQ, so I went to Slackbuilds.org to get the files allowing me to create Slackware packages for libnetfilter_queue and libnfnetlink.
Once I got the new packages installed, made sure the ip_queue module wasn't loaded, recompiled DAQ to support NFQ, and changed my Snort init to use --daq nfq, my inline Snort was working once again.
Next, I updated from Barnyard-0.2.0.
$ barnyard2 -V
______ -*> Barnyard2 <*-
/ ,,_ \ Version 2.1.10-beta2 (Build 266) TCL
|o" )~| By Ian Firns (SecurixLive): http://www.securixlive.com/
+ '''' + (C) Copyright 2008-2011 Ian Firns
Barnyard2 is needed to process Snort's newer output mode, unified2. My snort.conf changed from:
output log_unified: filename unified.log, limit 128
to:
output unified2: filename unified.log, limit 128
When I got Barnyard2 up and running, it was obviously not successfully processing the unified2 files from Snort. Barnyard2 kept repeating the following error as it tried to process the files.
WARNING: No function defined to read header.
I found a thread on the snort-users list that indicated Barnyard2 was getting a file type it wasn't expecting, which made sense considering the warning message. This issue gave me more problems than it should have and I eventually realized it was because of an error in my barnyard.conf file. The input is supposed to read "input unified2" but I had somehow managed to include a colon after "input". Once I fixed that line, Barnyard2 started working, with alerts being properly processed and showing up in Sguil once again.
The next update will be to go from Sguil-0.7.0 to Sguil-0.8.0.
26 March, 2012
Updating to Snort 2.9.2 and Barnyard2
Posted by
Nathaniel Richmond
at
07:26
0
comments
Labels: barnyard, ids, inline, linux, slackware, snort, system administration
04 January, 2012
Flocon 2012
Flocon 2012 is January 9-12, which is next week. It's fairly late, but I believe registration is still open. The schedule includes speakers from many organizations and looks quite interesting. I will be attending and am looking forward to it.
Happy New Year!
Posted by
Nathaniel Richmond
at
10:45
0
comments
14 September, 2011
Recent Advances in Intrusion Detection 2011
For anyone still following despite my infrequent posting, I will be going to the International Symposium on Recent Advances in Intrusion Detection next week. I haven't made time to attend a conference in quite a while, so I'm looking forward to it.
If anyone that knows me is attending and interested in getting together, let me know. If you know me either online or in meatspace, hopefully that means you know how to reach me.
This post doubled my number of blog posts to date for 2011. The most likely next post will be covering anything interesting from the conference. Beyond that, I don't anticipate much posting activity in the near future for a number of reasons.
Posted by
Nathaniel Richmond
at
18:32
0
comments
28 February, 2011
Using ettercap for ARP poisoning
Ettercap is certainly nothing new, and there is plenty of documentation around to see how to use it, but I was sitting here goofing around and decided to record my results. I am not advocating this type of thing on a public network, and ARP poisoning or other attacks often fall afoul of terms of service for public and private networks, and may even be illegal in some jurisdictions.
First, I looked at my default route.
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.71.0.0 0.0.0.0 255.255.255.0 U 2 0 0 wlan0
0.0.0.0 10.71.0.1 0.0.0.0 UG 0 0 0 wlan0
To sniff the whole subnet, I'll want to do some ARP poisoning to send all traffic to/from the default route through my system.
$ sudo ettercap -i wlan0 -T -M arp:remote /10.71.0.1/ //
You can also use "// //" to designate ARP poisoning no matter what source and destination ettercap sees. The "-T" tells ettercap to use the text interface, which is still interactive. There is also a curses-based interface, "-C", and GTK with "-G" though it has always seemed less reliable to me than the others. The curses interface is actually pretty nice.
Once you run the command, ettercap should enumerate hosts and you will start seeing a bunch of traffic information scrolling through your console. How do we know if it's actually working? If you see non-broadcast traffic destined for other hosts, it will be obvious and you will know you're successfully sniffing all the traffic.
Another fun way is by opening etherape to see a realtime visualization of the traffic. If you are seeing typical non-broadcast traffic like HTTP, HTTPS, that's an indicator that you're successfully ARP poisoning. You can also get a quick idea if there are particular hosts getting a lot of traffic activity. I've seen the typical sites like Facebook, Amazon, Akamai, and LLNW, but also more interesting sites that are easily identifiable as VPN concentrators, banks, and more.
You can also of course use various tools including ettercap with the "-w" option to write traffic to a file and review at my leisure to look for interesting data. Ettercap also has an interesting utility to automatically grab usernames and passwords. From the man page:
-L, --log
Log all the packets to binary files. These files can be parsed
by etterlog(8) to extract human readable data. With this option,
all packets sniffed by ettercap will be logged, together with
all the passive info (host info + user & pass) it can collect.
Given a LOGFILE, ettercap will create LOGFILE.ecp (for packets)
and LOGFILE.eci (for the infos).
If you didn't run this with ettercap originally, you can also run it on a saved packet capture.
ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Please select an User Interface
$ ls hotel*
$ etterlog -a hotel.eci
etterlog NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Log file version : NG-0.7.3
Timestamp : Wed Feb 16 14:20:57 2010
Type : LOG_INFO
Number of hosts (total) : 248
Number of local hosts : 30
Number of non local hosts : 0
Number of gateway : 0
Number of discovered services : 240
Number of accounts captured : 4
74.125.93.191 TCP 80 USER: fakeuser PASS: fakepasswd
I changed the data above and of course most sites these days are hopefully forcing encrypted logins.
These days, many sites can be hosted on one IP or virtual server. If you're not catching the DNS or HTTP request specifically before the login that was captured, the easiest way to determine which site on a specific IP was being visited would be opening up the packet capture with a tool like Wireshark, using a filter for the IP, then looking at the actual web traffic for the site's name. Looking in Wireshark, I can see the GET immediately after the TCP handshake.
GET /members/bbs/showthread.php HTTP/1.1
Host: www.fakedomain.com
This really just scratches the surface of what you can do with ettercap and other network tools. ARP poisoning still works, particularly on public networks, and many people log in to many services that can be easily compromised through sniffing (I write while sitting in an airport on public WiFi logged into my blogger account). A relatively recent high profile example was when the Metasploit site was briefly hijacked by successful ARP poisoning.
There are numerous other attacks besides sniffing that could succeed when ARP poisoning, many involving redirecting traffic or injecting malicious content. For instance, you can use something like sslstrip to redirect all HTTPS traffic to HTTP, grabbing credentials in the process. You could also inject content directly using etterfilter.
The etterfilter utility is used to compile source filter files into
binary filter files that can be interpreted by the JIT interpreter in
the ettercap(8) filter engine. You have to compile your filter scripts
in order to use them in ettercap. All syntax/parse errors will be
checked at compile time, so you will be sure to produce a correct
binary filter for ettercap.
Although my example above is obviously on a wireless network as shown by using the wlan0 interface, you can easily perform ARP poisoning on a local wired segment. There are also a number of ways to help detect or prevent poisoning with your network appliances or software.
Finally, ettercap also has a number of interesting plugins available.
$ ettercap -P list
ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Available plugins :
arp_cop 1.1 Report suspicious ARP activity
autoadd 1.2 Automatically add new victims in the target range
chk_poison 1.1 Check if the poisoning had success
dns_spoof 1.1 Sends spoofed dns replies
dos_attack 1.0 Run a d.o.s. attack against an IP address
dummy 3.0 A plugin template (for developers)
find_conn 1.0 Search connections on a switched LAN
find_ettercap 2.0 Try to find ettercap activity
find_ip 1.0 Search an unused IP address in the subnet
finger 1.6 Fingerprint a remote host
finger_submit 1.0 Submit a fingerprint to ettercap's website
gre_relay 1.0 Tunnel broker for redirected GRE tunnels
gw_discover 1.0 Try to find the LAN gateway
isolate 1.0 Isolate an host from the lan
link_type 1.0 Check the link type (hub/switch)
pptp_chapms1 1.0 PPTP: Forces chapms-v1 from chapms-v2
pptp_clear 1.0 PPTP: Tries to force cleartext tunnel
pptp_pap 1.0 PPTP: Forces PAP authentication
pptp_reneg 1.0 PPTP: Forces tunnel re-negotiation
rand_flood 1.0 Flood the LAN with random MAC addresses
remote_browser 1.2 Sends visited URLs to the browser
reply_arp 1.0 Simple arp responder
repoison_arp 1.0 Repoison after broadcast ARP
scan_poisoner 1.0 Actively search other poisoners
search_promisc 1.2 Search promisc NICs in the LAN
smb_clear 1.0 Tries to force SMB cleartext auth
smb_down 1.0 Tries to force SMB to not use NTLM2 key auth
stp_mangler 1.0 Become root of a switches spanning tree
Posted by
Nathaniel Richmond
at
21:01
1 comments
Labels: linux, tcpdump, visualization, wireless
02 December, 2010
Using slackbuilds.org to create Slackware packages
Sorry for the long posting hiatus but don't expect it to end. I just don't have a lot of time or material to devote to the blog right now.
I recently wanted to upgrade Postfix on my Slackware mail server. I used to use packages from LinuxPackages.net for unofficial packages, but the site has gotten less active and always had a reputation for varying package quality. My preference is using the SlackBuilds to build my own packages. It's fairly simple to download their build script, edit as needed, then build a Slackware package from source.
Since Postfix is not available from Slackware official repositories, I downloaded the SlackBuild files and then the Postfix source.
$ wget http://postfix.cs.utah.edu/source/official/postfix-2.6.8.tar.gz $ wget http://slackbuilds.org/slackbuilds/13.1/network/postfix.tar.gz $ tar xvzf postfix.tar.gz $ ls postfix/ README postfix-2.6.8.tar.gz postfix.info slack-desc doinst.sh postfix.SlackBuild* rc.postfixI am using Cyrus-SASL, so it was important for me to note the following from the SlackBuild Postfix page.
This script builds postfix with support for Dovecot SASL but does notI also noted the following from the postfix.SlackBuild file itself.
include any support for Cyrus-SASL. If you need to enable support for
Cyrus see SASL_README in the source code.
# Postfix unfortunately does not use a handy ./configure script so you # must generate the makefiles using (what else?) "make makefiles". The # following includes support for TLS and SASL. It should automatically # find PCRE and DB3 support. The docs have information for adding # additional support such as MySQL or LDAP.I changed the "make makefile" lines from:
make makefiles \ CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DUSE_TLS' \ AUXLIBS="-lssl -lcrypto"to:
make makefiles CCARGS="-DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DHAS_PCRE \
-I/usr/local/include/sasl -I/usr/include" \
AUXLIBS="-L/usr/local/lib -lsasl2 -L/usr/lib -lpcre"This added Cyrus-SASL support and also fixed a problem I was having with it finding PCRE. I also changed the VERSION variable to 2.6.8 since the postfix.SlackBuild file was for 2.6.1. After the changes, all I have to do is run the postfix.SlackBuild file then use "upgradepkg" on the resulting postfix-2.6.8-iX86-1_SBo.tgz package. (Note that official packages use xz for compression now, not gzip, so they will have the extension txz).The next package I will create using SlackBuilds is cyrus-imapd since it also is not included in Slackware. Cyrus-SASL actually has an official package, but I I've been running Cyrus for so long that I have always installed it from source. I don't remember if that is because it wasn't available as a package back in the day or just because I was using some non-standard options.
Posted by
Nathaniel Richmond
at
21:30
0
comments
Labels: linux, slackware, system administration
14 March, 2010
March Slackware-current: libblkid.so.1
The Slackware-current updates from March 1, 2010, included updates to both the e2fsprogs package and the util-linux-ng package. An important thing to note is that libblkid was moved out of e2fsprogs and into util-linux-ng. If you search the web for libblkid.so.1, slackpkg, util-linux-ng, and e2fsprogs, you will see various forum posts about not being able to boot. This is because libblkid.so.1 is required to mount and the updates included a new kernel, which meant a lot of people updated then rebooted without having util-linux-ng installed. Booting without the library will get you error messages about libblkid.so.1 not being found when the system tries to mount the drives.
$ man libblkid LIBBLKID(3) LIBBLKID(3) NAME libblkid - block device identification library SYNOPSIS #includeIf you don't already have util-linux-ng installed then make sure to install it before rebooting since the update to e2fsprogs will remove libblkid.cc file.c -lblkid DESCRIPTION The libblkid library is used to identify block devices (disks) as to their content (e.g. filesystem type) as well as extracting additional information such as filesystem labels/volume names, unique identi- fiers/serial numbers, etc.
$ sudo slackpkg update ---snip--- $ sudo slackpkg install util-linux-ng ---snip--- $ sudo slackpkg install-new ---snip--- $ sudo slackpkg upgrade-allIf you get stuck because you ran upgrade-all, don't have util-linux-ng installed, then rebooted for the kernel update, you can boot to the Slackware install CD or DVD so you can install the old version of e2fsprogs or the new util-linux-ng. This will allow you to boot normally then fix whatever is needed, such as installing the new util-linux-ng and/or upgrading e2fsprogs.
Posted by
Nathaniel Richmond
at
14:37
Labels: linux, slackware, system administration
13 March, 2010
Customizing Slackware Tcl Package for Sguil
Most distributions these days are configuring their Tcl packages with --enable-threads as a default. Slackware-current switched some months back with the following in the ChangeLog.txt.
+--------------------------+ Mon Dec 7 02:13:13 UTC 2009 d/ruby-1.9.1_p243-i486-3.txz: Rebuilt. Added an explicit --enable-pthread. This is mostly to make sure that we get the expected option set from future releases of Ruby -- it appears that not only is --enable-pthread the default in ruby-1.9.1, but trying to use --disable-pthread doesn't work. Furthermore, Ruby and Tcl/Tk no longer work together unless both Ruby and Tcl/Tk are compiled with thread support. Compiling Tcl/Tk with thread support has caused some problems in the past. If a threaded Tcl app tries to fork(), it will hang, but by now most affected Tcl apps (such as eggdrop) should have patches available. Anyway, this should fix the issues with Ruby and Tk. Please test it, and report any other problems that arise. tcl/tcl-8.5.8-i486-1.txz: Upgraded. Compiled using --enable-threads, since Ruby requires it to work with Tk. tcl/tclx-8.4-i486-3.txz: Rebuilt. Recompiled using --enable-threads. tcl/tix-8.4.3-i486-2.txz: Rebuilt. Recompiled using --enable-threads. tcl/tk-8.5.8-i486-1.txz: Upgraded. Compiled using --enable-threads, since Ruby requires it to work with Tk.
+--------------------------+The Sguil daemon will not work with threaded Tcl, so to fix this you need to build a package for the distribution of your choice with the --disable-threads configure option. In Slackware and most other distributions, it is fairly simple to customize a package.
Download Tcl from the source directory on the Slackware mirror of your choice. It should include a slack-desc file, a tcl.SlackBuild file, and the Tcl source. Modify the tcl.SlackBuild file to replace --enable-threads with --disable-threads.
./configure \
--prefix=/usr \
--libdir=/usr/lib${LIBDIRSUFFIX} \
--enable-shared \
--disable-threads \
--enable-man-symlinks \
--enable-man-compression=gzip \
${CONFARGS} \
--build=$ARCH-slackware-linuxYou may also want to modify the slack-desc to note that this is a non-threaded version. Then build the new package.$ sh tcl.SlackBuild ---snip--- Slackware package /tmp/tcl-8.5.8-i486-1.txz created.As you see, the package will get written to /tmp by default. Now replace the threaded version with the new non-threaded version.
$ sudo upgradepkg --reinstall /tmp/tcl-8.5.8-i486-1.txz +============================================================================== | Upgrading tcl-8.5.8-i486-1 package using /tmp/tcl-8.5.8-i486-1.txz +============================================================================== Pre-installing package tcl-8.5.8-i486-1... Removing package /var/log/packages/tcl-8.5.8-i486-1-upgraded-2010-03-13,20:03:22... Verifying package tcl-8.5.8-i486-1.txz. Installing package tcl-8.5.8-i486-1.txz: PACKAGE DESCRIPTION: # tcl (Tool Command Language) # # Tcl, developed by Dr. John Ousterhout, is a simple to use text-based # script language with many built-in features which make it especially # nice for writing interactive scripts. # # This is a version customized by nr that uses --disable-threads. # Executing install script for tcl-8.5.8-i486-1.txz. Package tcl-8.5.8-i486-1.txz installed. Package tcl-8.5.8-i486-1 upgraded with new package /tmp/tcl-8.5.8-i486-1.txz.
Posted by
Nathaniel Richmond
at
15:11
0
comments
Labels: linux, sguil, slackware, system administration
