Loading the Atheros 5xxx drivers

The first, most logical step, was to make the Linux based PC into an AP. Keep in mind, I actually have two EnGenuis PCI wireless cards in the system. One will be used to build our AP, and the other for detection of layer 2 attacks (rogue access points, spoofed AP's, etc). Before we can get to that point, we need to load the appropriate drivers for these cards. On my soon-to-be wireless IDS system, a 'lspci' showed:

01:01.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01) 01:02.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)

The kernel I'll be using on my Linux based IDS/IPS system is the Gentoo 2.6.35-r2 hardened ebuild. We typically build our field IDS/IPS systems with harden kernels, so I decided it would be best to do the same with my PoC system. This means that pax/grsec is enabled and working. The idea is that this is a 'security' device, so any assistance in thwarting attacks can help.

The 2.6.35-r2 kernel has "Atheros 5xxx wireless card support", and this is what we'll be using. Below are the device/wireless kernel configurations I used.

Device Drivers ---> [*] Network device support ---> [*] Wireless LAN ---> < M > Atheros Wireless Cards ---> < M > Atheros 5xxx wireless cards support [*] Atheros 5xxx debugging

You'll probably want to install the wireless tools. This will give you commands like 'iwconfig', which may be needed for debugging. On my Gentoo based system, I simply typed:

# emerge wireless-tools

Check your distribution for the wireless tools. They'll likely be avaliable. Once your kernel has been compiled, you can load the Atheros 5k drivers by typing:

# modprobe ath5k

Check 'dmesg' for any errors. Make sure the module sees both wireless cards. Your 'dmesg' should look something like this, if completed successfully:

ath5k 0000:01:01.0: PCI->APIC IRQ transform: INT A -> IRQ 22 ath5k 0000:01:01.0: registered as 'phy0' ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45) ath5k 0000:01:02.0: PCI->APIC IRQ transform: INT A -> IRQ 17 ath5k 0000:01:02.0: registered as 'phy1' ath5k phy1: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)

Buiding the AP

For the AP, we'll be using 'hostap'. The idea is to use one of our two wireless cards and switch it from a 'client' [Managed] mode, to 'AP' [Master] mode. This turns the computer into a wireless router. The card I'll be using is the first card (device: wlan0). Remember, we'll be using the second Atheros card for other purposes. I'm using hostapd version 6.9 for stability reasons. In the Gentoo world, to install hostapd, we would type:

# emerge hostapd

Check your distribution for information about possible hostapd packages.

Many people who use hostapd build a network 'bridge' between the wireless card and their internal network card. I will not be running hostapd in 'bridge' mode, but rather in NAT mode. This means I'll be assigning my AP card (wlan0) an IP address.

# ifconfig wlan0 10.220.0.1 netmask 255.255.255.0 # My home network

I'll be using this AP just as I would any other one. This means that WPA2 encryption is a must. In this case, I'll be using a pre-shared key. Your configuration may differ, so alter as you see fit. This is simply a 'base' configuration for you to start off with. In my case, the hostapd.conf file is stored in the /etc/hostapd/hostapd.conf.

interface=wlan0 # Our first Atheros card driver=driver=nl80211 # Kernel level driver we're using logger_syslog=-1 # This will be useful later! logger_syslog_level=2 # ^^ for Sagan! logger_stdout=-1 logger_stdout_level=2 dump_file=/tmp/hostapd.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=secure # Your network SSID (name) hw_mode=g # We'll restrict to wireless G mode only channel=6 # On channel 6 beacon_int=100 dtim_period=2 max_num_sta=255 rts_threshold=2347 fragm_threshold=2346 macaddr_acl=0 auth_algs=1 ignore_broadcast_ssid=0 wpa=2 # Security settings (WPA encryption enabled) wpa_passphrase=mysecretkey # Replace with your secret key! wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP

To start up hostapd.conf in 'debug' mode, simply type:

# hostapd -dd /etc/hostapd/hostapd.conf

Note: You might be wondering why we're not manually putting 'wlan0' in 'Master' mode with 'iwconfig'. You can do this, but 'hostapd' automatically does this at startup.

This will cause hostapd to run in the foreground, which can be useful for debugging. Without the '-dd' options, hostapd will become a system daemon (background). Since we're trying to build this system as a 'real access' point, you'll probably want to run DHCP services on the AP/wireless card (wlan0). If you're using the ISC (Internet Systems Consortium) DHCP server, you would configure the DHCP server just as you would any other. Here's a short example configuration:

# Set to your domain name. option domain-name "quadrantsec.com"; # I typically run a caching DNS server on the local system. option domain-name-servers 10.220.0.1; default-lease-time 600; max-lease-time 7200; ddns-update-style ad-hoc; log-facility local7; subnet 10.220.0.0 netmask 255.255.255.0 { range 10.220.0.240 10.220.0.254; option routers 10.220.0.1; }

Start your DHCP server and test. From another machine equipped with wirelss networking, you should see the SSID 'secure'. You should also be able to get a DHCP lease from your new DHCP server. Once the AP is deemed "operational", tweak your firewall settings and NAT to how you like them. That's outside of the scope of this document, so lets continue forward.

Back hall communications

Since we're attempting to build a Wireless IDS system we'll need to build a secure means to communicate with our back end server(s). This is ultimately where all our IDS/IPS alert information will end up and where we'll have a unified console to tie everything together. We could just send the data across the Internet to our back end unencrypted, but that would be a bad thing. Even though this is a PoC idea, we might as well do it right.

For the back end communications, at Quadrant Information Security. we utilize OpenVPN quite a bit. It's pretty simple to setup, and will give us an encrypted layer to transport our IDS events.

To build from source, simply go to http://openvpn.net and follow the instructions. If you're doing this on a Linux platform, odds are your distribution has a repository/build for OpenVPN. On a Gentoo system, you would simply type:

$ sudo emerge openvpn

For Ubuntu, you'd type:

$ sudo apt-get install openvpn

Configuration of OpenVPN is pretty straightforward, but I'll go over the basics of my PoC install. OpenVPN will be operating in a client/server model. That is, the clients will be our remote wireless IDS systems and they'll connect to our server, which is our event data storage/correlation back end. We'll basically be building a "point-to-point" VPN (encrypted) tunnel for our IDS data to flow to.

To start off, I'm going to create an OpenVPN configuration file on the "server" side.

############################################################################## # "Server" side OpenVPN configuration. Remember, OpenVPN uses the tap/tun # # device. This means you'll need to have tap/tun support in your kernel! # ############################################################################## # dev tun # # Local side is 1.1.2.70, remote will be 1.1.2.80 # ifconfig 1.1.2.70 1.1.2.80 # # The pre-shared "key" we'll use for encryption. # secret /etc/openvpn/wireless-ids.key # # The UDP port to listen on. OpenVPN uses UDP by default, we're going # keep it that way. # port 2600 # # Privilege separation. # user nobody group nobody # When the tunnel is considered "down".... ping 15 ping-restart 45 ping-timer-rem persist-tun persist-key verb 3 # persist-tun persist-key verb 3

The client side is somewhat similar, with a few things switched around and added.

############################################################################## # "Client" side of the connection. This configuration file would be used on # # the "remote" wireless IDS systems. # ############################################################################## # dev tun # # Local side is 1.1.2.80, remote will be 1.1.2.70 # Note: It is reverse from the server side. # ifconfig 1.1.2.80 1.1.2.70 # # The pre-shared "key" we'll use for encryption. # secret /etc/openvpn/wireless-ids.key # # The "target" or "server" we want to connect to. This is where the # "server" is "listening". # remote 12.145.241.1 # # The remote "target" or "server" port we want to connect to (via # UDP). # port 2600 # # Privilege separation. # user nobody group nobody # # When the tunnel is considered "down".... ping 15 ping-restart 45 ping-timer-rem persist-tun persist-key verb 3

Once the configuration files are in place, you'll need to generate a pre-shared key for OpenVPN to use. This key will go on both the client and the server. Keep in mind, it is a "secret" pre-shared key, so you'll want to transport the key over some sort of "secure" medium (For example, OpenSSH). To generate the key, type:

# openvpn --genkey --secret wireless-ids.key

Verify that both sides have a copy of the key, and test the connection. To test on both sides, type:

# openvpn --config /etc/openvpn/wireless-ids.conf

With any luck, you'll see something like the below:

Sun Sep 26 15:18:06 2010 Re-using pre-shared static key Sun Sep 26 15:18:06 2010 Preserving previous TUN/TAP instance: tun1 Sun Sep 26 15:18:06 2010 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ] Sun Sep 26 15:18:06 2010 Local Options hash (VER=V4): '034192ac' Sun Sep 26 15:18:06 2010 Expected Remote Options hash (VER=V4): 'a0e614ba' Sun Sep 26 15:18:06 2010 Socket Buffers: R=[114688->131072] S=[114688->131072] Sun Sep 26 15:18:06 2010 UDPv4 link local (bound): [undef]:2600 Sun Sep 26 15:18:06 2010 UDPv4 link remote: 12.145.241.1:2600 Sun Sep 26 15:18:16 2010 Peer Connection Initiated with 12.145.241.1:2600 Sun Sep 26 15:18:17 2010 Initialization Sequence Completed

To further verify, "ping" across the OpenVPN tunnel. The "server" side will be assigned the TCP/IP address 1.1.2.70. The client side will be assigned 1.1.2.80. If you can successfully "ping" across the OpenVPN connection, we have a secure means to transport our wireless IDS data. Also, after testing the link, you'll probably want to run OpenVPN in a "daemon" mode (background). To do this, simply append the "--daemon" flag. You might want to consider adding this to your startup in case either side gets rebooted. This way, the OpenVPN tunnel will automatically be established.

You might be curious about the IP structure we're using in the PoC wireless IDS system. Why didn't we use RFC1918 style addresses? We actually avoid RFC1918 addresses (for example, 192.168.0.0/24) because we don't know what type of networks these sensors might be installed in. It's likely that the remote wireless IDS system might be installed in a network already using RFC1918 addressing. This could potentially interfere with our wireless IDS system routing. With this in mind, we create a "point-to-point" tunnel using non-RFC1918 addresses to avoid any future conflicts. Remember, this is a point-to-point tunnel, so only two IP addresses are being used. Odds are in our favor that we won't be taking any "important" addresses.

Snort'ing the interface(s)

One part of our wireless IDS system will be used to monitor for attacks from within our network at the packet level. To do this, we'll be using a software from Sourcefire known as Snort. The very basic idea behind Snort is that it monitors traffic on a network interface for security related events. For example, Snort might monitor the network for possible exploit attempts or people probing the network (nmap, etc) for information. Snort accomplishes this by using rule sets. When the rule sets match a 'bad' thing, Snort is able to send an 'alert' letting the administrators know that a possible attack is under way. At Quadrant we've used Snort for quite a while and have become fans of it. In many cases, we use Snort as our IDS/IPS engine. If you don't have experience with Snort and you're in the security field, I highly recommend checking it out.

For the purpose of this article, I'll be giving the basic overview of how we'll be using Snort for our wireless IDS system. Actually, I'm going to be configuring Snort to operate on more than just the wireless interface. My PoC wireless IDS system has the wireless network cards but is also connected to the Internet on a wired interface know as "eth1". So, for better protection of the network and the machines it controls, I'll be running Snort on the Internet facing network device (eth1) and on the wireless AP device (wlan0). On the Internet-facing side, we'll monitor for external attacks to our wireless IDS sensor. On the wireless LAN/AP side, we'll monitor for internally based attacks. The Internet facing "sensor" (Snort) will be known as "wireless-internet" (sensor id [sid]: # 1 on device eth1). The internal wireless LAN's "sensor" (Snort) will be known as "wireless-internal" (sensor id: # 2 on device wlan0).

While Snort will alert us when suspicious activity or attacks happen from within or externally from our wireless IDS system, we'll be running a firewall on both interfaces to hopefully slow or prevent the attack from being successful. The firewall configuration will largely depend on the type of installation you want to do. For example, it may be desired to egress firewall on the wireless/AP (wlan0) devices. Configuring firewalls with Linux has been a topic that's largely documented and outside of the scope of this document. I'll let you determine how you want to handle traffic on you wireless IDS system.

I typically build Snort directly from source. I find that many distributions typically ship older version of Snort, or distribute it with options I don't like. If you're not comfortable building Snort from source, check your distribution's repository. You might have better luck than me and be able to use a pre-built package of Snort. The Sourcefire team, the makers of Snort, also release pre-built packages of Snort that might be useful to you. To get the latest version of Snort, point your browser to:

http://www.snort.org/snort-downloads

As of this writing, Snort version 2.8.6.1 is the 'latest'. I'll be using this version as the base of my wireless IDS system. By the time you read this, this may be considered an older version of Snort. While that may be the case, the premise of the article should stand. Simply use the latest version of Snort.

Below is my "./configure" flags I use to build Snort.

./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-shared --disable-static --enable-dynamicplugin --disable-ipv6 --disable-gre --disable-mpls --enable-targetbased --enable-decoder-preprocessor-rules --disable-ppm --disable-timestats --enable-perfprofiling --disable-linux-smp-stats --enable-inline --enable-inline-init-failopen --disable-prelude --disable-debug --enable-reload --enable-reload-error-restart --disable-flexresp --enable-flexresp2 --disable-react --disable-aruba --enable-zlib --without-mysql --without-odbc --without-postgresql --disable-build-dynamic-examples --disable-corefiles --disable-ipfw --disable-profile --disable-ppm-test --without-oracle --enable-pthread --with-libipq-includes=/usr/include/libipq

You might notice that I've disabled all SQL database support. This might seem incorrect, but it's actually just what I want. We'll get to that a bit later in the 'Barnyard' configuration section of this paper. I also enabled options like 'inline' with Snort, in the event I wish to turn our IDS system into an IPS (Intrusion Prevention System). For the time being, we're only concentrating on IDS, but having the ability to go full IPS in the future is a nice option to have.

You'll also want to create the user 'snort' on your system. While we will start Snort as the user 'root', when Snort finishes initializing, we'll want it to drop its privileges and 'become' the user name 'snort'. We do this for security reasons (ie - privilege separation). On most modern systems, when you add the 'snort' user, the account is 'disabled'. That is, it hasn't been assigned a password and thus can't be logged into. I typically like to keep it that way.

For Snort rule sets, I'll be using the Sourcefire Snort rules and Emerging threats rules. You'll need to download those and put them in the /etc/snort directory. If you wish to put your rules in another directory, don't forget to change the "RULE_PATH" in the configuration files.

The first interface we'll tackle is the Internet facing one (eth1). This is the Interface that connects our wireless AP/IDS system to the Internet. Here's my base configuration file used for that externally facing, Internet connected interface.

############################################################################ # Snort configuration for the Internet facing side of our Wireless IDS/IPS # # sensor. # ############################################################################ var HOME_NET [YOURIPADDRESS/32] # Public IP address (Internet) var EXTERNAL_NET !$HOME_NET var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var SSH_PORTS 22 portvar HTTP_PORTS [80,2301,3128,7777,7779,8000,8008,8028,8080,8180,8888,9999] # SMTP and HTTP trigger many false positive "shell code" alerts. Ignore these # ports. portvar SHELLCODE_PORTS [!25,!80] # Not running any Oracle servers, but some emerging rules (exploit) make # reference to this variable. portvar ORACLE_PORTS 1521 var AIM_SERVERS [64.12.24.0/23,64.12.28.0/23,64.12.161.0/24,64.12.163.0/24, 64.12.200.0/24,205.188.3.0/24,205.188.5.0/24,205.188.7.0/24,205.188.9.0/24, 205.188.153.0/24,205.188.179.0/24,205.188.248.0/24] var RULE_PATH /etc/snort var SO_RULE_PATH /etc/snort/so_rules var PREPROC_RULE_PATH /etc/snort/preproc_rules # Reduce the noise. config disable_decode_alerts config disable_tcpopt_experimental_alerts config disable_tcpopt_obsolete_alerts config disable_tcpopt_ttcp_alerts config disable_tcpopt_alerts config disable_ipopt_alerts config checksum_mode: none # Ignore the OpenVPN UDP port. config ignore_ports: udp 2600 config pcre_match_limit: 1500 config pcre_match_limit_recursion: 1500 config detection: search-method ac-bnfa max_queue_events 5 config event_queue: max_queue 8 log 3 order_events content_length # Where to find dynamic preprocessors, libraries, etc. dynamicpreprocessor directory /usr/lib/snort_dynamicpreprocessor/ dynamicengine /usr/lib/snort_dynamicengine/libsf_engine.so dynamicdetection directory /usr/lib/snort_dynamicrules preprocessor frag3_global: max_frags 65536 preprocessor frag3_engine: policy windows timeout 180 preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no preprocessor stream5_tcp: policy windows, use_static_footprint_sizes, ports client 21 22 23 25 42 53 79 80 109 110 111 113 119 135 136 137 139 143 110 111 161 445 513 514 691 1433 1521 2100 2301 3128 3306 6665 6666 6667 6668 6669 7000 8000 8080 8180 8888 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779, ports both 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 preprocessor perfmonitor: time 300 file /var/snort/snort.stats pktcnt 10000 # We don't run any internal web servers that are connectable via the # Internet. However, we'll leave this preprocesssor enabled. # preprocessor http_inspect: global iis_unicode_map unicode.map 1252 preprocessor http_inspect_server: server default \ apache_whitespace no \ ascii no \ bare_byte no \ chunk_length 500000 \ flow_depth 1460 \ directory no \ double_decode no \ iis_backslash no \ iis_delimiter no \ iis_unicode no \ multi_slash no \ non_strict \ oversize_dir_length 2048 \ ports { 80 2301 3128 7777 7779 8000 8008 8028 8080 8180 8888 9999 } \ u_encode yes \ non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \ webroot no preprocessor rpc_decode: 111 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779 no_alert_multiple_requests no_alert_large_fragments no_alert_incomplete preprocessor bo preprocessor ftp_telnet: global encrypted_traffic yes check_encrypted inspection_type stateful preprocessor ftp_telnet_protocol: telnet \ ayt_attack_thresh 20 \ normalize ports { 23 } \ detect_anomalies preprocessor ftp_telnet_protocol: ftp server default \ def_max_param_len 100 \ ports { 21 2100 } \ ftp_cmds { USER PASS ACCT CWD SDUP SMNT QUIT REIN PORT PASV TYPE STRU MODE } \ ftp_cmds { RETR STOR STOU APPE ALLO REST RNFR RNTO ABOR DELE RMD MKD PWD } \ ftp_cmds { LIST NLST SITE SYST STAT HELP NOOP } \ ftp_cmds { AUTH ADAT PROT PBSZ CONF ENC } \ ftp_cmds { FEAT OPTS CEL CMD MACB } \ ftp_cmds { MDTM REST SIZE MLST MLSD } \ ftp_cmds { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ alt_max_param_len 0 { CDUP QUIT REIN PASV STOU ABOR PWD SYST NOOP } \ alt_max_param_len 100 { MDTM CEL XCWD SITE USER PASS REST DELE RMD SYST TEST STAT MACB EPSV CLNT LPRT } \ alt_max_param_len 200 { XMKD NLST ALLO STOU APPE RETR STOR CMD RNFR HELP } \ alt_max_param_len 256 { RNTO CWD } \ alt_max_param_len 400 { PORT } \ alt_max_param_len 512 { SIZE } \ chk_str_fmt { USER PASS ACCT CWD SDUP SMNT PORT TYPE STRU MODE } \ chk_str_fmt { RETR STOR STOU APPE ALLO REST RNFR RNTO DELE RMD MKD } \ chk_str_fmt { LIST NLST SITE SYST STAT HELP } \ chk_str_fmt { AUTH ADAT PROT PBSZ CONF ENC } \ chk_str_fmt { FEAT OPTS CEL CMD } \ chk_str_fmt { MDTM REST SIZE MLST MLSD } \ chk_str_fmt { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ cmd_validity MODE < char ASBCZ > \ cmd_validity STRU < char FRP > \ cmd_validity ALLO < int [ char R int ] > \ cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } > \ cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string > \ cmd_validity PORT < host_port > preprocessor ftp_telnet_protocol: ftp client default \ max_resp_len 256 \ bounce yes \ telnet_cmds no preprocessor smtp: ports { 25 587 691 } \ inspection_type stateful \ normalize cmds \ normalize_cmds { EXPN VRFY RCPT } \ alt_max_command_line_len 260 { MAIL } \ alt_max_command_line_len 300 { RCPT } \ alt_max_command_line_len 500 { HELP HELO ETRN } \ alt_max_command_line_len 255 { EXPN VRFY } preprocessor ssh: server_ports { 22 } \ max_client_bytes 19600 \ max_encrypted_packets 20 \ enable_respoverflow enable_ssh1crc32 \ enable_srvoverflow enable_protomismatch preprocessor dcerpc2: memcap 102400, events [co ] preprocessor dcerpc2_server: default, policy WinXP, \ detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \ autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \ smb_max_chain 3 preprocessor dns: ports { 53 } enable_rdata_overflow preprocessor ssl: ports { 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 }, trustservers, noinspect_encrypted # Output formats. We'll be using 'unified2' for back end logging to our # SQL database. Syslog and tcpdump I'm simply using as fall back recording # methods. output alert_syslog: LOG_AUTH LOG_ALERT output log_tcpdump: tcpdump.eth1.log output unified2: filename snort.eth1.log, limit 128 ############################################################################## # Rule loading. ############################################################################## include classification.config include reference.config include $PREPROC_RULE_PATH/preprocessor.rules include $PREPROC_RULE_PATH/decoder.rules include $SO_RULE_PATH/bad-traffic.rules include $SO_RULE_PATH/dos.rules include $SO_RULE_PATH/exploit.rules include $RULE_PATH/threshold.conf include $RULE_PATH/attack-responses.rules include $RULE_PATH/backdoor.rules include $RULE_PATH/bad-traffic.rules include $RULE_PATH/blacklist.rules include $RULE_PATH/botnet-cnc.rules include $RULE_PATH/ddos.rules include $RULE_PATH/emerging-attack_response.rules include $RULE_PATH/emerging-botcc.rules include $RULE_PATH/emerging-compromised.rules include $RULE_PATH/emerging-current_events.rules include $RULE_PATH/emerging-drop.rules include $RULE_PATH/emerging-dshield.rules include $RULE_PATH/emerging-exploit.rules include $RULE_PATH/emerging-misc.rules include $RULE_PATH/emerging-rbn.rules include $RULE_PATH/emerging-scan.rules include $RULE_PATH/emerging-shellcode.rules include $RULE_PATH/emerging-tor.rules include $RULE_PATH/emerging-trojan.rules include $RULE_PATH/exploit.rules include $RULE_PATH/scan.rules include $RULE_PATH/shellcode.rules include $RULE_PATH/specific-threats.rules

For the external interface, I'm not going to load very many rules. We have some general rules loaded to detect certain things, but the fact is, my wireless IDS system is not going to be running many services that will be connectable from the outside. Let me rephrase that. My wireless IDS system will not be running any publicly connectable services on the Internet facing interface. Period. With proper firewalling in place and not running un-needed services, this dramatically reduces our threat level and hence reduces the number of rules I'll be using on this interface.

Think of it this way. I'm not, and will never be running a service on the wireless IDS system that requires "Coldfusion" support. It will never be protecting anything that requires Coldfusion support. Therefore, there's not much of a reason to load the "web-coldfusion.rules" rule set!

The 'wireless' interface (wlan0) is a bit different. I will be monitoring that interface for everything from attacks to malware. Anything in our wireless network, I'm going to consider potentially hostile. The interface configuration is pretty similar, but with different network definitions and more rules loaded.

############################################################################ # Internal network/wireless side of our network. This will ultimately # operating on our wlan0 devices (Atheros wireless card) ############################################################################ var HOME_NET [10.220.0.0/24] # My home network. Alter to yours! var EXTERNAL_NET !$HOME_NET var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var SSH_PORTS 22 portvar HTTP_PORTS [80,2301,3128,7777,7779,8000,8008,8028,8080,8180,8888,9999] # SMTP and HTTP trigger many false positive "shell code" alerts. Ignore these # ports. portvar SHELLCODE_PORTS [!25,!80] # Not running any Oracle servers, but some emerging rules (exploit) make # reference to this variable. portvar ORACLE_PORTS 1521 var AIM_SERVERS [64.12.24.0/23,64.12.28.0/23,64.12.161.0/24,64.12.163.0/24, 64.12.200.0/24,205.188.3.0/24,205.188.5.0/24,205.188.7.0/24,205.188.9.0/24, 205.188.153.0/24,205.188.179.0/24,205.188.248.0/24] var RULE_PATH /etc/snort var SO_RULE_PATH /etc/snort/so_rules var PREPROC_RULE_PATH /etc/snort/preproc_rules # Reduce the noise. config disable_decode_alerts config disable_tcpopt_experimental_alerts config disable_tcpopt_obsolete_alerts config disable_tcpopt_ttcp_alerts config disable_tcpopt_alerts config disable_ipopt_alerts config checksum_mode: none config pcre_match_limit: 1500 config pcre_match_limit_recursion: 1500 config detection: search-method ac-bnfa max_queue_events 5 config event_queue: max_queue 8 log 3 order_events content_length # Where to find dynamic preprocessors, libraries, etc. dynamicpreprocessor directory /usr/lib/snort_dynamicpreprocessor/ dynamicengine /usr/lib/snort_dynamicengine/libsf_engine.so dynamicdetection directory /usr/lib/snort_dynamicrules preprocessor frag3_global: max_frags 65536 preprocessor frag3_engine: policy windows timeout 180 preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no preprocessor stream5_tcp: policy windows, use_static_footprint_sizes, ports client 21 22 23 25 42 53 79 80 109 110 111 113 119 135 136 137 139 143 110 111 161 445 513 514 691 1433 1521 2100 2301 3128 3306 6665 6666 6667 6668 6669 7000 8000 8080 8180 8888 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779, ports both 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 preprocessor perfmonitor: time 300 file /var/snort/snort.stats pktcnt 10000 # We don't run any internal web servers that are connectable via the # Internet. However, we'll leave this preprocesssor enabled. # preprocessor http_inspect: global iis_unicode_map unicode.map 1252 preprocessor http_inspect_server: server default \ apache_whitespace no \ ascii no \ bare_byte no \ chunk_length 500000 \ flow_depth 1460 \ directory no \ double_decode no \ iis_backslash no \ iis_delimiter no \ iis_unicode no \ multi_slash no \ non_strict \ oversize_dir_length 2048 \ ports { 80 2301 3128 7777 7779 8000 8008 8028 8080 8180 8888 9999 } \ u_encode yes \ non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \ webroot no preprocessor rpc_decode: 111 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779 no_alert_multiple_requests no_alert_large_fragments no_alert_incomplete preprocessor bo preprocessor ftp_telnet: global encrypted_traffic yes check_encrypted inspection_type stateful preprocessor ftp_telnet_protocol: telnet \ ayt_attack_thresh 20 \ normalize ports { 23 } \ detect_anomalies preprocessor ftp_telnet_protocol: ftp server default \ def_max_param_len 100 \ ports { 21 2100 } \ ftp_cmds { USER PASS ACCT CWD SDUP SMNT QUIT REIN PORT PASV TYPE STRU MODE } \ ftp_cmds { RETR STOR STOU APPE ALLO REST RNFR RNTO ABOR DELE RMD MKD PWD } \ ftp_cmds { LIST NLST SITE SYST STAT HELP NOOP } \ ftp_cmds { AUTH ADAT PROT PBSZ CONF ENC } \ ftp_cmds { FEAT OPTS CEL CMD MACB } \ ftp_cmds { MDTM REST SIZE MLST MLSD } \ ftp_cmds { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ alt_max_param_len 0 { CDUP QUIT REIN PASV STOU ABOR PWD SYST NOOP } \ alt_max_param_len 100 { MDTM CEL XCWD SITE USER PASS REST DELE RMD SYST TEST STAT MACB EPSV CLNT LPRT } \ alt_max_param_len 200 { XMKD NLST ALLO STOU APPE RETR STOR CMD RNFR HELP } \ alt_max_param_len 256 { RNTO CWD } \ alt_max_param_len 400 { PORT } \ alt_max_param_len 512 { SIZE } \ chk_str_fmt { USER PASS ACCT CWD SDUP SMNT PORT TYPE STRU MODE } \ chk_str_fmt { RETR STOR STOU APPE ALLO REST RNFR RNTO DELE RMD MKD } \ chk_str_fmt { LIST NLST SITE SYST STAT HELP } \ chk_str_fmt { AUTH ADAT PROT PBSZ CONF ENC } \ chk_str_fmt { FEAT OPTS CEL CMD } \ chk_str_fmt { MDTM REST SIZE MLST MLSD } \ chk_str_fmt { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ cmd_validity MODE < char ASBCZ > \ cmd_validity STRU < char FRP > \ cmd_validity ALLO < int [ char R int ] > \ cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } > \ cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string > \ cmd_validity PORT < host_port > preprocessor ftp_telnet_protocol: ftp client default \ max_resp_len 256 \ bounce yes \ telnet_cmds no preprocessor smtp: ports { 25 587 691 } \ inspection_type stateful \ normalize cmds \ normalize_cmds { EXPN VRFY RCPT } \ alt_max_command_line_len 260 { MAIL } \ alt_max_command_line_len 300 { RCPT } \ alt_max_command_line_len 500 { HELP HELO ETRN } \ alt_max_command_line_len 255 { EXPN VRFY } preprocessor ssh: server_ports { 22 } \ max_client_bytes 19600 \ max_encrypted_packets 20 \ enable_respoverflow enable_ssh1crc32 \ enable_srvoverflow enable_protomismatch preprocessor dcerpc2: memcap 102400, events [co ] preprocessor dcerpc2_server: default, policy WinXP, \ detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \ autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \ smb_max_chain 3 preprocessor dns: ports { 53 } enable_rdata_overflow preprocessor ssl: ports { 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 }, trustservers, noinspect_encrypted # Output formats. We'll be using 'unified2' for back end logging to our # SQL database. Syslog and tcpdump I'm simply using as fall back recording # methods. output alert_syslog: LOG_AUTH LOG_ALERT output log_tcpdump: tcpdump.wlan0.log output unified2: filename snort.wlan0.log, limit 128 ############################################################################## # Rule loading. ############################################################################## include classification.config include reference.config include $PREPROC_RULE_PATH/preprocessor.rules include $PREPROC_RULE_PATH/decoder.rules include $SO_RULE_PATH/bad-traffic.rules include $SO_RULE_PATH/dos.rules include $SO_RULE_PATH/exploit.rules include $RULE_PATH/threshold.conf include $RULE_PATH/attack-responses.rules include $RULE_PATH/backdoor.rules include $RULE_PATH/bad-traffic.rules include $RULE_PATH/blacklist.rules include $RULE_PATH/botnet-cnc.rules include $RULE_PATH/chat.rules include $RULE_PATH/content-replace.rules include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/dos.rules include $RULE_PATH/emerging-activex.rules include $RULE_PATH/emerging-attack_response.rules include $RULE_PATH/emerging-botcc.rules include $RULE_PATH/emerging-chat.rules include $RULE_PATH/emerging-compromised.rules include $RULE_PATH/emerging-current_events.rules include $RULE_PATH/emerging-dns.rules include $RULE_PATH/emerging-dos.rules include $RULE_PATH/emerging-drop.rules include $RULE_PATH/emerging-dshield.rules include $RULE_PATH/emerging-exploit.rules include $RULE_PATH/emerging-ftp.rules include $RULE_PATH/emerging-games.rules include $RULE_PATH/emerging-imap.rules include $RULE_PATH/emerging-inappropriate.rules include $RULE_PATH/emerging-malware.rules include $RULE_PATH/emerging-misc.rules include $RULE_PATH/emerging-p2p.rules include $RULE_PATH/emerging-policy.rules include $RULE_PATH/emerging-pop3.rules include $RULE_PATH/emerging-rbn.rules include $RULE_PATH/emerging-rpc.rules include $RULE_PATH/emerging-scan.rules include $RULE_PATH/emerging-shellcode.rules include $RULE_PATH/emerging-smtp.rules include $RULE_PATH/emerging-snmp.rules include $RULE_PATH/emerging-sql.rules include $RULE_PATH/emerging-telnet.rules include $RULE_PATH/emerging-tftp.rules include $RULE_PATH/emerging-tor.rules include $RULE_PATH/emerging-trojan.rules include $RULE_PATH/emerging-user_agents.rules include $RULE_PATH/emerging-virus.rules include $RULE_PATH/emerging-voip.rules include $RULE_PATH/emerging-web_client.rules include $RULE_PATH/emerging-web_server.rules include $RULE_PATH/emerging-web_specific_apps.rules include $RULE_PATH/emerging-worm.rules include $RULE_PATH/experimental.rules include $RULE_PATH/exploit.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules include $RULE_PATH/imap.rules include $RULE_PATH/info.rules include $RULE_PATH/local.rules include $RULE_PATH/misc.rules include $RULE_PATH/multimedia.rules include $RULE_PATH/mysql.rules include $RULE_PATH/netbios.rules include $RULE_PATH/nntp.rules include $RULE_PATH/oracle.rules include $RULE_PATH/other-ids.rules include $RULE_PATH/p2p.rules include $RULE_PATH/phishing-spam.rules include $RULE_PATH/policy.rules include $RULE_PATH/pop3.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/scada.rules include $RULE_PATH/scan.rules include $RULE_PATH/shellcode.rules include $RULE_PATH/smtp.rules include $RULE_PATH/snmp.rules include $RULE_PATH/specific-threats.rules include $RULE_PATH/spyware-put.rules include $RULE_PATH/sql.rules include $RULE_PATH/telnet.rules include $RULE_PATH/tftp.rules include $RULE_PATH/virus.rules include $RULE_PATH/voip.rules include $RULE_PATH/web-activex.rules include $RULE_PATH/web-attacks.rules include $RULE_PATH/web-cgi.rules include $RULE_PATH/web-client.rules include $RULE_PATH/web-coldfusion.rules include $RULE_PATH/web-frontpage.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-php.rules

As you can see, many more rules have been loaded. In reality, you could probably trim down the rule sets loaded a good bit. However, this is a PoC model, so I'm pretty much "throwing the book" at it.

To start and test your Snort configuration, simply run Snort with the appropriate flags:

# snort -i wlan0 -c /etc/snort/snort.wlan0.conf -u snort -g snort

Substitute the interface (-i wlan0) and configuration file (snort.wlan0.conf) with the appropriate settings for your setup. For this article, I'm simply giving a brief run down of my configurations. Your configuration may vary. If you have problems with Snort, Google around. There are many "HOWTO" documents related to Snort and this article isn't really geared toward a person who is completely new to Snort. Once you verified the Snort setup, you can run Snort with the same configuration options, but add a '-D' (daemonize). This will make Snort run in the background. You might want to consider adding Snort to your system's startup routine. Make sure you put it in after your wireless and hostapd are set up!

It's probably not apparent yet, but we have one more interface we'll be running Snort on. This interface will be a TAP/TUN device supplied to us by Kismet.

Kismet monitoring with Snort in the mix

"Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and (with appropriate hardware) can sniff 802.11b, 802.11a, 802.11g, and 802.11n traffic. Kismet also supports plug-ins which allow sniffing other media such as DECT. Kismet identifies networks by passively collecting packets and detecting standard named networks, detecting (and given time, decloaking) hidden networks, and inferring the presence of non-beaconing networks via data traffic." -- From the Kismet web site

Remember, we have two Atheros based cards. We're using one card (wlan0) to create our "Access Point" for internal users to connect to the network.

We're already monitoring that network interface with Snort, as well as our network interface connecting our Wireless IDS system to the Internet.

The second wireless interface (wlan1) will be our "Kismet" interface. Kismet will actually supply us with two sets of data. The first set of data supplied by Kismet is layer 2 data. That data will be Kismet scanning wireless frequencies looking for new clients, potentially hostile/rogue AP, and miscellaneous other layer 2 types of attacks.

Basically, we'll be operating Kismet in a "traditional" sense. Think of "war driving", but of course our sensor won't be moving.

Kismet also has a mechanism to supply data collected (packets), as it is channel 'hopping' to a TAP/TUN interface. Think of it this way, as Kismet hops from channel to channel, it will sometimes intercept data (TCP/IP packets). Those data packets can be read by programs like tcpdump or wireshark from the Kismet supplied TAP/TUN interface.

This TAP/TUN interface will be "monitored" by our third Snort sensor.

As of this writing, the 'latest' version of Kismet is "Kismet-2010-07-R1" and can be found at http://www.kismetwireless.net. However, we'll be using Kismet with a bit of a twist to it. In our case, we want the information that Kismet "finds" via "channel hopping" to be fed to syslog for later examination. The reason for this will become more clear later in the article, but we'll go ahead and "patch" Kismet now.

You can download the Kismet "syslog" patch from:

http://sagan.quadrantsec.com/patches/kismet-2010-07-R1-syslog-patch-r4.diff

This will only patch the "kismet_server.cc" file. Once you've downloaded Kismet-2010-07-R1 and the kismet-2010-07-R1-syslog-patch-r4.diff patch, application and configuration is pretty simple. For example:

$ tar -zxvpf kismet-2010-07-R1.tar.gz $ patch -p0 < kismet-2010-07-R1-syslog-patch-r3.diff patching file kismet-2010-07-R1/kismet_server.cc $ cd kismet-2010-07-R1 $ ./configure $ make dep $ make $ sudo make install $ sudo useradd kismet

Configuration is pretty simple for Kismet. It should be noted that we will not be using the Kismet console! We'll be using the Kismet server, and passing that information to our back end MySQL/Console system. That's not to say you can't use the Kismet console. Since the 'kismet_server' will be running on remote wireless IDS sensors, you can fire up the Kismet client/console on the sensors. What we are going for is having the 'kismet_server' report information to our back end. This means the console isn't as important to us. I'll go into my reasoning for this later in the document.

Below is my Kismet configuration (/usr/local/etc/kismet.conf).

############################################################################# # kismet.conf - Stripped down Kismet configuration file. This will be read # # by our /usr/local/bin/kismet_server # ############################################################################# version=2009-newcore servername=Kismet_2009 allowplugins=true # Our source will be our secondary Atheros wireless card [wlan1]. Remember, # our first card (wlan0) is operating as our AP. ncsource=wlan1 # Common channels, and how often to "hop" (1 channel per second) preferredchannels=1,6,11 channelvelocity=1 # Channel list supported. This must be present for Kismet to operate! channellist=IEEE80211b:1:3,6:3,11:3,2,7,3,8,4,9,5,10 channellist=IEEE80211a:36,40,44,48,52,56,60,64,149,153,157,161,165 channellist=IEEE80211ab:1:3,6:3,11:3,2,7,3,8,4,9,5,10,36,40,44,48,52,56,60,64,149,153,157,161,165 # We don't be using this, but kismet_server won't start without it. listen=tcp://127.0.0.1:2501 allowedhosts=127.0.0.1 maxbacklog=5000 # If you have Wireshark installed, you can tell Kismet to report the # manufacturer of a device based on the MAC address. You may need to # adjust this to your installation. ouifile=/usr/share/wireshark/manuf # This will be a stationary system. No need for GPS. gps=false # Kismet will supply a TAP/TUN device. We'll have our third instance of # Snort running on this interface. Make sure you name the "device" # correctly (kistap0 is probably already taken by our AP instance) tuntap_export=true tuntap_device=kistap1 # Intrusion Detection Controls. This is the backbone or our layer 2 # wireless IDS system. alert=ADHOCCONFLICT,5/min,1/sec alert=AIRJACKSSID,5/min,1/sec alert=APSPOOF,10/min,1/sec alert=BCASTDISCON,5/min,2/sec alert=BSSTIMESTAMP,5/min,1/sec alert=CHANCHANGE,5/min,1/sec alert=CRYPTODROP,5/min,1/sec alert=DISASSOCTRAFFIC,10/min,1/sec alert=DEAUTHFLOOD,5/min,2/sec alert=DEAUTHCODEINVALID,5/min,1/sec alert=DISCONCODEINVALID,5/min,1/sec alert=DHCPNAMECHANGE,5/min,1/sec alert=DHCPOSCHANGE,5/min,1/sec alert=DHCPCLIENTID,5/min,1/sec alert=DHCPCONFLICT,10/min,1/sec alert=NETSTUMBLER,5/min,1/sec alert=LUCENTTEST,5/min,1/sec alert=LONGSSID,5/min,1/sec alert=MSFBCOMSSID,5/min,1/sec alert=MSFDLINKRATE,5/min,1/sec alert=MSFNETGEARBEACON,5/min,1/sec alert=NULLPROBERESP,5/min,1/sec alert=PROBENOJOIN,5/min,1/sec # This is the SSID of our AP (wlan0; Atheros card) with that card's # MAC address. We set this to detect attackers attempting to "spoof" our # AP (hopefully). apspoof=AP:ssid="secure",validmacs="00:02:6f:89:2a:a2" # How often to write files. 0 will disable it. However, I let Kismet # write its own files. This way, I always have a "backup" method of # retrieving IDS data. writeinterval=300 # If a tree falls in the woods, and nobody is around...... enablesound=false enablespeech=false # Formats the Kismet server to "save" information. I leave this default. # (see "writeinterval" for my reasoning). logtypes=pcapdump,gpsxml,netxml,nettxt,alert pcapdumpformat=ppi # What to pre-pend file named with... logdefault=Wireless-IDS logtemplate=%p%n-%D-%t-%i.%l configdir=%h/.kismet/

Note: Be sure to change the 'apspoof' option to the MAC address of your wireless AP card (wlan0)! This way, Kismet can monitor the "out side" for possible AP spoofing attempts!

After reviewing and adjusting your configurations, you can test by firing up /usr/local/bin/kismet_server. With any luck, you'll see something like this:

(Figure 3. The 'kismet_server' running in interactive mode. MAC addresses have been obfuscated)

While the Kismet server is up and running, it might be a good time to check your syslog information. On my PoC system, you'd type, 'tail -f /var/log/messages'.

(Figure 4. Example of syslog output supplied by the 'kismet_server'. MAC addresses have been obfuscated)

You might need to check your system/distribution setup for where the syslog information gets stored.

Once you're satisfied with the Kismet server and syslog results, we can go ahead and start up the Kismet server in the background. This can be done by running the /usr/local/bin/kismet_server with the --daemonize flag. To see other kismet_server flags, pass the --help option.

With the 'kismet_server' operational, we should have a new pseudo interface named "kistap1". This interface is being supplied by Kismet, and this is the data (packet level) that's being gathered while it does its 'channel hopping'.

Note: 'mmiller' on irc.freenode.net in the #kismet channel pointed me to the Janus Project. This project makes use of multiple wifi cards to monitor all possible wireless channels. 'mmiller' pointed out that the best way to monitor the wireless data intercepted on other channels outside of my network would be to do it this way. The reasoning is that since Kismet is only intercepting data on one channel at a time, I'd be missing data on other channels. I believe he is correct, however, this ended up outside of the scope of this PoC project.

We'll be running Snort on this interface. Since it's the "channel hopping" interface, things get a little more strange. For example, we have clear needs and solutions for all of our Snort interfaces. For example, Snort is monitoring our externally facing interface for external attacks (eth1). We also monitor our internal interface with Snort for attacks and malicious traffic from within our network at the AP level (wlan0). This interface doesn't really "fit" into those categories.

So basically, this interface is going to be monitoring 'data' outside of our network. This is essentially what Google got in trouble for! If a nearby network isn't encrypted and Kismet "picks up" some of that packet data, we'll see it on our kistap1 interface. So, essentially, we're running Snort on "outside of our network" traffic. We're grabbing packets out of the air an analyzing them.

Do we need to? Probably not. Since this is a PoC design, I'm interested in seeing the data that's supplied. Some might even consider this a slippery legal issue.

In a real world design, this might be over the limit. I'll leave that to the reader. However, the beer is telling me this is a "research project", so let's continue forward.

Considering we don't really have a clear idea what type of traffic we'll be seeing on this interface, we'll use a similar Snort configuration that we used on our AP (wlan0). That is, we'll enable lots of rules and see what it picks up. Unlike previous configurations, where we had a clear definition of TCP/IP address ranges that would be in use, on this interface we do not.

The packets received by our Kismet supplied interface could be within any possible range. Some might be RFC1918, while others might not be. To get around this, we want to run Snort in an "any/any" configuration. That is, any traffic coming from/to any place needs to be examined. However, when we tell Snort to run in a "HOME_NET any" and "EXTERNAL_NET any" configuration, certain rules will complain (mostly emerging threat rules). To get around this issue, I'm creating a 'mirror' of our rules in the "/etc/snort/any" directory. Rules that complain about our 'any/any' configuration will be disabled. It's typically only a handful of rules that cause this problem. By doing it this way, we can keep our kistap1 rules separate from our "real rules".

This is basically the run-down of my Snort configuration file that we're going to be using for our kistap1 interface. Mine is stored in the /etc/snort/snort.kistap1.conf.

############################################################################ # Snort configuration for our 'channel hopping' interface supplied by # Kismet [/etc/snort/snort.kistap1.conf] ############################################################################ # This will break some rules (any/any) so be prepared to correct manually # and/or with oinkmaster/pulledpork. var HOME_NET any var EXTERNAL_NET any var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var SSH_PORTS 22 portvar HTTP_PORTS [80,2301,3128,7777,7779,8000,8008,8028,8080,8180,8888,9999] # SMTP and HTTP trigger many false positive "shell code" alerts. Ignore these # ports. portvar SHELLCODE_PORTS [!25,!80] # Not running any Oracle servers, but some emerging rules (exploit) make # reference to this variable. portvar ORACLE_PORTS 1521 var AIM_SERVERS [64.12.24.0/23,64.12.28.0/23,64.12.161.0/24,64.12.163.0/24, 64.12.200.0/24,205.188.3.0/24,205.188.5.0/24,205.188.7.0/24,205.188.9.0/24, 205.188.153.0/24,205.188.179.0/24,205.188.248.0/24] var RULE_PATH /etc/snort/any var SO_RULE_PATH /etc/snort/so_rules var PREPROC_RULE_PATH /etc/snort/preproc_rules # Reduce the noise. config disable_decode_alerts config disable_tcpopt_experimental_alerts config disable_tcpopt_obsolete_alerts config disable_tcpopt_ttcp_alerts config disable_tcpopt_alerts config disable_ipopt_alerts config checksum_mode: none config pcre_match_limit: 1500 config pcre_match_limit_recursion: 1500 config detection: search-method ac-bnfa max_queue_events 5 config event_queue: max_queue 8 log 3 order_events content_length # Where to find dynamic preprocessors, libraries, etc. dynamicpreprocessor directory /usr/lib/snort_dynamicpreprocessor/ dynamicengine /usr/lib/snort_dynamicengine/libsf_engine.so dynamicdetection directory /usr/lib/snort_dynamicrules preprocessor frag3_global: max_frags 65536 preprocessor frag3_engine: policy windows timeout 180 preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no preprocessor stream5_tcp: policy windows, use_static_footprint_sizes, ports client 21 22 23 25 42 53 79 80 109 110 111 113 119 135 136 137 139 143 110 111 161 445 513 514 691 1433 1521 2100 2301 3128 3306 6665 6666 6667 6668 6669 7000 8000 8080 8180 8888 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779, ports both 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 preprocessor perfmonitor: time 300 file /var/snort/snort.stats pktcnt 10000 # We don't run any internal web servers that are connectable via the # Internet. However, we'll leave this preprocesssor enabled. # preprocessor http_inspect: global iis_unicode_map unicode.map 1252 preprocessor http_inspect_server: server default \ apache_whitespace no \ ascii no \ bare_byte no \ chunk_length 500000 \ flow_depth 1460 \ directory no \ double_decode no \ iis_backslash no \ iis_delimiter no \ iis_unicode no \ multi_slash no \ non_strict \ oversize_dir_length 2048 \ ports { 80 2301 3128 7777 7779 8000 8008 8028 8080 8180 8888 9999 } \ u_encode yes \ non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \ webroot no preprocessor rpc_decode: 111 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779 no_alert_multiple_requests no_alert_large_fragments no_alert_incomplete preprocessor bo preprocessor ftp_telnet: global encrypted_traffic yes check_encrypted inspection_type stateful preprocessor ftp_telnet_protocol: telnet \ ayt_attack_thresh 20 \ normalize ports { 23 } \ detect_anomalies preprocessor ftp_telnet_protocol: ftp server default \ def_max_param_len 100 \ ports { 21 2100 } \ ftp_cmds { USER PASS ACCT CWD SDUP SMNT QUIT REIN PORT PASV TYPE STRU MODE } \ ftp_cmds { RETR STOR STOU APPE ALLO REST RNFR RNTO ABOR DELE RMD MKD PWD } \ ftp_cmds { LIST NLST SITE SYST STAT HELP NOOP } \ ftp_cmds { AUTH ADAT PROT PBSZ CONF ENC } \ ftp_cmds { FEAT OPTS CEL CMD MACB } \ ftp_cmds { MDTM REST SIZE MLST MLSD } \ ftp_cmds { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ alt_max_param_len 0 { CDUP QUIT REIN PASV STOU ABOR PWD SYST NOOP } \ alt_max_param_len 100 { MDTM CEL XCWD SITE USER PASS REST DELE RMD SYST TEST STAT MACB EPSV CLNT LPRT } \ alt_max_param_len 200 { XMKD NLST ALLO STOU APPE RETR STOR CMD RNFR HELP } \ alt_max_param_len 256 { RNTO CWD } \ alt_max_param_len 400 { PORT } \ alt_max_param_len 512 { SIZE } \ chk_str_fmt { USER PASS ACCT CWD SDUP SMNT PORT TYPE STRU MODE } \ chk_str_fmt { RETR STOR STOU APPE ALLO REST RNFR RNTO DELE RMD MKD } \ chk_str_fmt { LIST NLST SITE SYST STAT HELP } \ chk_str_fmt { AUTH ADAT PROT PBSZ CONF ENC } \ chk_str_fmt { FEAT OPTS CEL CMD } \ chk_str_fmt { MDTM REST SIZE MLST MLSD } \ chk_str_fmt { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ cmd_validity MODE < char ASBCZ > \ cmd_validity STRU < char FRP > \ cmd_validity ALLO < int [ char R int ] > \ cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } > \ cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string > \ cmd_validity PORT < host_port > preprocessor ftp_telnet_protocol: ftp client default \ max_resp_len 256 \ bounce yes \ telnet_cmds no preprocessor smtp: ports { 25 587 691 } \ inspection_type stateful \ normalize cmds \ normalize_cmds { EXPN VRFY RCPT } \ alt_max_command_line_len 260 { MAIL } \ alt_max_command_line_len 300 { RCPT } \ alt_max_command_line_len 500 { HELP HELO ETRN } \ alt_max_command_line_len 255 { EXPN VRFY } preprocessor ssh: server_ports { 22 } \ max_client_bytes 19600 \ max_encrypted_packets 20 \ enable_respoverflow enable_ssh1crc32 \ enable_srvoverflow enable_protomismatch preprocessor dcerpc2: memcap 102400, events [co ] preprocessor dcerpc2_server: default, policy WinXP, \ detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \ autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \ smb_max_chain 3 preprocessor dns: ports { 53 } enable_rdata_overflow preprocessor ssl: ports { 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 }, trustservers, noinspect_encrypted # Output formats. We'll be using 'unified2' for back end logging to our # SQL database. Syslog and tcpdump I'm simply using as fall back recording # methods. output alert_syslog: LOG_AUTH LOG_ALERT output log_tcpdump: tcpdump.kistap1.log output unified2: filename snort.kistap1.log, limit 128 ############################################################################## # Rule loading. ############################################################################## include classification.config include reference.config include $PREPROC_RULE_PATH/preprocessor.rules include $PREPROC_RULE_PATH/decoder.rules include $SO_RULE_PATH/bad-traffic.rules include $SO_RULE_PATH/dos.rules include $SO_RULE_PATH/exploit.rules include $RULE_PATH/threshold.conf include $RULE_PATH/attack-responses.rules include $RULE_PATH/backdoor.rules include $RULE_PATH/bad-traffic.rules include $RULE_PATH/blacklist.rules include $RULE_PATH/botnet-cnc.rules include $RULE_PATH/chat.rules include $RULE_PATH/content-replace.rules include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/dos.rules include $RULE_PATH/emerging-activex.rules include $RULE_PATH/emerging-attack_response.rules include $RULE_PATH/emerging-botcc.rules include $RULE_PATH/emerging-chat.rules include $RULE_PATH/emerging-compromised.rules include $RULE_PATH/emerging-current_events.rules include $RULE_PATH/emerging-dns.rules include $RULE_PATH/emerging-dos.rules include $RULE_PATH/emerging-drop.rules include $RULE_PATH/emerging-dshield.rules include $RULE_PATH/emerging-exploit.rules include $RULE_PATH/emerging-ftp.rules include $RULE_PATH/emerging-games.rules include $RULE_PATH/emerging-imap.rules include $RULE_PATH/emerging-inappropriate.rules include $RULE_PATH/emerging-malware.rules include $RULE_PATH/emerging-misc.rules #include $RULE_PATH/emerging-netbios.rules include $RULE_PATH/emerging-p2p.rules include $RULE_PATH/emerging-policy.rules include $RULE_PATH/emerging-pop3.rules include $RULE_PATH/emerging-rbn.rules include $RULE_PATH/emerging-rpc.rules include $RULE_PATH/emerging-scan.rules include $RULE_PATH/emerging-shellcode.rules include $RULE_PATH/emerging-smtp.rules include $RULE_PATH/emerging-snmp.rules include $RULE_PATH/emerging-sql.rules include $RULE_PATH/emerging-telnet.rules include $RULE_PATH/emerging-tftp.rules include $RULE_PATH/emerging-tor.rules include $RULE_PATH/emerging-trojan.rules include $RULE_PATH/emerging-user_agents.rules include $RULE_PATH/emerging-virus.rules include $RULE_PATH/emerging-voip.rules include $RULE_PATH/emerging-web_client.rules include $RULE_PATH/emerging-web_server.rules include $RULE_PATH/emerging-web_specific_apps.rules include $RULE_PATH/emerging-worm.rules include $RULE_PATH/experimental.rules include $RULE_PATH/exploit.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules include $RULE_PATH/imap.rules include $RULE_PATH/info.rules include $RULE_PATH/local.rules include $RULE_PATH/misc.rules include $RULE_PATH/multimedia.rules include $RULE_PATH/mysql.rules include $RULE_PATH/netbios.rules include $RULE_PATH/nntp.rules include $RULE_PATH/oracle.rules include $RULE_PATH/other-ids.rules include $RULE_PATH/p2p.rules include $RULE_PATH/phishing-spam.rules include $RULE_PATH/policy.rules include $RULE_PATH/pop3.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/scada.rules include $RULE_PATH/scan.rules include $RULE_PATH/shellcode.rules include $RULE_PATH/smtp.rules include $RULE_PATH/snmp.rules include $RULE_PATH/specific-threats.rules include $RULE_PATH/spyware-put.rules include $RULE_PATH/sql.rules include $RULE_PATH/telnet.rules include $RULE_PATH/tftp.rules include $RULE_PATH/virus.rules include $RULE_PATH/voip.rules include $RULE_PATH/web-activex.rules include $RULE_PATH/web-attacks.rules include $RULE_PATH/web-cgi.rules include $RULE_PATH/web-client.rules include $RULE_PATH/web-coldfusion.rules include $RULE_PATH/web-frontpage.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-php.rules

We can now "test" Snort by running it like our previous interfaces. Simply type:

# snort -i kistap1 -c /etc/snort/snort.kistap1.conf -u snort -g snort

If it runs successfully, consider re-running the command with the -D (daemonize) option. You'll probably want to add this to your system rc/startup routines. Remember, Kismet supplies this interface so you'll need to start Kismet first before running this instance of Snort!.

Barnyard2 configurations

You might have noticed in our Snort configurations the lack of sending data to the MySQL (in our case) back end. There's a good reason for this. We'll be using Barnyard2 to collect data from Snort and send it to our back end data collection point. In each of our Snort configuration files, we're using the "output unified2:" option. As Snort detects potentially hostile traffic, it'll log it to a file using unitied2 format. This means, Snort will record the alert and rule that was triggered, as well as the packet information (packet dump). Barnyard2's job is to "read" this file, in real time, and relay that information to our SQL back end servers. The basic idea is to separate Snort from having to deal with the logging process.

Think of it this way. Snort is monitoring a network interface in real time. If a 'bad event' happens, Snort would have to temporarily 'stop processing' network traffic to log information to the SQL database. This is not good, as we might potentially miss other hostile traffic while Snort is dealing with logging to the SQL server. To avoid this, a separate process is started (Barnyard2) that'll take information from Snort, via the unified2 output format, and INSERT it into the SQL database for Snort; thus off loading that process from Snort to Barnyard2. Since Snort doesn't need to 'concentrate' efforts on SQL logging, it can continue monitoring the network interface.

In each Snort configuration, we've told each instance of Snort to log to its own individual "unified2" file. For example:

output unified2: filename snort.eth1.log, limit 128 # Internet connection output unified2: filename snort.wlan0.log, limit 128 # AP interface output unified3: filename snort.kistap1.log, limit 128 # Hopping interface

[Note: the 'limit' option means the unifed2 file size limit. In our cases, we're setting this to 128 megabytes

Since we have a total of three instances of Snort running, we'll be running three instances of Barnyard2. Each one will read a unique Snort unifed2 formated file. Each Barnyard2 instance will log to our SQL back end as a separate "sensor id". In the Snort SQL database in the 'sensor' table, the 'sensor id' is known as the 'sid'.

Data from each specific instance of Barnyard2 will be loaded to a unique sid. In the end, this allows you to specify traffic by interface from the database. For example, in the end, you'll be able to 'view' data from the sid # 1 (Internet connection) while ignoring sid's #2 (AP) and #3 (Kismet TAP/TUN). Or you can combined all that information together, to get a complete view of all data.

Let's first do a quick overview of creating the database and tables that'll be needed on our MySQL back end server. Keep in mind, I'm using OpenVPN to create a tunnel between our satellite wireless IDS systems and the back end server. The idea is that we'll be collecting information from Snort via Barnyard2 and sending that over the OpenVPN to our MySQL server.

In our case, our satellite (wireless IDS) system has an OpenVPN tunnel address of 1.1.2.80. The peer TCP/IP address on our back end data collection point it to 1.1.2.70. Lets first do a brief overview of setting up the SQL back end server. These instructions are for MySQL, however, PostgreSQL works very well with Barynard2 too.

First, on the server back end, lets create our database and build our tables. Database schemas ship with the tarballs of Snort within the 'schemas' directory. There you'll find MySQL, MS-SQL, DB2 and MySQL schemes. In our example, we'll be using the MySQL schema.

# mysqladmin -u root -p create snort_beave # cd /home/beave/snort-2.8.6.1-build/snort-2.8.6.1/schemas # mysql -u root -p snort_beave < create_mysql

Once the database is created, we need to assign the appropriate grants/ rights to the database for the remote satellite wireless IDS systems to be able to store information.

# mysql -u root -p snort_beave mysql> grant INSERT,SELECT on snort_beave.* to snort@1.1.2.80 identified by 'mypassword'; mysql> grant INSERT,UPDATE,SELECT on snort_beave.sensor to snort@1.1.2.80 identified by 'mypassword' mysql> exit

Note: In too many cases I've seen people grant "ALL" to remote satellite IDS/IPS systems. We only want to give our IDS/IPS system the rights that it needs! Also, think of it this way, if an attacker gains access to our system and thus steals our database credentials, do we really want them to have ALL access to the back end database?

With the grants/rights in place, we can now move on to configuring Barnyard2 to read our unifed2 output from Snort and inserting data into our MySQL database. Just like Snort, where we separated configuration files via interface (ie - snort.eth1.conf, snort.wlan0.conf, snort.kistap1.conf), we'll be doing the same with Barnyard2 (barnyard.eth1.conf, barnyard.wlan0.conf, barnyard.kistap1.conf).

I'll be putting all my Barnyard2 configuration files in the /etc/barnyard2 directory. So the first interface we'll tackle is eth1, our Internet facing interface. So, our configuration file will be barnyard2.eth1.conf

############################################################################ # /etc/barnyard2/barnyard.eth1.conf - Internet facing interface. ############################################################################ config reference_file: /etc/snort/reference.config config classification_file: /etc/snort/classification.config config gen_file: /etc/snort/gen-msg.map config sid_file: /etc/snort/sid-msg.map # The 'hostname' will be directly in our console, so name it something # descriptive. config hostname: wireless-internet config interface: eth1 config set_gid: snort config set_uid: snort config waldo_file: /var/log/barnyard2/barnyard2.eth1.waldo input unified2 output database: log, mysql, user=snort password=mypassword dbname=snort_beave host=1.1.2.70, detail full

Obviously, you'll need to tweak this configuration to your environment (ie - 'mypassword').

To start Barnyard for the first time, type:

# /usr/bin/barnyard2 -c /etc/barnyard2/barnyard.eth1.conf -f snort.eth1.log -d /var/log/snort -a /var/log/snort/archive -v

You should see output similar to the below:

(Figure 5. Barnyard2 starting up. Pay attention to the 'database' information)

Other Barnyard2 configurations from the remaining interfaces will be very similar to our Internet facing side. I've including them in this document, but the changes should be pretty obvious (ie - waldo_file, hostname and interface)

############################################################################## # /etc/barnyard2/barnyard2.wlan0.conf - Internal AP/wlan0 interface. ############################################################################## config reference_file: /etc/snort/reference.config config classification_file: /etc/snort/classification.config config gen_file: /etc/snort/gen-msg.map config sid_file: /etc/snort/sid-msg.map config hostname: wireless-internal config interface: wlan0 config set_gid: snort config set_uid: snort config waldo_file: /var/log/barnyard2/barnyard2.wlan0.waldo input unified2 output database: log, mysql, user=snort password=mypassword dbname=snort_beave host=1.1.2.70, detail full

Command line to start Barnyard2:

# /usr/bin/barnyard2 -c /etc/barnyard2/barnyard.wlan0.conf -f snort.wlan0.log -d /var/log/snort -a /var/log/snort/archive -v

############################################################################## # /etc/barnyard2/barnyard2.kistap1.conf - Channel hopping interface. ############################################################################## config reference_file: /etc/snort/reference.config config classification_file: /etc/snort/classification.config config gen_file: /etc/snort/gen-msg.map config sid_file: /etc/snort/sid-msg.map config hostname: wireless-internal config interface: kistap1 config set_gid: snort config set_uid: snort config waldo_file: /var/log/barnyard2/barnyard2.kistap1.waldo input unified2 output database: log, mysql, user=snort password=mypassword dbname=snort_beave host=1.1.2.70, detail full

Command line to start Barnyard2:

# /usr/bin/barnyard2 -c /etc/barnyard2/barnyard.kistap1.conf -f snort.kistap1.log -d /var/log/snort -a /var/log/snort/archive -v

Pulling the 'kismet_server' into the mix

To veteran Kismet users, this setup is probably a bit strange. Why not just run Kismet "drones" on the remote wireless IDS systems? The "drones" can report back to a centralized server.

This idea is okay, but relies on the Kismet server to do the data interpretation of the drones. That is, if the Kismet server "dies", information from the drones is lost. Also, I still need a method to "push" information from the Kismet server to our MySQL back end. Kismet supports various log output formats, which is excellent. However, there is a lack of output formats that transport data over a network into, for example, a database format.

Another thought was to do multiple Kismet drone/servers in the field, but we end up with the same situation. That is, the lack of a network capable of transporting to our back end.

I brought this up to Dragorn on the #kismet IRC channel (irc.freenode.net). Dragorn's response was to build an application that'll query the Kismet API via the Kismet server and pull the information we need. Once the application has the information we need, we could transport it over the network however we see fit. Overall, I completely agree with Dragorn. That is a possible way to accomplish network transmission of data.

But, this misses the overall problem. Kismet, at its core, lacks any means to transport information over a network.

I had mentioned that basically what I wanted was the exact same information the Kismet console was being given, but transmitted over syslog. Dragorn opposed this idea, and again pointed me back to the Kismet API idea.

In some aspects, I completely agree with Dragorn. In actuality, I might be able to pull more information from the Kismet servers. However, this adds a bit more complexity to our wireless IDS solution. It could even be argued that it's not much more complexity at all. However, creating a syslog patch for the Kismet server was about 5 lines of C code. Granted, it's a sloppy patch, but this gives the Kismet server itself the ability to transport wireless IDS information via syslog.

Today, almost everything you put in your network has the ability to transport log information over a network. My personal belief is that it should be an option within Kismet itself. Even more so if Kismet is to be used as a serious wireless IDS system.

It's not that an application querying the Kismet API is a bad thing. Dragron pointed out that it could be done in just about any language (Perl, C, Ruby, Python, even bash). If I'd gone with the Kismet server/drone method, this might be acceptable. That's not the model I chose for reasons outlined above.

These will be field sensors. Even though this is only a PoC model, there is an assumption that these development utilities will be available. In the majority of cases for IDS/IPS systems, development tools are not likely to be present on these machines. At my place of employment, it's common not to have Perl, Ruby, GCC (C compiler), Python, etc loaded. That leaves me with one option. Bash, or shell scripting, to work with the Kismet API. That leaves a bad taste in my mouth, so I decided that would not be the way to go for me.

There is one other option. Everything we've done up to this point in our PoC can be supported by a package based system. For example, Snort, Barnyard2 and even Kismet updates or installs can be rolled out as packages. Hence, no development tools are needed on the "sensor" end of things.

I could write a custom C program that communicates with the Kismet API. I could then build that and roll it out as a package to the remote sensor. This idea I don't find so bad. Perhaps I'll come back to this some day. My patch seemed the most simple solution for my needs.

Kismet; Syslog me, baby

So far, we have almost all critical information of our wireless IDS system reporting back to a centralize MySQL database. We're missing one piece. That's the information Kismet provides about layer 2 attacks and other "networks" that "pop up" in our environment.

Again, our ultimate goal here is to build a unified console for wireless IDS. This means, that data being collected by Kismet's channel hopping/sniffing will ultimately need to be within the same database as our Snort information. From the database level, we already have 3 sensors running. They are:

Our final sensor.....

At his point, we have not configured our syslog service to transmit data to our back end. However, there is more to our syslog data than Kismet information. That is, while Kismet will be supplying us information via syslog, so will other services. For example, OpenSSH session information gets logged via syslog. Firewall information (via iptables) might get logged via syslog. It would be best to have all that data.

So really, what Sensor ID # 4 will become is a 'syslog' interface. While most of it will probably be Kismet related, it'll also have other information we might find useful on our PoC wireless IDS system.

The first step to take is to make our PoC system send its syslog information to a centralized repository. As a log is generated, I want it sent to our back end. Not for correlation, but for archival purposes. If we do this correctly, even if an attacker somehow gains access to the system and alters the logs, we'll have a known 'good' copy. The logs are sent in 'real time', so even if the attacker mangles local logs, we'll be able to review something 'clean'.

At the time of this writing, the big players in the syslog field under *nix are syslog-ng and rsyslog. Below are links to example configuration files for each. Remember, "client" means our remote satellite wireless IDS system. This system will be sending the logs to the back end for collection. The "server" is the configuration for the side that will be receiving the logs.

Syslog-ng	Client side	Server side
Rsyslog	Client side	Server side

I'm using the the Rsyslog configurations. I've been a long time Syslog-ng user, but recently switched to Rsyslog due to some features it has over Syslog-ng. For example, in our Rsyslog client side configurations, I'm sending via the more reliable TCP method rather than UDP. This helps ensure the messages reach our back end servers. Rsyslog can also 'queue' events in the event our OpenVPN connection has died. On the Rsyslog server side, I'm storing events into a SQL database. This allows me to view all events from our wireless IDS sensor in a nice graphical interface. The interface I'm using is Loganalyzer. You could easily use something like Splunk or Logzilla to view syslog events.

That's getting a bit outside the scope of this document. While access to the archival syslog information is important, what I want are the threats to be located in one console. There is also plenty of documentation and 'HOWTOs' related to projects like Rsyslog and Loganalyzer.

Enter Sagan

One thing you might have noticed in our rsyslog/syslog-ng server/client examples, is a reference to 'sagan'. Sagan is ultimately the software that will 'patch' the information supplied from our Kismet server via syslog to our back end Snort based MySQL system. To make things a bit more clear, let me explain what Sagan is and what it does.

Sagan is a real-time correlation engine. What this means is that Sagan 'reads' logs, as it receives them, and attempts to correlate the information within your Snort SQL database with the packet/IDS/IPS data based on rules. For the sake of simplicity, lets examine what Sagan does.

Lets assume, for the sake of an example, you run an SMTP server. In front of this server, you use Snort as your IDS/IPS engine. So, as traffic is flowing to and from your SMTP server, that traffic also flows through your Snort sensor. For our example, lets assume a potential attacker is probing your network. They connect to your SMTP server, and issue the SMTP command "expn root". This traffic will be "seen" by Snort and "flagged" as an "attempted recon", and sent to your SQL back end. When Snort logs its information about the 'attempted-recon', it'll record information like, packet data (dump), source TCP/IP address, destination TCP/IP address, source TCP port, destination port, timestamp, etc.

Sagan, does the exact same thing, but instead of gathering the information about the 'attempted recon' at the network/packet level, it pulls the information from the log level. When the SMTP server sends out the log (via syslog), it'll typically have much of the same information. For example, the timestamp, TCP/IP destination and source, destination port (port 25) and sometimes even the source port!

Since Sagan has a lot of the same information as Snort, we can now correlate log events with our IDS/IPS packet level events! Sort of nifty, eh?

It gets better. Sagan can not only communicate directly with our SQL back end, but also store information into our Snort SQL database. Sagan uses a very similar rule set as Snort. Why is this important? The same utilities you use for rule management with Snort work with Sagan.. There's no additional software to load, only Sagan!

Note: If you're confused about what Sagan is and/or does, you might want to check out the Sagan: Log Correlation in a 'Snort like' way video at Securitytube.net. This is a short presentation that was given for the North Florida ISSA chapter in Jacksonville, Florida about Sagan.

Sagan configuration and installation

Configuration and installation of Sagan is pretty straightforward. However, if you need more detailed information, you'll want to check out Sagan's main site and the Sagan HOWTO.

Like Snort, we'll first need to compile and install Sagan. On our wireless PoC IDS system, we'll download the latest version of Sagan. This can be obtained from http://sagan.softwink.com/download/sagan-current.tar.gz.

Once download, we'll do the following:

$ tar -zxvpf sagan-current.tar.gz $ cd sagan-0.1.7 # Or whatever version is current $ ./configure --disable-postgresql # MySQL is enabled by default $ make $ sudo make install $ sudo useradd sagan # Used for privilege separation $ sudo mkfifo /var/run/sagan.fifo # Where to receive logs from $ sudo chown sagan:sagan /var/run/sagan.fifo $ sudo chown sagan:sagan /var/log/sagan $ sudo chown sagan:sagan /var/run/sagan

Most of this should be straightforward. We want to add a user to the system "sagan", for similar reasons we add a 'snort' user. We'll be starting Sagan as 'root', but once Sagan is initialized, Sagan will 'drop' its privileges and 'become' the user 'sagan'.

This 'mkfifo' builds out FIFO (First In/First Out). This is also sometimes known as a 'named pipe'. This is where Sagan will be receiving log messages from either rsyslog or syslog-ng. Previously, in the syslog-ng and rsyslog "client" example configurations, the FIFO feature and Sagan templates were included. If you're confused, you might want to refer to them.

Note: Sagan is under constant development. If you run into a problem, report it. You might even want to check out the Sagan Git tree!

Next we'll want to pull down the latest Sagan rule set. The rule sets are very similar to Snort rule sets. They tell Sagan what to 'look' for in syslog messages. To get the latest rule set, simply do the following.

$ wget http://sagan.quadrantsec.com/rules/sagan-rules-current.tar.gz $ tar -zxvpf sagan-rules-current.tar.gz $ mv rules /usr/local/etc/sagan-rules

We can now configure Sagan. The key thing to look for is the database access ("output database:") plug in information. This tells Sagan how and what database (snort_beave) to access.

# ,-._,-. Sagan configuration file [http://sagan.quadrantsec.com] # \/)"(\/ By Champ Clark III & Quadrant InfoSec: http://www.quadrantsec.com # (_o_) Copyright (C) 2009-2010 Quadrant InfoSec., et al. # / \/) # (|| ||) # oo-oo ############################################################################## # Standard _required_ Sagan options! ############################################################################## # Sagan can read log entries via a FIFO (First In, First Out) or via # 'standard input' (stdin). If this option is _present_, then Sagan assumes # log entries will come in via a FIFO. If this option is _not_ present, then # Sagan will 'assume' log entries will come in via stdin. # # When Sagan takes input from stdin, syslog-ng calls this via the 'program' # mode/call. # # The --program flag can override this variable and force Sagan to use # stdin. # # [optional] - Depending on system configuration. var FIFO /var/run/sagan.fifo # This variable contains the path of the Sagan rule sets. It is required. var RULE_PATH /usr/local/etc/sagan-rules # Where Sagan should store it's lock file. var LOCKFILE /var/run/sagan/sagan.pid # This is for storage of Sagan runtime information. var SAGANLOG /var/log/sagan/sagan.log # Where Sagan should store alerts, in a text file format. var ALERTLOG /var/log/sagan/alert # This is the IP address _of_ the Sagan system. These options are used # if Sagan is unable to determine a TCP/IP network address and/or port. # # [Required] sagan_host 10.220.0.1 sagan_port 514 ############################################################################## # Snort database specific configurations ############################################################################## # Sagan "sensor" configuration. If you plan on running Sagan and storing data # to a Snort database, these options are required. This information gets # logged to the Snort database's "sensor" table to differentiate between Snort # IDS/IPS data and log data. We don't really have an "interface", so we create # one known as "syslog", or whatever you'd like to call it. # # [Required if logging to a Snort database] sagan_hostname wireless-sagan sagan_interface syslog sagan_filter none sagan_detail 1 # If logging to a Snort database, and the rule set specifies the protocol as # "any", this is the protocol we default to. This is only needed if you are # logging to a Snort database. # # Defaults to 17 [UDP], which is what normal 'syslog' traffic is. If you # want TCP to be the desired effect, change this option to "6". ; sagan_proto 17 # If you plan on logging to a Snort database, this is where you tell Sagan # where to log to. The options should be pretty clear. Currently Sagan # supports MySQL and PostgreSQL. The "maxdb_threads" is the maximum number of # threads that can be created. This defaults to 20. # # [Required if logging to a Snort database] maxdb_threads 50 output database: log, mysql, user=sagan password=mypassword dbname=snort_beave host=1.1.2.70 ; output database: log, postgresql, user=sagan password=secret dbname=snort_db host=192.168.0.1 ############################################################################## # External program/system calls configurations specifics ############################################################################## # This option calls an external program when an event is triggered by a rule. # Sagan basically makes a thread and calls the execl() system call. # Data is supplied to the program being called via standard in (stdin). # Data can be sent in a "parsable" or "alert" format. "parsable" will be # probably easier for your external program to parse. # # The "max_ext_threads" limits the amount of threads that can be created, # which defaults to 20. ; max_ext_threads 50 ; output external: /home/champ/stdout parsable ############################################################################## # libesmtp (SMTP/E-mail) specific configuration options ############################################################################## # If you'd like Sagan to e-mail events to you, then you want to enable this # option. The fields should be pretty self explanatory. # "max_email_threads" is the maximum number of threads that can be created # for e-mailing out events. This defaults to 20. If min_email_priority is # set, then Sagan will _only_ e-mail event equal to or less than the # minimum priority. If left commented out or set to '0', Sagan will # e-mail all events. ; max_email_threads 50 ; min_email_priority 5 ; output email: to=sagan-alerts@example.com smtpserver=192.168.0.1:25 from=sagan@example.com ############################################################################## # Logzilla (AKA : php-syslog-ng) database configuration specifics ############################################################################## # If you'd like Sagan to log information to a Logzilla database (MySQL or # PostgreSQL), then you'll need to enabled this option. The # "max_logzilla_threads" option specifies the maximum number of threads that # can be used to log to a Logzilla database. This defaults to 20. The # majority of the options should be pretty clear, but the options "full" and # "alert" have very specific functions. The "alert" option sends _only_ # Sagan triggered events to the Logzilla database. If "full" is used, then # _all_ events, triggered or not, will be sent to the Logzilla database. ; max_logzilla_threads 50 ; output logzilla: full, mysql, user=sagan password=secret dbname=syslog host=192.168.0.1 ; output logzilla: alert, postgresql, user=sagan password=secret dbname=syslog host=192.168.0.1 ############################################################################## # Sagan rule sets! Arrgh Villains! Sagan neither takes nor gives mercy! ############################################################################## # This should be enabled! "classifications.config" allows correlation between # a short name (for example, "attempted-admin") and a priority level # (for example, "1"). "reference.config" gives your various places to learn # more information pertaining to an alert. # include $RULE_PATH/classification.config include $RULE_PATH/reference.config # These are the specific rule sets of events which are of interest and require # notification. Tailor these to your specific needs and check from time to # time for new rule sets that might be of benefit. include $RULE_PATH/arp.rules include $RULE_PATH/attack.rules include $RULE_PATH/bash.rules include $RULE_PATH/bind.rules include $RULE_PATH/kismet.rules include $RULE_PATH/hostapd.rules include $RULE_PATH/ntp.rules include $RULE_PATH/openssh.rules include $RULE_PATH/squid.rules include $RULE_PATH/su.rules include $RULE_PATH/syslog.rules include $RULE_PATH/tcp.rules

If you're interested in enabling other output plug in's, it'd be best to refer to the Sagan web site.

Like Snort, Sagan rules are broken down protocols and/or programs. There are actually many more rules supplied via Sagan, but they aren't needed for this project. For example, Sagan rules ship with "proftpd.rules", but we won't be running a ProFTP server. If we enabled those rules, we would be watching for things that'll never happen on our wireless IDS system. This will simply use CPU ticks and memory. Lets break down the rule set we're using.

As you can see, we're using Sagan for a bit more than just Kismet traffic. We're also using it to keep an eye on other functions of the system.

Once Sagan is installed and configured, we'll need to give it rights to the Snort database (snort_beave). Since Sagan works similarly to Snort, give it the same rights, just with another user name ("sagan"). On our back end server, we'll do the following. This will give our satellite wireless IDS sensors access to the database.

$ mysql -u root -p snort_beave mysql> grant INSERT,SELECT on snort_beave.* to sagan@1.1.2.80 identified by 'mypassword'; mysql> grant INSERT, UPDATE, SELECT select on snort_beave.sensor to sagan@1.1.2.80 identified by 'mypassword' mysql> exit

If everything is configured properly, we can now fire up Sagan and verify things are working. To do that, simply type (as "root"):

# /usr/local/bin/sagan

You should see something similar to the below:

(Figure 6. 'Sagan' startup splash screen. I'm using the SVN version of Sagan)

(Figure 7. Hitting a key in Sagan's interactive mode will dump statistics)

Note the "Total number of events processed: ". If that remains zero after some time of operation, Sagan probably isn't seeing the events correctly.

You can further check Sagan to see if it's operating properly by examining the Sagan 'alert' log. This is normally stored in the '/var/log/sagan/alert' file. If you're a Snort user, the output in the Sagan alert file should look pretty familiar, since Sagan uses a 'Snort like' alert syntax. Examining the 'alert' file, you should see something like:

[**] [5001014] [KISMET] Detected new managed network [**] [Classification: suspicious-traffic] [Priority: 2] 2010-10-26 11:47:28 10.220.0.1:514 -> 10.220.0.1:514 user info Message: Detected new managed network "2WIRE940", BSSID 00:25:00:00:00:00, encryption yes, channel 6, 54.00 mbit [Xref => http://wiki.quadrantsec.com/bin/view/Main/5001014]

Once you're satisfied with Sagan's setup, you can tell Sagan to run in the background with the --daemon flag. To get statistics from Sagan, when running in the background, simply issue a 'killall -USR1 sagan'. Statistics will be stored in the /var/log/sagan/sagan.log file.

That's it! Final notes!

As a PoC system, we end up with a decent wireless IDS solution. Best yet, we're using nothing but open source software.

You've probably noticed that I've been dwelling on the fact that all potential attack or alert data must go to the same Snort MySQL database back end. Since we have all data in one place, we can now use the power of SQL to correlate that information. Another plus to this, we can use Snort web based front ends to examine the data. Yes, even the Kismet/syslog data!

With this mixture of software, we don't have to hunt through multiple consoles to do our job. We have one, unified console from which to view potential threats.

We can now take advantage of open source IDS consoles like BASE and Snorby. At Quadrant Information Security we use a proprietary console that queries the SQL database. Guess what. It doesn't matter. If your console, report generation utiltities, etc. can query a Snort database, they can be used with this mix! It doesn't matter, it'll always work with this solution!. Here's the short laundry list of things we've accomplished:

It wouldn't be fair to not show you the final outcome of this weekend PoC project. Below, I've included some screen shots of both BASE and Snorby working with our wireless IDS system with data supplied from both Sagan (syslog) and Snort (packet level).

BASE (Basic Analysis and Security Engine) Console

Snorby Console

Loganalyzer Console (Syslog data only)

Prelude's 'Prewikka' console. This is a new output plug in for Sagan and it based on the Prelude security frame work. Sagan & Prelude/IDMEF wasn't covered in this article but it's yet another console that is supported for our wireless IDS system.

About the author: Champ Clark III (AKA - 'Da Beave') is a security researcher & engineer at Quadrant Information Security. He's the founder of the Deathrow OpenVMS public access cluster and a founding member of the VoIP hobbyist group Telephreak. He's an author of 'Asterisk Hacking' & 'Threat Analysis 2008' by Syngress Publishing. He regularly speaks at events like Defcon, HOPE, CCC (Germany) and various other events. He's the author of iWar, a VoIP/Unix based war dialer and Sagan, the log correlation and analysis engine talked about in this article. You can sometimes reach Champ Clark (Da Beave) on irc.2600.net / #sagan. You can also follow Champ via Twitter [http://twitter.com/dabeave666] Thanks To Bruce M. Wink and Kathrin Ritter at Quadrant Information Security for helping me get this article together. All the guys in the irc.freenode.net #kismet channel. In particular, Dragorn for the development of a great wireless scanner/sniffer. Also 'mmiller' and 'Zero_Cool' for input during the writing of this article. Of course, the irc.2600.net #telephreak crew.

Other articles by Champ Clark Telco SMTP -> SMS/MMS Crypto (Telco related) Installation & Securing VoIP with Linux (VoIP related) Virtual Private Asterisk (VoIP related) Videos by Champ Clark (Defon/HOPE/etc) Hacking Internation Networks & Systems using VoIP (HOPE) Sagan - Log correlation in a Snort like way (NF ISSA) Automated Analog Telephone Logging (Defcon) PSTN based cartography (Defcon)