Generating Multicast Traffic

If you're a protocol junkie like me, you probably enjoy investigating a variety of network traffic types. I don't encounter multicast traffic too often, so the following caught my eye.

I'm using Iperf for some simple testing, and I notice it has a multicast option. Here's how I used it.

In the following scenario, I have two hosts (cel433 and cel600) on the same segment. This is important because the router(s) in this test network are not configured to support multicast.

I set up cel433 as a Iperf server listening on multicast address 224.0.55.55.

cel433:/root# iperf -s -u -B 224.0.55.55 -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 224.0.55.55
Joining multicast group  224.0.55.55
Receiving 1470 byte datagrams
UDP buffer size: 41.1 KByte (default)

Now I generate multicast traffic from cel600.

cel600:/root# iperf -c 224.0.55.55 -u -T 32 -t 3 -i 1
------------------------------------------------------------
Client connecting to 224.0.55.55, UDP port 5001
Sending 1470 byte datagrams
Setting multicast TTL to 32
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[  3] local 10.1.10.3 port 51296 connected with 224.0.55.55 port 5001
[  3]  0.0- 1.0 sec    129 KBytes  1.06 Mbits/sec
[  3]  1.0- 2.0 sec    128 KBytes  1.05 Mbits/sec
[  3]  2.0- 3.0 sec    128 KBytes  1.05 Mbits/sec
[  3]  0.0- 3.0 sec    386 KBytes  1.05 Mbits/sec
[  3] Sent 269 datagrams

Here is what cel433 sees:

------------------------------------------------------------
[  3] local 224.0.55.55 port 5001 connected with 10.1.10.3 port 51296
[  3]  0.0- 1.0 sec    128 KBytes  1.05 Mbits/sec  0.146 ms    0/   89 (0%)
[  3]  1.0- 2.0 sec    128 KBytes  1.05 Mbits/sec  0.100 ms    0/   89 (0%)
[  3]  2.0- 3.0 sec    128 KBytes  1.05 Mbits/sec  0.110 ms    0/   89 (0%)
[  3]  0.0- 3.0 sec    386 KBytes  1.05 Mbits/sec  0.098 ms    0/  268 (0%)
[  3]  0.0- 3.0 sec  1 datagrams received out-of-order

The traffic looks like this:

cel433:/root# tcpdump -n -i xl0 -s 1515 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 1515 bytes
15:29:53.669508 IP 10.1.10.3.51296 > 224.0.55.55.5001: UDP, length 1470
15:29:53.680789 IP 10.1.10.3.51296 > 224.0.55.55.5001: UDP, length 1470
15:29:53.691934 IP 10.1.10.3.51296 > 224.0.55.55.5001: UDP, length 1470
...truncated...

This is a simple way to generate multicast traffic and ensure a member of the multicast group actually receives it.

Update: I forgot to show the IGMP messages one would see when starting a multicast listener.

This is the interface listening for multicast:

cel433:/root# ifconfig xl0
xl0: flags=8843 mtu 1500
        options=9
        inet6 fe80::2c0:4fff:fe1c:102b%xl0 prefixlen 64 scopeid 0x6 
        inet 10.1.10.2 netmask 0xffffff00 broadcast 10.1.10.255
        ether 00:c0:4f:1c:10:2b
        media: Ethernet autoselect (100baseTX )
        status: active

Here are IGMP report and leave messages.

cel433:/root# tcpdump -nevv -i xl0 -s 1515 igmp
tcpdump: listening on xl0, link-type EN10MB (Ethernet), capture size 1515 bytes
06:28:40.887868 00:c0:4f:1c:10:2b > 01:00:5e:00:37:37, ethertype IPv4 (0x0800),
 length 46: (tos 0x0, ttl   1, id 59915, offset 0, flags [none], proto: IGMP (2),
 length: 32, options
 ( RA (148) len 4 )) 10.1.10.2 > 224.0.55.55: igmp v2 report 224.0.55.55

06:28:42.196233 00:c0:4f:1c:10:2b > 01:00:5e:00:00:02, ethertype IPv4 (0x0800),
 length 46: (tos 0x0, ttl   1, id 59920, offset 0, flags [none], proto: IGMP (2),
 length: 32, options
 ( RA (148) len 4 )) 10.1.10.2 > 224.0.0.2: igmp leave 224.0.55.55

I used the -e option to show the MAC addresses. Notice the destination MAC for these multicast packets.

06:31:21.467919 00:b0:d0:14:b2:11 > 01:00:5e:00:37:37, ethertype IPv4 (0x0800),
 length 1512: (tos 0x0, ttl  32, id 1652, offset 0, flags [none], proto: UDP (17),
 length: 1498) 
 10.1.10.3.58479 > 224.0.55.55.5001: [udp sum ok] UDP, length 1470

The 01:00:5e:00:37:37 MAC address is a mapping derived from the 24-bit IANA multicast OUI 01:00:5e and the multicast IP address 224.0.55.55.

Read More

SwitchProxy and Tor

I just wrote about Web Browsing with Tor. You might wonder if there's an easy way to switch to using Tor while running Firefox. I looked at the Torbutton extension, but then I found SwitchProxy. I like SwitchProxy because can you configure multiple proxies and decide when to use them.

If you click on the thumb image above you'll see me accessing a Hidden Service using Tor while I have Privoxy and Tor working together. Notice the URL -- http://6sxoyfb3h2nvok2d.onion/

I can just as easily switch to my production proxy, or even import a list of anonymous proxies and have SwitchProxy cycle through them every X seconds.

Read More

Installing Privoxy

A task I'm going to blog shortly recommends that I install Privoxy. I encounted some troubles using FreeBSD so I thought I would document them.

First I installed the package.

orr:/root# pkg_add -vr privoxy
...edited...
Running pre-install for privoxy-3.0.3_4..
extract: Package name is privoxy-3.0.3_4
extract: CWD to /usr/local
extract: /usr/local/man/man1/privoxy.1.gz
extract: /usr/local/sbin/privoxy
extract: /usr/local/etc/privoxy/config
extract: /usr/local/etc/privoxy/default.action
extract: /usr/local/etc/privoxy/default.filter
extract: /usr/local/etc/privoxy/trust
...edited...

***********************************************************
** Before running privoxy you must modify the file       **
** /usr/local/etc/privoxy/config                         **
**                                                       **
** Start privoxy with:                                   **
** /usr/local/sbin/privoxy /usr/local/etc/privoxy/config **
**                                                       **
** For documentation see:                                **  
** /usr/local/share/doc/privoxy-manual or 'man privoxy'  **
***********************************************************

Next I enabled Privoxy in /etc/rc.conf.

orr:/root# echo "privoxy_enable=YES" >> /etc/rc.conf

Next I tried starting Privoxy. I ran into some problems that I fixed with the following:

orr:/usr/local/etc/rc.d# mkdir /var/run/privoxy
orr:/usr/local/etc/rc.d# chown privoxy:privoxy /var/run/privoxy
orr:/usr/local/etc/rc.d# mkdir /var/log/privoxy
orr:/usr/local/etc/rc.d# chown privoxy:privoxy /var/log/privoxy

Here's what Privoxy looks like while running.

orr:/usr/local/etc/rc.d# ./privoxy start
Starting privoxy.
orr:/usr/local/etc/rc.d# sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
privoxy  privoxy    40053 3  tcp4   127.0.0.1:8118        *:*
richard  firefox-bi 37850 22 tcp4   192.168.2.5:62936     66.249.83.83:80
richard  ssh        691   3  tcp4   192.168.2.5:49499     172.16.3.2:22
root     sendmail   468   4  tcp4   127.0.0.1:25          *:*
root     sshd       462   4  tcp4   *:22                  *:*
root     syslogd    320   7  udp4   *:514                 *:*

So what is this good for? Well, now that I have Privoxy listening on port 8118 TCP I can point my Web browser toward it. I tell Firefox to use localhost port 8118 and now all my Web requests use Privoxy.

I can test the difference between normal Web browsing and Privoxy Web browsing by visiting http://config.privoxy.org/show-status. It shows information like the following.

Show-Request

Here you see the original headers that your client sent when requesting this page, along with the headers that Privoxy would have sent to the remote server if this request hadn't been intercepted.

Original Client Request:

GET http://config.privoxy.org/show-request HTTP/1.1
Host: config.privoxy.org
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.7)
 Gecko/20060917 Firefox/1.5.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
 text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://config.privoxy.org/show-status
If-Modified-Since: Mon, 18 Sep 2006 15:25:41 GMT
Cache-Control: max-age=0

Processed Request:

GET /show-request HTTP/1.1
Host: config.privoxy.org
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.7) 
 Gecko/20060917 Firefox/1.5.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
 text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Referer: http://config.privoxy.org/
If-Modified-Since: Mon, 18 Sep 2006 15:25:41 GMT
Cache-Control: max-age=0
X-Actions-File-Version: 1.8
Connection: close

This doesn't appear to be a big deal, but I'm using Privoxy's default configuration. In my next post I'll combine Privoxy with Tor to facilitate (but not guarantee) anonymous Web browsing.

Read More

Web Browsing with Tor

In my Installing Privoxy post I said I needed to install Privoxy for a certain task. I decided to use Privoxy with Tor to facilitate anonymous Web browsing.

First I installed Tor via package.

orr:/root# pkg_add -vr tor
...edited...
Package 'tor-0.1.1.23' depends on 'tsocks-1.8.b5_3' with 'net/tsocks' origin.
...edited...
extract: Package name is tsocks-1.8.b5_3
extract: CWD to /usr/local
extract: /usr/local/man/man1/tsocks.1.gz
extract: /usr/local/man/man5/tsocks.conf.5.gz
extract: /usr/local/man/man8/tsocks.8.gz
extract: /usr/local/bin/tsocks
extract: /usr/local/etc/tsocks.conf.sample
extract: /usr/local/lib/libtsocks.so.1
extract: /usr/local/lib/libtsocks.so
extract: /usr/local/share/examples/tsocks/tsocks.conf.complex.example
extract: /usr/local/share/examples/tsocks/tsocks.conf.simple.example
extract: /usr/local/share/examples/tsocks/README
...edited...
Package 'tor-0.1.1.23' depends on 'libevent-1.2' with 'devel/libevent' origin.
 - already installed.
Running pre-install for tor-0.1.1.23..
Added group "_tor".
Added user "_tor".
extract: Package name is tor-0.1.1.23
extract: CWD to /usr/local
extract: /usr/local/man/man1/tor.1.gz
extract: /usr/local/man/man1/tor-resolve.1.gz
extract: /usr/local/man/man1/torify.1.gz
extract: /usr/local/bin/tor
extract: /usr/local/bin/tor-resolve
extract: /usr/local/bin/torify
extract: /usr/local/etc/tor/tor-tsocks.conf.sample
extract: /usr/local/etc/tor/torrc.sample
extract: CWD to /usr/local
extract: /usr/local/etc/rc.d/tor
...edited.
================================================================================
To enable the tor server, set tor_enable="YES" in your /etc/rc.conf
and edit /usr/local/etc/tor/torrc.  Also note that the rc.subr script overrides
many torrc options and is tunable.  See /usr/local/etc/rc.d/tor.sh for details
================================================================================
...truncated...

Next I made a copy of the config file and enabled Tor's startup script.

orr:/root# cp /usr/local/etc/tor/torrc.sample /usr/local/etc/tor/torrc
orr:/root# echo "tor_enable=YES" >> /etc/rc.conf

Finally I told Privoxy to accept connections and send them to Tor, which would listen on port 9050 TCP.

orr:/root# echo "forward-socks4a / localhost:9050 ." >> /usr/local/etc/privoxy/config

Using SOCKS4A means my local host will not make DNS requests. Instead, they will be made by the SOCKS server (ostensibly through Tor).

Thanks to this guide for help!

Now I start Privoxy.

orr:/root# /usr/local/etc/rc.d/privoxy start
Starting privoxy.

Finally I start Tor.

orr:/root# /usr/local/etc/rc.d/tor start
/usr/local/etc/rc.d/tor: WARNING: /var/db/tor is not a directory.

That's no good. I make the required directory. (Why isn't that a default?)

orr:/root# mkdir /var/db/tor
orr:/root# /usr/local/etc/rc.d/tor start
Starting tor.
Sep 18 10:50:59.336 [notice] Tor v0.1.1.23. This is experimental software. 
 Do not rely on it for strong anonymity.
Sep 18 10:50:59.346 [notice] Initialized libevent version 1.2 using method kqueue. Good.
Sep 18 10:50:59.348 [warn] /var/db/tor is not owned by this user (_tor, 256) but by root (0). 
 Perhaps you are running Tor as the wrong user?
Sep 18 10:50:59.349 [warn] Failed to parse/validate config: Couldn't access/create private data 
 directory "/var/db/tor"
Sep 18 10:50:59.350 [err] tor_init(): Reading config failed--see warnings above. For usage, try -h.

Shoot. I need to let the _tor user access the directory I just made.

orr:/root# chown _tor:_tor /var/db/tor

Now I start Tor.

orr:/root# /usr/local/etc/rc.d/tor start
Sep 18 11:12:06.587 [notice] Tor v0.1.1.23. This is experimental software.
 Do not rely on it for strong anonymity.
Sep 18 11:12:06.597 [notice] Initialized libevent version 1.2 using method kqueue. Good.
Sep 18 11:12:06.597 [notice] connection_create_listener(): Opening Socks listener on 
 127.0.0.1:9050
Sep 18 11:12:06.600 [warn] options_init_logs(): Can't log to stdout with RunAsDaemon set; 
 skipping stdout

Let's see what's listening.

orr:/root# sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
_tor     tor        39325 4  tcp4   192.168.2.5:57518     62.35.214.207:9030
_tor     tor        39325 5  tcp4   127.0.0.1:9050        *:*
_tor     tor        39325 6  tcp4   192.168.2.5:56850     70.32.145.204:9001
_tor     tor        39325 8  tcp4   192.168.2.5:64675     218.189.210.17:4806
root     privoxy    39312 3  tcp4   127.0.0.1:8118        *:*
richard  ssh        691   3  tcp4   192.168.2.5:49499     172.16.3.2:22
root     sendmail   468   4  tcp4   127.0.0.1:25          *:*
root     sshd       462   4  tcp4   *:22                  *:*
root     syslogd    320   7  udp4   *:514                 *:*

Now I configure my Web browser to connect to port 8118 (where Privoxy is listening), and Privoxy will send my traffic to port 9050 TCP where Tor is listening.

Now if I browse to a site like whatismyip.com I get a result like 195.71.8.10, which is plug.rfc822.org.

You can see Tor node status at sites like serifos.eecs.harvard.edu/cgi-bin/exit.pl and node2.xenobite.eu/torstat.php.

Read More

All Network Security Functions in the Switch

The ISS acquisition has me thinking again about the security space. I noticed Richard Stiennon wrote the following:

Consolidation? Not even close. There are over 867 vendors in the IT-Harvest knowledge base this morning. When that number falls month to month we can start talking about consolidation.

I'm not sure that's the right way to look at the issue. How many of those companies are 1 year old or less? 2 years? 3 years? I'm guessing that many companies that were firewall development startups have either been bought or gone out of business. The same can be said for other product types. The vendor count may never decrease because new companies are always joining the market to address new problems (or so they claim). I think that process is consolidation.

The main reason I posted this entry, however, is the title above. I am not the only person to discuss collapsing all network security functions into switches, and I have probably said something similar already. Nevertheless, I believe that the future is not bright for companies that want to introduce network security products but remain independent.

Let me define a few terms. By "network security" I mean products that interact with network traffic, for inspection or access control decisions. I do not mean products which work on the host level. When I say "remain independent" I mean start as a small company and grow to become a billion dollar plus company.

It seems as though all network security functions are going to collapse into the devices which carry traffic -- switches. Consider a router to be a "layer 3 switch" for the sake of this argument. If you can't accept that, imagine I said "switches and routers" earlier.

I think the shelf life of point products is going to become increasingly short. In other words, I could see IBM eventually selling or abandoning its ISS network security product line. Why? IBM doesn't make switches or routers that compete with Cisco. The functions that ISS network security products provide, however, are going to end up in Cisco switches. Those features are going to be available as upgrades to sufficiently powerful switches, leaving managers with the choice of running Cisco plus other boxes, or just Cisco. They will choose "just Cisco."

Am I Cisco hack? No (but I do have my CCNA). Do I think this is the best of all possible worlds? No, since I prefer Cisco's routing and switching to its security products. Nevertheless, the drive to consolidate products is going to eventually collapse network security functionality down to the only boxes which absolutely must remain -- switches.

I expect to see network security point products continue to be developed. However, they will continue to be outsourced research, development, and viability testing factories for Cisco. When Cisco sees a product it likes, it will buy the company and then integrate the functionality into its own equipment.

Where does this leave the other security gorillas, and gorilla wanna-bes? Those that focus on host-centric products may continue to exist, but there is a good chance that they will be continue to be bought by Microsoft. Those that provide services to make all this work will grow. I think this is where IBM and other giant integrators can make a good living.

Read More