Multicasting Civil Warning Systems

Earlier this year at National Marathon, with 40K people were around the start at the DC armory, and the event notification system we signed up for was overwhelmed so our group text messages were getting cached and taking tens of minutes to get through to everyone. At 6:40am, the 6:00 am message that the parking was full and that parking on the streets would be allowed by DC police got through – after a HUGE traffic jam was formed and we were all ready stuck....

Despite the current implementation difficulties, the apps to actually handle this kind of messging efficiently are becoming very cool and useful – we are moving from the early goofy “flash mob” application to “Smart Mobs” with context-aware message groups [context: interests, job function, location], which are all good starts on mobile collective-intelligence applications. Can we apply this type of context-aware group messaging technology to paying customers? Could our "Geo-casting" idea be extended to this kind of situation? This certainly has great application for emergency services, civil warning systems, defense applications, etc…

Multicast DNS (mDNS) Avahi Zeroconfig not resolving .local hosts on Linux

There’s a little tweak that you need to know to get Avahi multicast DNS (mDNS) Service Discovery (DNS-SD) ( aka: Zeroconfig) to resolve .local hostnames for applications running on Linux hosts. This problem vexed me for several days so I thought I'd document it so others could save a bit of time digging into the inner workings of the Linux advanced networking features. The Avahi mdns responder responds to dns requests both external (from remote hosts) and internal from applications on the local host. However, for some reason the default nslookup file on some Linux distributions (Angstrom embedded!) has mdns lookups disabled in the host name lookup process - - meaning your applications will return "bad address" for commands like (.local is the local mdns domain in an ad-hoc network)

Example of the error:

qsense1_user@overo:~$ ping -6 qsense2.local
ping: unknown host qsense2.local

You must add the word ‘mdns’ to the line ‘hosts:’ in the nsswitch.conf file to remedy the situation so host name lookup will use mDNS. Here’s the file with the problem:

qsense1_user@overo:~$ more /etc/nsswitch.conf
# /etc/nsswitch.conf
# Example configuration of GNU name service
hosts: files dns

Now for the fix:

qsense1_user@overo:~$ sudo vi /etc/nsswitch.conf
# /etc/nsswitch.conf
# Example configuration of GNU name service
hosts: files dns mdns //add mdns to this line above or the host lookup never uses mdns!

Test the fix:

qsense1_user@overo:~$ ping -6 qsense2.local
PING qsense2.local (fe80::219:88Fff::fe20:fae9) 56 bytes of data.
64 bytes from fe80::219:88Fff::fe20:fae9: icmp_seq=1 ttl=127 time=0.305 ms
--- hostqsense1.local ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Success! Now use IPv6, mDNS, DNS-SD, and advance web services to conquer the world with your ad-hoc, serverless network... Can you think of anywhere where you might want to run a network with minimal/no IT support, where you would like user to be able to automatically find objects, sensors, controllers, peers and interact with them? The consumer home, ad-hoc military networks, transportation environments perhaps...

Testing IPv6 on Android

We're doing some tests on peer-to-peer (machine-to-machine) IPv6 functionality on Android 2.2 - - can anyone else suggest functioality we are not testing?

WIFI Tests

• WIFI connect to base station?
• WIFI Ad-hoc mode? (P2P with No base station!) Why: Proves we can connect to a gumstix angstrom linux "computer on a chip" or laptop without a WIFI basestation.
  

IPv6 (over WIFI)

• P2P stateless autoconfiguration: (No Infrastructure) Test for P2P Link-Local stateless autoconfiguration - without router advertisements! (this may be a problem!) Why: We want to run ad-hoc and infrastructureless
• Autoconfiguration with a router: Test IPv6 with an IPv6 router advertisement over WIFI
• Stateful autoconfiguration with DHCP: Test IPv6 configuration with our lab’s DHCPv6 server….
• Local COI: Can we manipulate an /etc/hosts table to write a “COI” for IPv6? Why: We will need a way to run P2P in a local ad-hoc network without DNS…
• Connect to IPv6 Web Service: Can we connect to web services hosted on link-local and organization-local (private) addresses? Connect by DNS, mDNS name, or by IP Address?
• Multicasting: Can we write an app to send/receive multicast on Android? There is sample app here: http://code.google.com/p/android/issues/detail?id=2917
• Multicast DNS (mDNS) and Zeroconfig: Can we send and receive mDNS "application service auto-discovery" on Android? Hint: Try the Java mDNS library http://jmdns.sourceforge.net/
• MDNS and DNS-SD (Zeroconfig) Services browser? Is there a Zeroconfig-Bonjour services browser application/sample code already done?
• Programming SDKs:
  *Can we write IPv6 P2P and multicast sample apps on the Android http://developer.android.com/sdk/index.html and Java network sockets? http://developer.android.com/reference/java/net/Socket.html
  
  Ref wiki on current IPv6 Issues in Android: http://code.google.com/p/android/issues/detail?id=3389 (TJ Evans posted some of these!)

Lastly - is anyone interested in helping me develop a physiological monitoring App on android, that couples with a heart monitor and the GPS in the phone, to give you similar functionality to a Garmin Heart Watch? Sort of a running/health tracker!

IPv6 Service via Time Warner Telecom

We just got IPv6 service into our Netcentric-Systems lab via Time Warner Telecom. Time Warner Telecom doesn't have the term "IPv6" anywhere on their customer site or list of services, though they can (and do!) provide the service at a very reasonable rate. We are yet to test the AAAA DNS service, or look to see if the Service Level Agreements (SLAs) are being met for IPv6 as well as IPv4...

Interesting, from the "Address Use Policy" document on Time Warner's site, it appears that they are somewhat worried about IPv4 depletion:
“IPv4 IP address space is a limited resource that is being depleted at a significant rate. All numbers must be accounted for, and each address block must be reassigned via SWIP, RWHOIS or internal databases. [snip] Large address consumers will also be required to maintain, and provide upon request, a database of how addresses are assigned internally.”

I wonder what that site will say in 2011-2012 when IPv4 depletion and IPv6 switchover becomes a continuity of operations issue for service providers...

IPv6 Honeypot and Attack Trend Geo-Analysis

We're setting up an IPv6 Honeypot on our new network and will be using Snort + v6 Geotracing to see the distribution of where attacks are coming from. More to follow as we get our IPv6 cybersecurity lab up and running.

Tuning Snort Intrusion Detection for IPv6

Executive Summary: Installing Snort IDS with IPv6 support is still technically VERY challenging. IPv6 support does not come installed in the default version of Snort and takes a fairly complicated compile process to intall. Despite there existing dozens of IPv6-sepcific vulnerabilities, there are only a couple of IPv6-specific attack signatures in Snort rules. To truly tune Snort for IPv6, your cybersecurity support will have to write your own rules to secure against known vulnerabilities such as the 'IPv6 Routing Header 0' vulnerability.

Tuning Snort Intrusion Detection for IPv6
(On Debian Linux)

If you're involved with IPv6 (Next-Gen Internet) and cybersecurity, you probably know how difficult it is to get good product support and documentation on new IPv6 security features. Snort open source Intrusion Detection System (IDS) and its supported variant by Sourcefire is the leading product for detecting "Badness" invading Enterprise networks. Snort has been experimenting with some level of IPv6 support for the last couple of years and recently it officially released IPv6 support in Snort 2.8 That all sounds great until you look into it and find out how sparse the support really is. The IPv6 capability does not come "baked in" in normal binary releases of Snort so you have to download the code and compile IPv6 support yourself. Also, there are only a couple of IPv6-specific attack signatures in the 2503 signatures that come in the normal snort rules - leaving Snort unable to detect many known IPv6 attacks. In this article, we'll explore the issues of activating IPv6 support, and tuning for additional signatures so your cybersecurity or IT support staff understands the approach to fixing these problems.

Activating IPv6 Support:

Snort 2.8 generally does not come with IPv6 installed in any binary distributions (ex: rpm, dpm, exe files) so you will have to download the source code and compile it yourself. This can be complicated a bit as the latest Snort versions may have dependencies on software that is still in the "testing" or "beta" release of upcoming OS. In the case of my Debian Linux distibution, I couldn't use the stable "Lenny" distribution but instead had to use the upcoming "Squeeze" test distibution in order to get all of the components I needed in one shot. The alternative is to download, compile, and install all of the dependencies - a lengthy process! Once I "upgraded" Debian to Squeeze (which is already very stable!) I needed to obtain the binary code for Snort 2.8 so I could compile it. The command using the Debian package manager is:


$ cd /usr/local/src
$ apt-get source snort

You should see three files downloaded and unpack in your directory:

$ ls
snort_2.8.5.2.orig.tar.gz
snort_2.8.5.2.dsc
snort_2.8.5.2.diff

Also download any dependencies:

$apt-get build-dep snort

Now

$cd snort_2.8.5.2/

Since I want to run snort with IPv6, mysql database support, and the dynamic plugins my next command should look something like:

$ ./configure --enable-ipv6 --with-mysql --enable-dynamic-plugin --prefix=/usr/local/snort-2.8.5.2

Now I'll turn the binary into a Debian package for install:

$ dpkg-buildpackage -uc -b

To install the package built by the commands above one must use the package manager directly, like this:

$ dpkg -i file.deb

Now- if your install went smoothly, time for a test run! Lets activate snort on Ethernet port zero (default) and log alerts to the console with the '-A console' option

$ snort -i eth0 -A console

Look for IPv6 in your build and your pre-processors - - if you don't see this (see below!), you don't have the IPv6 version!!!!!

--== Initialization Complete ==--

,,_ - * > Snort! <*- o" )~ Version 2.8.5.2 IPv6 (Build 121) '' '' By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
Copyright (C) 1998-2009 Sourcefire, Inc., et al.
Using PCRE version: 7.8 2008-09-05

Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.11
Preprocessor Object: SF_DCERPC (IPV6) Version 1.1
Preprocessor Object: SF_Dynamic_Example_Preprocessor Version 1.0
Preprocessor Object: SF_DCERPC2 (IPV6) Version 1.0
Preprocessor Object: SF_SMTP (IPV6) Version 1.1
Preprocessor Object: SF_SSH (IPV6) Version 1.1
Preprocessor Object: SF_FTPTELNET (IPV6) Version 1.2
Preprocessor Object: SF_SSLPP (IPV6) Version 1.1
Preprocessor Object: SF_DNS (IPV6) Version 1.1

Now for a Snort IPv6 shake-down test. We'll run Nmap scanner at an IPv6 target on our network from a second laptop to see if Snort IPv6 picks up the port scan:

root@CyberAttack:/ # nmap -6 fde5:3e88:e86c::1
Starting Nmap 5.00 ( http://nmap.org ) at 2010-04-29 10:51 EDT
Interesting ports on fde5:3e88:e86c::1:
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 7.11 seconds

The Snort Console picks up the IPv6 scan activity and the Nmap :

04/29-10:54:16.516639 [**] [122:1:0] (portscan) TCP Portscan [**] [Priority: 3] {PROTO:255} fde5:3e88:e86c:0000:0226:b9ff:feb9:de18 -> fde5:3e88:e86c:0000:0000:0000:0000:0001

04/29-10:54:21.195671 [**] [1:1421:11] SNMP AgentX/tcp request [**] [Classification:
Attempted Information Leak] [Priority: 2] {TCP}fde5:3e88:e86c:0000:0226:b9ff:feb9:de18:53515 -> fde5:3e88:e86c:0000:0000:0000:0000:0001:705

04/29-10:54:23.503659 [**] [1:1418:11] SNMP request tcp [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} fde5:3e88:e86c:0000:0226:b9ff:feb9:de18:41829 -> fde5:3e88:e86c:0000:0000:0000:0000:0001:161

Tuning for IPv6:

Lets see how many IPv6-specific rules Snort comes with:

$ grep -r-i ipv6 /etc/snort/rules/

/etc/snort/rules/policy.rules:alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"POLICY IPv6 encapsulated in IPv4 activity"; ip_proto:41; classtype:policy-violation; sid:8446; rev:1;)

/etc/snort/rules/web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC malformed ipv6 uri overflow attempt"; flow:to_server,established; uricontent:"3A/["; pcre:"/\x3a\x2f\x5b\s*([\x2F\x3F\x23]*)([\x2F\x3F\x23]+.+)(\x3a[^\x3a^\x5d]*)$/U"; metadata:service http; reference:bugtraq,11187; reference:cve,2004-0786; classtype:web-application-attack; sid:5715; rev:2;)

/etc/snort/rules/icmp-info.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP IPV6 I-Am-Here"; icode:0; itype:34; classtype:misc-activity; sid:411; rev:5;)
/etc/snort/rules/icmp-info.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP IPV6 I-Am-Here undefined code"; icode:>0; itype:34; classtype:misc-activity; sid:412; rev:7;)
/etc/snort/rules/icmp-info.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP IPV6 Where-Are-You"; icode:0; itype:33; classtype:misc-activity; sid:413; rev:5;)
/etc/snort/rules/icmp-info.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP IPV6 Where-Are-You undefined code"; icode:>0; itype:33; classtype:misc-activity; sid:414; rev:7;)

OUCH! Only 6 rules when we know of dozens of possible IPv6-based attacks. On the good side, the thousands of application and policy rules (2497 in my download) generally do fire alerts in the IPv6 version if the attack comes over IPv6. Thats why the Nmap scan rules fired.

Lets try writing a custom rule for a known IPv6 attack. This is a rule for the "router header 0" attack which Jeremy Duncan of Command Information found last year being used as a live network attack and Joe Klein (QinetiQ Cyber Security Principle Architect and IPv6 Security Guru) analyzed and explained to me. This vulnerability was being used to bounce IPv6 packets into an Enterprise network from a "trusted" perimeter router. A sample Snort rule to look for these types of IPv6 routing headers entering a network is:

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"POLICY IPv6 routing extension headers entiring network"; ip_proto:43; classtype: policy-violation; sid:10000005; rev:1;)

I wrote this rule and all of the new IPv6-specific rules in a new rules file I created:

$ nano /etc/snort/rules/ipv6.rules

I added a new command to include a seperate directory of snort IPv6 rules to my snort.conf configuration startup file like this:

$ nano /etc/snort/snort.conf

Near the bottom of snort.conf where you see all the "include rule" statements add:

include $RULE_PATH/ipv6.rules

Conclusions:

This quick overview on getting IPv6 support up on Snort should give you an idea of the challenges of tuning Snort for IPv6 networking. You still have to write several rules for IPv6 specific attacks, set up the alert database and any GUI you are using, and and tune your Snort distribution to your network's traffic.

Further Reading:

• A really good resource for learning how to set up Snort with a Web-GUI on Debian can be found here: http://www.aboutdebian.com/snort.htm


• Richard Bejtlich's article on Snort 2.8's new IPv6 features: http://searchsecuritychannel.techtarget.com/tip/0,289483,sid97_gci1278254,00.html


• US Govt Computer Emergency Response Team (US-CERT) Alerts on IPv6 which you can use to generate Snort signatures can be found here: http://search.us-cert.gov/search?q=IPv6&entqr=0&ud=1&sort=date%3AD%3AL%3Ad1&output=xml_no_dtd&oe=UTF-8&ie=UTF-8&client=default_frontend&proxystylesheet=default_frontend&hq=inurl%3Awww.us-cert.gov%2F&site=default_collection&btnG.x=16&btnG.y=9


• A good basic primer on IPv6 security by Sheila Frankel and company at NIST is NIST SP 800-119 "Guidlines for Secure Deployment of IPv6": http://csrc.nist.gov/publications/drafts/800-119/draft-sp800-119_feb2010.pdf