LBNL/ICSI Enterprise Tracing Project

Thanks to ronaldo in #snort-gui I learned about the LBNL/ICSI Enterprise Tracing Project. According to the site:

A goal of this project is to characterize internal enterprise traffic recorded at a medium-sized site, and to determine ways in which modern enterprise traffic is similar to wide-area Internet traffic, and ways in which it is quite different.

We have collected packet traces that span more than 100 hours of activity from a total of several thousand internal hosts. This wealth of data, which we are publicly releasing in anonymized form, spans a wide range of dimensions.

I decided to take a look at this data through the lens of Structured Traffic Analysis, which I discuss in Extrusion Detection and (IN)SECURE Magazine. I downloaded lbl-internal.20041004-1303.port001.dump.anon and took the following actions.

First I ran capinfos to get a sense of the nature of the trace.

$ sha256 lbl-internal.20041004-1303.port001.dump.anon
 > lbl-internal.20041004-1303.port001.dump.anon.sha256
$ capinfos lbl-internal.20041004-1303.port001.dump.anon
File name: lbl-internal.20041004-1303.port001.dump.anon
File type: libpcap (tcpdump, Ethereal, etc.)
Number of packets: 84574 
File size: 5907016 bytes
Data size: 33872987 bytes
Capture duration: 600.507393 seconds
Start time: Mon Oct  4 16:03:41 2004
End time: Mon Oct  4 16:13:41 2004
Data rate: 56407.28 bytes/s
Data rate: 451258.22 bits/s
Average packet size: 400.51 bytes

We can see this trace occupies 10 minutes in October 2004, at 451 Kbps, with 84574 packets.

Next I run Tcpdstat to learn a little more about the traffic.

$ tcpdstat lbl-internal.20041004-1303.port001.dump.anon

DumpFile:  lbl-internal.20041004-1303.port001.dump.anon
FileSize: 5.63MB
Id: 200410041603
StartTime: Mon Oct  4 16:03:41 2004
EndTime:   Mon Oct  4 16:13:41 2004
TotalTime: 600.51 seconds
TotalCapSize: 4.34MB  CapLen: 74 bytes
# of packets: 84574 (32.30MB)
AvgRate: 451.17Kbps  stddev:304.48K

### IP flow (unique src/dst pair) Information ###
# of flows: 260  (avg. 325.28 pkts/flow)
Top 10 big flow size (bytes/total in %):
 37.9% 18.0% 15.8%  7.4%  6.8%  5.0%  1.3%  1.1%  0.7%  0.7%

### IP address Information ###
# of IPv4 addresses: 143 
Top 10 bandwidth usage (bytes/total in %):
 56.1% 55.9% 35.0% 23.0% 12.5%  2.7%  1.7%  1.3%  1.3%  1.0%
### Packet Size Distribution (including MAC headers) ###
<<<<
 [   32-   63]:      12784
 [   64-  127]:      17662
 [  128-  255]:      27008
 [  256-  511]:       7531
 [  512- 1023]:       2416
 [ 1024- 2047]:      17173
>>>>


### Protocol Breakdown ###
<<<<
     protocol           packets                 bytes           bytes/pkt
------------------------------------------------------------------------
[0] total            84574 (100.00%)         33872987 (100.00%)    400.51
[1] ip               84514 ( 99.93%)         33859701 ( 99.96%)    400.64
[2]  tcp             82817 ( 97.92%)         33278039 ( 98.24%)    401.83
[3]   http(s)         1727 (  2.04%)          1251300 (  3.69%)    724.55
[3]   http(c)         1579 (  1.87%)           267624 (  0.79%)    169.49
[3]   imap             488 (  0.58%)           122352 (  0.36%)    250.72
[3]   ssh              176 (  0.21%)            26337 (  0.08%)    149.64
[3]   other          78847 ( 93.23%)         31610426 ( 93.32%)    400.91
[2]  udp               399 (  0.47%)            88116 (  0.26%)    220.84
[3]   dns               50 (  0.06%)             8669 (  0.03%)    173.38
[3]   other            349 (  0.41%)            79447 (  0.23%)    227.64
[2]  icmp              375 (  0.44%)            35880 (  0.11%)     95.68
[2]  ipsec             923 (  1.09%)           457666 (  1.35%)    495.85
>>>>

You get some of the same information as noted in Capinfos, but you also get some primitive protocol breakdowns. Unfortunately, 93.23% of the TCP traffic is unrecognized "other."

Let's see if Tethereal does any better:

taosecurity:/home/analyst/lbl$ tethereal -n -r lbl-internal.20041004-1303.port001.dump.anon -q -z io,phs

===================================================================
Protocol Hierarchy Statistics
Filter: frame

frame                                    frames:84574 bytes:33872987
  eth                                    frames:84574 bytes:33872987
    ip                                   frames:84514 bytes:33859701
      tcp                                frames:82817 bytes:33278039
      udp                                frames:399 bytes:88116
        isakmp                           frames:176 bytes:53996
          short                          frames:176 bytes:53996
        short                            frames:207 bytes:32742
      short                              frames:923 bytes:457666
      icmp                               frames:375 bytes:35880
    short                                frames:30 bytes:11340
    arp                                  frames:28 bytes:1792
===================================================================

Unfortunately, Tethereal statistics don't tell you really anything different from Tcpdstat. Usually Tethereal statistics are more informative, but not here. For the sake of comparison, here is what Wireshark GUI statistics tell you.



Notice the format is different (but more human-friendly), and there is no way to copy or save it to a file. That would be a nice feature. (Tshark shows the same output as Tethereal, incidentally.)

The next step is to let Argus parse the file and then let Argus summarize the protocols it sees.

taosecurity:/home/analyst/lbl$ argus -r lbl-internal.20041004-1303.port001.dump.anon -w lbl.arg 
 
taosecurity:/home/analyst/lbl$ ragator -r lbl.arg -w lbl.arg.ragator

taosecurity:/home/analyst/lbl$ racount -ar lbl.arg.ragator 
racount    records       total_pkts         src_pkts         dst_pkts 
     total_bytes        src_bytes        dst_bytes
    tcp        234            82817            39423            43394
         33203201         10825712         22377489
    udp         84              399              341               58
            87969            77032            10937
   icmp         36              375              224              151
            35682            21416            14266
    arp          4               28               28                0
             1792             1792                0
 non-ip          4               32               32                0
            11494            11494                0
    sum        363            83651            40048            43603
         33340138         10937446         22402692

The next step is to see the IP addresses involved in this trace.

taosecurity:/home/analyst/lbl$ rahosts -nr lbl.arg.ragator 
13.59.236.185
33.115.84.19
56.173.106.169
57.161.221.95
57.172.228.116
59.11.88.73
59.79.189.88
59.133.234.45
59.152.11.128
59.214.234.155
59.223.4.38
59.223.8.17
69.152.121.223
92.1.70.86
92.2.245.156
118.123.53.121
118.132.250.187
118.133.86.156
118.133.157.28
118.160.89.230
118.172.218.242
128.3.2.67
128.3.44.26
128.3.44.90
128.3.44.94
128.3.44.98
128.3.44.101
128.3.44.112
128.3.44.167
128.3.44.242
128.3.45.7
128.3.45.10
128.3.45.84
128.3.45.105
128.3.45.128
128.3.45.164
128.3.45.225
128.3.45.232
128.3.46.51
128.3.46.146
128.3.46.165
128.3.46.179
128.3.46.190
128.3.46.202
128.3.46.232
128.3.46.246
128.3.46.252
128.3.47.46
128.3.47.49
128.3.47.58
128.3.47.114
128.3.47.119
128.3.47.161
128.3.47.183
128.3.47.191
128.3.47.207
128.3.47.209
128.3.47.255
128.3.70.147
128.3.71.140
128.3.95.149
128.3.96.157
128.3.96.230
128.3.97.58
128.3.97.204
128.3.99.54
128.3.99.102
128.3.99.118
128.3.100.81
128.3.100.204
128.3.148.125
128.3.161.74
128.3.161.96
128.3.161.98
128.3.161.165
128.3.161.182
128.3.161.223
128.3.161.230
128.3.162.146
128.3.164.191
128.3.164.194
128.3.164.203
128.3.189.187
128.3.189.248
128.3.190.85
128.3.193.169
128.3.193.172
128.3.194.133
128.3.194.169
128.3.194.231
128.3.204.42
128.3.209.152
128.3.212.21
128.3.212.208
131.243.63.245
131.243.89.55
131.243.89.131
131.243.91.153
131.243.91.229
131.243.140.105
131.243.140.156
131.243.141.187
131.243.160.216
131.243.208.56
131.243.208.210
131.243.219.216
137.107.86.84
148.184.171.6
148.184.171.104
148.184.175.97
148.184.191.214
159.29.113.169
163.27.195.211
163.27.232.226
167.130.77.99
169.182.111.161
172.16.34.231
194.80.36.186
198.166.39.133
201.52.39.133
202.46.87.173
203.13.173.243
204.116.246.71
205.103.33.197
207.215.132.184
207.235.114.53
207.235.115.253
207.235.214.252
207.235.255.108
207.245.43.126
208.0.11.26
208.233.189.150
208.235.59.226
216.192.122.101
218.105.16.20
218.131.115.53
218.165.163.184
218.195.4.173
218.201.93.0

That's a lot of addresses for a 10 minute trace. Given the preponderance of 128.3.0.0/16 addresses, I'm guessing that is the HOME_NET.

The next step involves creating what I call session combinations. Essentially I remove the source port as a factor and I group on source IP, destination IP, and destination port.

taosecurity:/home/analyst/lbl$ ra -nn -r lbl.arg.ragator -s
 saddr daddr dport proto | sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 |
 uniq -c 

   1 a6:c6:c9:23:cc: a9:71:1d:9f:85:      321
   1 3b:d:21:32:30:a 80:b:98:3b:b9:e     2457
   1    33.115.84.19     128.3.47.46.5554   tcp
   1    33.115.84.19     128.3.47.46.9898   tcp
   1    33.115.84.19    128.3.44.101.5554   tcp
   1    33.115.84.19    128.3.44.101.9898   tcp
   1    33.115.84.19    128.3.45.105.5554   tcp
   1    33.115.84.19    128.3.45.105.9898   tcp
   1    33.115.84.19    128.3.46.146.5554   tcp
   1    33.115.84.19    128.3.46.146.9898   tcp
   1    33.115.84.19    128.3.46.202.5554   tcp
   1    33.115.84.19    128.3.46.202.9898   tcp
   1    33.115.84.19    128.3.46.232.5554   tcp
   1    33.115.84.19    128.3.46.232.9898   tcp
   1    33.115.84.19    128.3.47.209.5554   tcp
   1    33.115.84.19    128.3.47.209.9898   tcp
   1 34:c9:c8:fa:af: a9:71:1d:9f:85:      381
   1 34:c9:c8:fa:af: a9:71:1d:9f:85:      390
   1  69.152.121.223    128.3.46.179       icmp
   1 118.132.250.187    128.3.44.112.1518   tcp
   1 118.132.250.187    128.3.44.112.1525   tcp
   4     128.3.44.26    128.3.190.85.143    tcp
   1     128.3.44.26    128.3.47.255.138    udp
   1     128.3.44.26    128.3.97.204.53     udp
   4     128.3.44.26   128.3.164.194.143    tcp
   1     128.3.44.26   128.3.189.187.138    udp
   1     128.3.44.26   128.3.189.248       icmp
   1     128.3.44.26   128.3.189.248.138    udp
   1     128.3.44.26   128.3.189.248.139    tcp
   1     128.3.44.26   128.3.189.248.2074   tcp
   1     128.3.44.90   128.3.212.208.514    udp
   1     128.3.44.98    128.3.97.204.53     udp
   2     128.3.44.98    128.3.99.118.993    tcp
   1     128.3.44.98   128.3.164.191.5730   tcp
   1    128.3.44.101     128.3.97.58.123    udp
   1    128.3.44.101     128.3.99.54.123    udp
   2    128.3.44.112     59.11.88.73.80     tcp
   5    128.3.44.112     59.223.4.38.80     tcp
   2    128.3.44.112     59.223.8.17.80     tcp
   1    128.3.44.112    128.3.47.255.137    udp
   1    128.3.44.112    128.3.47.255.138    udp
   3    128.3.44.112    128.3.97.204.53     udp
   2    128.3.44.112    218.201.93.0.443    tcp
   6    128.3.44.112    59.79.189.88.80     tcp
   1    128.3.44.112   128.3.164.194.143    tcp
   1    128.3.44.112   148.184.171.6       icmp
   1    128.3.44.112   148.184.171.6.135    tcp
   2    128.3.44.112   148.184.171.6.139    tcp
   1    128.3.44.112   148.184.171.6.389    udp
   2    128.3.44.112   148.184.171.6.445    tcp
   2    128.3.44.112   218.105.16.20.80     tcp
   2    128.3.44.112   218.195.4.173.80     tcp
   2    128.3.44.112  118.133.157.28.80     tcp
   4    128.3.44.112  118.133.86.156.80     tcp
   2    128.3.44.112  148.184.175.97       icmp
   1    128.3.44.112  148.184.175.97.135    tcp
   1    128.3.44.112  148.184.175.97.139    tcp
   2    128.3.44.112  148.184.175.97.389    udp
   1    128.3.44.112  148.184.175.97.445    tcp
   1    128.3.44.112  163.27.195.211.443    tcp
   2    128.3.44.112  163.27.195.211.80     tcp
   1    128.3.44.112  163.27.232.226.80     tcp
   1    128.3.44.112  205.103.33.197.80     tcp
   2    128.3.44.112  208.235.59.226.80     tcp
   4    128.3.44.112 118.132.250.187.443    tcp
   1    128.3.44.112 148.184.171.104       icmp
   1    128.3.44.112 148.184.171.104.139    tcp
   1    128.3.44.112 148.184.171.104.445    tcp
   2    128.3.44.112 148.184.191.214.389    udp
   2    128.3.44.112 207.235.214.252.80     tcp
   1    128.3.44.112 207.235.255.108.5002   tcp
   1    128.3.44.167  131.243.208.56.123    udp
   1    128.3.44.242   128.3.212.208.514    udp
   1      128.3.45.7    128.3.96.157.22     tcp
   1      128.3.45.7    128.3.99.102.53     udp
   1     128.3.45.10     208.0.11.26.80     tcp
   1     128.3.45.10    128.3.47.255.137    udp
   1     128.3.45.10    128.3.47.255.138    udp
   1     128.3.45.10    128.3.97.204       icmp
   2     128.3.45.10    128.3.97.204.53     udp
   1     128.3.45.10   128.3.148.125.1521   tcp
  26     128.3.45.10   137.107.86.84.80     tcp
   1     128.3.45.10  203.13.173.243       icmp
   1     128.3.45.10  203.13.173.243.53     udp
   1     128.3.45.10  56.173.106.169.80     tcp
   1     128.3.45.10  59.214.234.155.80     tcp
   2     128.3.45.10 169.182.111.161.80     tcp
   1     128.3.45.84   128.3.212.208.514    udp
   1    128.3.45.105    128.3.96.157.67     udp
   1    128.3.45.128  118.123.53.121.80     tcp
   5    128.3.45.128  207.245.43.126.80     tcp
  55    128.3.45.128  218.131.115.53.80     tcp
   1    128.3.45.128 207.215.132.184.80     tcp
  14    128.3.45.128 208.233.189.150.80     tcp
   1    128.3.45.164    128.3.97.204.53     udp
   1    128.3.45.164   128.3.161.182.139    tcp
   1    128.3.45.164   128.3.161.223.138    udp
   1    128.3.45.164   167.130.77.99.80     tcp
   1    128.3.45.225    128.3.47.255.138    udp
   1    128.3.45.225    128.3.70.147.161    udp
   1    128.3.45.225    128.3.71.140.161    udp
   6    128.3.45.225    128.3.97.204.53     udp
   1    128.3.45.225   172.16.34.231.161    udp
   1    128.3.45.232   202.46.87.173.80     tcp
   1     128.3.46.51   128.3.212.208.514    udp
   1    128.3.46.146    128.3.212.21     2054
   1    128.3.46.146    128.3.96.230     2054
   1    128.3.46.146    33.115.84.19     2054
   1    128.3.46.146   128.3.162.146     2054
   1    128.3.46.165   128.3.161.223.138    udp
   1    128.3.46.165   128.3.161.223.139    tcp
   1    128.3.46.165   128.3.161.223.2645   tcp
   1    128.3.46.165   128.3.164.194.993    tcp
   1    128.3.46.165   128.3.209.152       icmp
   1    128.3.46.190    128.3.161.74       icmp
   1    128.3.46.190    128.3.47.255.138    udp
   1    128.3.46.190   128.3.161.165       icmp
   1    128.3.46.190   128.3.161.223.139    tcp
   1    128.3.46.190   128.3.161.230       icmp
   1    128.3.46.190   128.3.164.194.993    tcp
   1    128.3.46.190 131.243.141.187       icmp
   1    128.3.46.246   128.3.209.152       icmp
   4    128.3.46.252    128.3.95.149.111    udp
   1     128.3.47.46   128.3.212.208.514    udp
   1     128.3.47.49 131.243.219.216.137    udp
   1     128.3.47.58   128.3.209.152       icmp
   1    128.3.47.114   128.3.212.208.514    udp
   1    128.3.47.119    128.3.47.255.138    udp
   1    128.3.47.119   128.3.193.169.139    tcp
   1    128.3.47.119   128.3.209.152       icmp
   2    128.3.47.161   128.3.164.194.993    tcp
   1    128.3.47.161   128.3.164.203.389    tcp
   1    128.3.47.183    128.3.47.255.138    udp
   1    128.3.47.183   128.3.189.248.139    tcp
   1    128.3.47.183  204.116.246.71.1863   tcp
   6    128.3.47.183 218.165.163.184.80     tcp
   1    128.3.47.191    128.3.47.255.138    udp
   1    128.3.47.191  131.243.89.131.161    udp
   1    128.3.47.191  131.243.91.153.161    udp
   1    128.3.47.191  131.243.91.229.161    udp
   3    128.3.47.207      128.3.2.67.80     tcp
   1    128.3.47.207    128.3.161.96.88     tcp
   1    128.3.47.207    128.3.97.204.53     udp
   1    128.3.47.207   128.3.164.194.993    tcp
   1    128.3.47.207   128.3.193.169.139    tcp
   1    128.3.47.207   128.3.193.169.80     tcp
   2    128.3.47.207   128.3.193.172.80     tcp
   1    128.3.47.207   128.3.194.133.161    udp
   1    128.3.47.207   128.3.194.169.161    udp
   1    128.3.47.207   128.3.194.231.161    udp
   1    128.3.47.207 131.243.140.156       icmp
   1    128.3.47.207 131.243.140.156.1026   tcp
   1    128.3.47.207 131.243.140.156.135    tcp
   1    128.3.47.207 131.243.140.156.445    tcp
   1    128.3.96.157    128.3.45.105       icmp
   1    128.3.96.230     128.3.47.46       icmp
   1    128.3.96.230    128.3.44.101       icmp
   1    128.3.96.230    128.3.45.105       icmp
   1    128.3.96.230    128.3.46.146       icmp
   7    128.3.96.230    128.3.46.146.161    udp
   1    128.3.96.230    128.3.46.202       icmp
   1    128.3.96.230    128.3.46.232       icmp
   1    128.3.96.230    128.3.47.209       icmp
   1    128.3.100.81   57.161.221.95.500    udp
   1    128.3.100.81   59.133.234.45.500    udp
   1    128.3.100.81  57.172.228.116.500    udp
   1    128.3.100.81 118.172.218.242.500    udp
   1   128.3.100.204      92.1.70.86.500    udp
   1   128.3.100.204    92.2.245.156.500    udp
   1   128.3.100.204  118.160.89.230.500    udp
   1   128.3.100.204  131.243.63.245.500    udp
   1    128.3.161.98    128.3.46.190.1050   tcp
   1   128.3.161.165    128.3.46.190.1047   tcp
   1   128.3.161.165    128.3.46.190.1048   tcp
   1   128.3.161.223    128.3.46.165.139    tcp
   1   128.3.162.146    128.3.46.146       icmp
   1   128.3.164.191     128.3.44.98.4543   tcp
   1   128.3.164.194    128.3.44.112.1395   tcp
   1    128.3.204.42     128.3.44.26.38293  udp
   1   128.3.209.152     128.3.47.58.38293  udp
   1   128.3.209.152    128.3.46.165.38293  udp
   1   128.3.209.152    128.3.46.246.38293  udp
   1   128.3.209.152    128.3.47.119.38293  udp
   1    128.3.212.21    128.3.46.146       icmp
   1   128.3.212.208     128.3.44.90       icmp
   1   128.3.212.208     128.3.44.94.137    udp
   1   128.3.212.208     128.3.45.84       icmp
   1   128.3.212.208     128.3.45.84.137    udp
   1   128.3.212.208     128.3.46.51       icmp
   1   128.3.212.208     128.3.46.51.137    udp
   1   128.3.212.208     128.3.47.46       icmp
   1   128.3.212.208    128.3.44.242       icmp
   1   128.3.212.208    128.3.47.114       icmp
   1   128.3.212.208    128.3.47.114.137    udp
   1   131.243.89.55     128.3.47.58.139    tcp
   1 131.243.140.105    128.3.46.190.1057   tcp
   1 131.243.160.216    128.3.46.190.1119   tcp
   1 131.243.208.210    128.3.44.167       icmp
   1 148.184.191.214    128.3.44.112       icmp
   1   194.80.36.186    128.3.46.232       icmp
   1  207.235.114.53    128.3.47.183.4206   tcp
   1 207.235.115.253    128.3.44.112.4973   tcp
   1 216.192.122.101     128.3.44.94.49201  tcp
   1  229.97.122.203               1 0      man

I like creating these session combinations because they show me connections to hosts and destination ports. I can review these target ports, for example, to look for sessions which might be interesting. This is as far as we can go, because all of the application layer details for these sessions have been eliminated by the Tcpmkpub anonymization tool.

At some point I plan to update this methodology using Argus 3.0, and automate the process.

Read More

Metasploit 3 on FreeBSD

I've wanted to try Metasploit 3 since it was released in late March. I noticed the metasploit/devel FreeBSD port, but it wanted me to install framework-3.0-beta-3-svn.tar.gz. I decided to install Metasploit 3 (gold) manually, using the FreeBSD port dependencies for guidance.

I installed the following via the ports tree:

• devel/subversion


• devel/ruby-gems


• databases/rubygem-activerecord


• lang/ruby18

Then I extracted the framework-3.0.tar.gz I downloaded to /usr/local/src.

When I tried to run msfweb, I got this error:

Cannot find gem for Rails ~> 1.2.2.0:
Install the missing gem with “gem install - v=1.2.2 rails”,
or change environment.rb to define RAILS_GEM_VERSION with
your desired version.

Hmm. First I decided I needed to install www/rubygem-rails, which I did. Next I looked in framework-3.0/data/msfweb/config and found environment.rb, with these lines which I added to specify 1.2.3 instead of 1.2.2:

# Specifies gem version of Rails to use when vendor/rails is not present
#RAILS_GEM_VERSION = '1.2.2' unless defined? RAILS_GEM_VERSION
RAILS_GEM_VERSION = '1.2.3' unless defined? RAILS_GEM_VERSION

Next I started msfweb and told it to bind to an IP I could reach.

neely-bsd:/usr/local/src/framework-3.0# ruby ./msfweb -a 192.168.2.9

[*] Starting msfweb v3.0 on http://192.168.2.9:55555/

=> Booting WEBrick...
=> Rails application started on http://192.168.2.9:55555
=> Ctrl-C to shutdown server; call with --help for options

When I connected to the specified IP and port with a Web browser, I was able to exploit a demo Windows target without issue. The new interface is slick. It looks like most of the evasion options are for layer 4 and higher.

Read More

CALEA Mania

CALEA is the Communications Assistance for Law Enforcement Act. I wrote about CALEA three years ago in Excellent Coverage of Wiretapping:

CALEA requires telecommunications carriers to allow law enforcement "to intercept, to the exclusion of any other communications, all wire and electronic communications carried by the carrier" and "to access call-identifying information," among other powers.

A lot has happened since then. Basically, all facilities-based broadband access providers and interconnected VoIP service providers must be CALEA-compliant by 14 May 2007. This means a lot of companies, of all sizes, are scrambling to deploy processes and tools to collect information in accordance with the law, as well as filing the right reports with the FCC.

If you're affected by CALEA I don't think you'll learn much from this post. However, those who do not work for ISPs might like to know a little bit about what is happening. (Note: I am not personally affected, so this post is based on some research I did this morning.) This post CALEA Mediation provides a lot of details and links, and the Wikipedia entry is good (as long as no one makes crazy changes). WISPA's mailing lists have carried several extended threads on CALEA compliance for wireless ISPs. The definitive blog on CALEA appears to be Demystifying Lawful Intercept and CALEA, by Scott Coleman, Director of Marketing for Lawful Intercept at SS8 Networks.

What started me looking at CALEA again was the story Solera Networks' CALEA Compliance Device, which talked about this Solera Networks appliance. The article mentioned OpenCALEA, which was new to me.

I checked out OpenCALEA via SVN from its OpenCALEA Google code site. Jesse Norell was helpful in #calea on irc.freenode.net. I installed the code on two FreeBSD 6.x boxes, cel433 (the "sensor") and poweredge (the box a Fed might use to collect data).

First I started a collector on the "Fed" box.

poweredge:/usr/local/opencalea_rev38/bin# ./lea_collector -t /tmp/cmii.txt
 -u richard -f /tmp/cmc.pcap

Next I started a "tap" on the sensor to watch port 6667 traffic.

cel433:/usr/local/opencalea_rev38/bin# ./tap -x x -y y -z z -f "port 6667"
 -i dc0 -d 10.1.13.2 -c

As I typed traffic in an IRC channel on a connection watched by the tap...

13:25 < helevius> This is another CALEA test

...the tap sent traffic to the Fed box.

13:26:28.795644 IP cel433.taosecurity.com.62576 >
 poweredge.taosecurity.com.6666: UDP, length 265
        0x0000:  4500 0125 80ca 0000 4011 cdf8 0a01 0a02  E..%....@.......
        0x0010:  0a01 0d02 f470 1a0a 0111 44ce 7800 0000  .....p....D.x...
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0060:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0070:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0080:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0090:  0000 0000 0000 0000 0000 0000 3230 3037  ............2007
        0x00a0:  2d30 342d 3139 5431 373a 3236 3a32 382e  -04-19T17:26:28.
        0x00b0:  3430 3600 015c 22aa c200 02b3 0acd 5e08  406..\".......^.
        0x00c0:  0045 0000 64c3 8f40 003f 0635 8245 8fca  .E..d..@.?.5.E..
        0x00d0:  1c8c d3a6 0380 331a 0b4f bb43 bfc4 6a95  ......3..O.C..j.
        0x00e0:  e080 187f ffe4 cc00 0001 0108 0a52 0b91  .............R..
        0x00f0:  ad05 c1a5 e150 5249 564d 5347 2023 736e  .....PRIVMSG.#sn
        0x0100:  6f72 742d 6775 6920 3a54 6869 7320 6973  ort-gui.:This.is
        0x0110:  2061 6e6f 7468 6572 2043 414c 4541 2074  .another.CALEA.t
        0x0120:  6573 740d 0a                             est..
13:26:28.795810 IP cel433.taosecurity.com.54296 >
 poweredge.taosecurity.com.6667: UDP, length 423
        0x0000:  4500 01c3 80cb 0000 4011 cd59 0a01 0a02  E.......@..Y....
        0x0010:  0a01 0d02 d418 1a0b 01af 3d00 7900 0000  ..........=.y...
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0060:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0070:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0080:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0090:  0000 0000 0000 0000 0000 0000 7a00 0000  ............z...
        0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0100:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0110:  0000 0000 0000 0000 0000 0000 3230 3037  ............2007
        0x0120:  2d30 342d 3139 5431 373a 3236 3a32 382e  -04-19T17:26:28.
        0x0130:  3430 3678 0000 0000 0000 0000 0000 0000  406x............
        0x0140:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0150:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0160:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0170:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0180:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0190:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x01b0:  0000 00bf 0080 0508 1cca 8f45 03a6 d38c  ...........E....
        0x01c0:  8033 1a                                  .3.

The traffic on port 6666 UDP is the content and the traffic on port 6667 UDP is a connection record of some kind.

After shutting down the tap and collector, I checked the files the collector created.

poweredge:/usr/local/opencalea_rev38/bin# cat /tmp/cmii.txt 
x, y, z, 2007-04-19T17:26:28.406, 69.143.202.28, 69.143.202.28, 32819, 6656
x, y, z, 2007-04-19T17:26:28.514, 140.211.166.3, 140.211.166.3, 6667, 32768
x, y, z, 2007-04-19T17:26:34.195, 140.211.166.3, 140.211.166.3, 6667, 32768
x, y, z, 2007-04-19T17:26:34.196, 69.143.202.28, 69.143.202.28, 32819, 6656

CMII is Communications Identifying Information. Here's the content, which is saved in Libpcap form.

poweredge:/usr/local/opencalea_rev38/bin# tcpdump -n -r /tmp/cmc.pcap -X
reading from file /tmp/cmc.pcap, link-type EN10MB (Ethernet)
13:26:28.406000 IP 69.143.202.28.32819 > 140.211.166.3.6667:
 P 1337672639:1337672687(48) ack 3295319520 win 32767
 
        0x0000:  4500 0064 c38f 4000 3f06 3582 458f ca1c  E..d..@.?.5.E...
        0x0010:  8cd3 a603 8033 1a0b 4fbb 43bf c46a 95e0  .....3..O.C..j..
        0x0020:  8018 7fff e4cc 0000 0101 080a 520b 91ad  ............R...
        0x0030:  05c1 a5e1 5052 4956 4d53 4720 2373 6e6f  ....PRIVMSG.#sno
        0x0040:  7274 2d67 7569 203a 5468 6973 2069 7320  rt-gui.:This.is.
        0x0050:  616e 6f74 6865 7220 4341 4c45 4120 7465  another.CALEA.te
        0x0060:  7374 0d0a                                st..

Jesse told me there's a lot of work to be done with this open source suite. The idea is to give businesses that can't afford a commercial CALEA solution the option of open source.

I plan to keep an eye on the OpenCALEA mailing list and try new versions as they are released.

Read More

Why UTM Will Win

We know how many words a picture is worth. The figure at left, from Boxed In by Information Security magazine, shows why Unified Threat Management appliances are going to replace all the middleboxes in the modern enterprise. At some point the UTM will be the firewall, so the gold UTM box above will also disappear. In some places even the firewall will disappear and all network security functions will collapse into switches and/or routers.

I'd like to show one other diagram from the story.

Figures like these, showing which products and their "features," are another reason UTM will replace point product middleboxes. "Hey, I read in this magazine that product X checks 7 boxes, but product Y only checks 3. Let's look at product X." These are the sorts of figures that people who are not security experts and are not interested in or capable of assessing security products like.

Just because I think this is going to happen (or is happening -- look at what your Cisco router can do) doesn't mean I like it. The more functions a box performs, the greater the likelihood that all of those functions will be performed at a mediocre level. Mediocrity is an improvement over zero security protection for some sites, but elsewhere it will not be sufficient.

I should say that the top diagram has its merits, with simplicity being the primary advantage. With so many networks having multiple "moving parts," it can be tough to stay operational and understand what's working or not working. Moving all those moving parts onto a single platform may not yield all the simplicity one might expect, however!

One way to address the weaknesses of these UTMs is to deploy stand-alone devices performing network forensics, so they record exactly what happens on the network. Using that data, one can investigate security incidents as well as measure the effectiveness of the UTM. I do not foresee network forensics collapsing into security switches/routers due to the data retention requirements and reconstruction workload required for investigations.

To survive I think network security inspection/interdiction vendors either need to be in the "meta-security" space (SIM/SEM) or in the do-it-all space (UTM). If your favorite vendor is in neither space, expect them to be acquired or go out of business.

Read More

Earth to MARS

Disclaimer: I'm going to single out a book by Cisco employees that talks about a Cisco product. I have no personal feelings about Cisco. I have friends there. I've done work for Cisco. Since I think Cisco is eventually going to own all network security functions in their switches, I may even work for Cisco one day.

This post is for all product vendors who approach understanding and defending the network in the ways described here. Wherever you read "Cisco" feel free to add products that share the characteristics I outline below.

Once again I found myself hanging in the sky last week. Trips to and from the West Coast gave me the opportunity to read Security Threat Mitigation and Response: Understanding Cisco Security MARS by Dale Tesch and Greg Abelar. This is mainly another Cisco marketing book, like Self-Defending Networks: The Next Generation of Network Security by Duane DeCapite. While I have a few thoughts on the book, I would much rather address the underlying philosophy presented by the authors. I'm fairly sure they're only repeating Cisco market-speak, but I hear the same message from many vendors, consultants, and individuals.

In this post I'd like to take issue with that message. In short, almost nothing about the approach taken by Cisco MARS (and similar products) is new or will "solve" your security problems. Unless you augment tactics and technologies like MARS, you will find yourself wondering why you spent time and effort to end up as frustrated and confused as you were pre-MARS.

I'll refer to this book as STM, short for the Security Threat Mitigation term in the title. STM is supposed to be "beyond Security Information Management" (SIM). According to STM, the five core SIM functions (pp 6-7) are:

• Collect event data


• Store data


• Correlate to show relationships (what the book calls "true power")


• Present data


• Report on, alarm on, and/or notify about data

STM starts to knock the value of SIMs by introducing the idea of "garbage in, garbage out," saying "information or events from several different sources can be 'garbage' unless they are put together in a useful way." I disagree -- garbage in always produces garbage out. The idea that a ton of garbage can be turned into something valuable (like gold from coal) is the fallacy of SIM/SEM technology.

The book tries to position "STM" as "beyond SIM" by granting STM the following attributes:

• Data reduction


• Timely attack mitigation


• End-to-end network awareness


• Integrated vulnerability assessment


• Session correlation

You are probably think what I am thinking; how is that really different from a SIM/SEM? I bet all the SIM/SEM vendors are saying "we do that already."

Things start to get really weird when the authors talk about the "advantages of a proactive security framework" (pp 14-15) compared to what everyone else must be using. STM says:

The key to this framework is the network's capability to behave actively. This does not necessarily mean to take action itself, but to automatically collect data from numerous sources and come to a decision..." (emphasis added)

... so that a person can react like we've always done. It is intellectual dishonesty to claim this product (or any other) is acting "actively" when the end result is still waiting for a person to react. Mind you, I'm not knocking reaction. Too many people seems to think proactivity is king and reactivity is evil, but sometimes there's no other option. It bugs me that Cisco is packaging manual "shunning" in a new wrapping and calling it "self-defending" and "active" when the end result is a person having to make a reactive decision.

The real problem is far more insidious, however. As has always been the case with alert-centric products, there is not enough data available to make a decision. In other words, Cisco MARS, like other products, still cannot tell me if an attack was successful.

More absurdity appears in the section (p 15) on "false-positive reduction," where three methods are given for MARS to "determine the validity of event data." They are, basically:

1. Network topology


2. Vulnerability assessment via limited network scanning


3. User determination

So, we have 1) could the attack reach the target? Guess what -- if it's a TCP connection it probably did. Next we have 2) scan to see if the IIS attack hit an Apache server; limited at best, worthless at other times. Finally -- and this kills me -- 3) let the user decide. How is this better than anything else again?

The section "Enhancing the Self-Defending Network" adds insult to injury by naming three "missing links" in the SDN addressed by STM:

1. Automated log correlation


2. Automated threat response


3. Automated mitigration

We know SIM/SEM does #1. A product that accomplished 2 and 3 would be impressive, but guess again -- MARS does neither automatically:

Automated mitigation is not yet achievable because many security devices still put out false-positive alerts, but CS-MARS makes a recommendation for mitigation and offers security responders a single click to deploy commands on devices that will stop offending traffic after the responder has analyzed the attack data. (emphasis added)

Again, it all comes back to having the data necessary to make a decision, and then letting an analyst make the decision. There's nothing proactive or special here.

STM emphasizes the speed with which one can respond, but how can an analyst even know to start the escalation process? The end of chapter 3 presents a case that aims to show "ROI" for MARS based on shutting down a spreading virus faster than a non-MARS solution. Here's the core of the problem, however:

The virus starts trying to infect other hosts... [MARS sends] an email page... to a security responder 24 hours a day, 7 days a week... The security responder gets the page and logs into CS-MARS.

And that's faster or better how?

STM demonstrates real ignorance of the sorts of data an analyst needs to make decisions regarding security events. On MARS, "forensic analysis" is "visual tools for attack-path analysis and attack propagation" (p 82) or mapping NAT'd IPs to public IPs or IPs to MAC addresses. "Attack validation" (i.e., should I worry?) is knowing "if an attack actually reached the intended destination." Furthermore, p 89 says:

[U]pon detecting an anomalous behavior, CS-MARS starts to dynamically store the full NetFlow records for the anomalous activity. This intelligent collection system provides all the information that a security analyst needs. (emphasis added)

Wrong. What else does MARS offer? Page 127 says "retrieval of raw messages" is available as a download of a zipped text file! I bet that's easy to manipulate when trying to understand alerts. On pp 229-230 we see examples of the sort of "incident ID" data available to analysts -- almost all of which is unactionable and worthless. On MARS, the analysis process consists of looking at a rule MARS used to generate an alert and then guessing at the relationship between the rule and events listed in the "detailed data" section.

I think the real problem with this approach is demonstrated by the case studies in chapter 9, which I guess Cisco sees as a validation of their approach. We read about a Trojan found at a state agency via an IDS alert (no different from non-MARS). We see a .edu respond using MARS because phone calls prompted an investigation of traffic on port 25! We read about a hospital that used a spike in traffic to a Web server as a reason to investigate the Web server (wow). A financial firm investigates high ICMP traffic, and a small business sees odd DNS names in its weekly MARS reports to find another company using its wireless access point. Honestly, is this supposed to make me a believer?

If you want to know how I recommend dealing with this and similar situations, I've already written about it. In brief, analyst must have high-fidelity, original, content-neutral data sources to investigate. That is the key term here. If you do not have such data (as provided by NSM) to investigate, you are doing alert management. And you will lose.

So what is MARS (and similar products) good for? In short, there is value in centralizing and presenting events from disparate security products. There is value in having a single window into that world, with some sort of accountability, escalation, and case management. There is value in being able to contain network-centric exploitation via centralized device control. Just remember that making the decisions to protect the enterprise requires having the proper data. NSM is one way to get that data.

Read More

Wireshark Display Filters and SSL

I mentioned the power of Wireshark display filters when analyzing 802.11 last year. Now I read Ephemeral Diffie Hellman support - NOT ! by the Unsniff guys and they tell me that they cannot decode SSL traffic which uses the ephemeral Diffie-Hellman cipher suite. I wonder what that looks like in traffic?

Thanks to Wireshark display filters, I can find a suitable packet. Here's a matching packet.

You could use syntax like this with Tshark:

tshark -V -n -r capture -R "ssl.handshake.ciphersuite == 0x39" 
...edited...
Secure Socket Layer
 TLSv1 Record Layer: Handshake Protocol: Server Hello
   Content Type: Handshake (22)
   Version: TLS 1.0 (0x0301)
   Length: 74
   Handshake Protocol: Server Hello
     Handshake Type: Server Hello (2)
     Length: 70
     Version: TLS 1.0 (0x0301)
     Random
      gmt_unix_time: Jan 26, 2007 19:32:44.000000000
      random_bytes: 76744E818415307EA6F7C14FAF4BA640F67834C1263E5065...
     Session ID Length: 32
     Session ID (32 bytes)
     Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
     Compression Method: null (0)

Maybe some of you crypto gurus can comment on their blog post -- is it possible to decrypt traffic if the cipher suite is TLS_DH_RSA_WITH_AES_256_CBC_SHA (0x0037) instead of TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)? The cited perfect forward secrecy article says Diffie-Hellman provides PFS but isn't clear on the differences between plain DH and DHE (ephemeral).

From what I read in Cryptography Decrypted, SSL/TLS uses Diffie-Hellman to create a shared pre-master secret key and six shared secret keys. Anonymous DH doesn't require either side to authenticate each other. Fixed or static DH exchanges public DH values using digital certs. Ephemeral DH exchanges public DH values signed with RSA or DSA keys. What does this mean for decryption using Wireshark, etc.? Thank you.

Read More

Pervasive Network Awareness via Interop SpyNet

In my 2005 book Extrusion Detection (p. 27) I defined the term pervasive network awarenesss (PNA):

A truly defensible network permits security administrators to achieve pervasive network awareness. Pervasive network awareness is the ability to collect the network-based information -- from the viewpoint of any node on the network -- required to make decisions.

Today while perusing Webcasts at Gigamon University, I listened to a Gigamon presentation on a "data access network" (so-called "DAN") built as the Interop SpyNet, shown earlier.

This is exactly an implementation of PNA. The Interop network and security admins can monitor the InteropNet and see traffic anywhere they like. This Interop Blog post provides a portal into discussions of the SpyNet, including history showing the idea stretches back to 1996. This shows that PNA is a good idea, and like many good ideas, not even new!

At some point I would like to see a SpyNet in person. I will be in Australia for Interop Las Vegas, but I will look into visiting New York in October.

It would be nice to see this approach built into all networks. I believe the reason it is not is that the InteropNet is a clean slate each year. If you're allowed to build a network from scratch using the latest and greatest tools and techniques, then you can see developments like this in action. Networks that have grown "organically" over a decade are likely to have plenty of dark streets and dangerous alleys where monitoring is dicey or impossible.

Update: I should mention that I dislike the term "data access network" (DAN). What could be more generic? What they should have said was "traffic access network" (TAN). Now we're describing the nature of the solution.

Read More

Solera DataEcho

I came across this press release from Solera Networks on their open source DataEcho application. DataEcho is a Windows program that captures live traffic or reads traces in Libpcap format. It's best used for interpreting Web traffic, as shown in this screen capture of a visit to www.bejtlich.net recorded in Wireshark and fed to DataEcho.



My Web site doesn't render that well because it uses CSS, but you can see how DataEcho breaks down the Web traffic. This is a similar view from Wireshark, sorted on the last column.



Besides DataEcho, I found a SourceForge project page for a Solera-related "tEthereal Network Forensic Console", which says:

Management Console to reconstruct emails, web sessions, VOIP sessions, FTP, and all known supported Internet Protocols for Network Forensics. ***UPDATE*** Project release scheduled.

That looks interesting, but no files are available. I have been exchanging emails with Solera CEO Terry Haas, so I hope to find out more about this company's projects.

Read More

Wireshark Substitute Encourages Defensible Software

Thanks to nikns in #snort-gui for pointing me towards this 23rd Chaos Communication Congress talk on an alternative to Wireshark created by Andreas Bogk and Hannes Mehnert. This blog post explains the rationale behind this new tool, still in its infancy and nowhere nearly feature-complete as Wireshark. Two implementations exist. Here is a screenshot of GUI-sniffer:



Here is a screenshot of Network Night Vision:



These applications are written in the Dylan programming language, which is new to me. There's a lang/dylan FreeBSD port, but as you can see I just tried running the Windows binaries.

The authors have written a paper (.pdf) that describes the project in detail. From the first part of the paper:

The security industry is in a paradox situation: many security appliances and analysis tools, be it IDS systems, virus scanners, firewalls or others, suffer from the same weaknesses as the systems they try to protect. What makes them vulnerable is the vast amount of structured data they need to understand to do their job, and the bugs that invariably manifest in parsers for complex protocols if written in unsafe programming languages.

Since we noticed a lack of a decent secure framework for handling network packets, we have designed and implemented major parts of a TCP/IP stack in the high level programming language “Dylan”, focusing on security, performance and code reuse.

Dylan is a high level language that provides a number of features to detect and prevent data reference failures, one of the most common sources of vulnerabilities in C software.

Bounds checks for array accesses are inserted where needed by the compiler. Also a garbage collector is used, avoiding the need to care about manual memory management, and preventing bugs from early frees or double frees. Dylan is strongly typed, so bypassing the type system by doing casts and pointer arithmetic is not possible.

Even though it is as easy to use as common scripting languages, Dylan programs are compiled to machine code. It bridges the world between dynamic and static typing by doing optimistic type inferencing: bindings can be type annotated, and types of expressions can be computed at compile time. This often eliminates type checks or function dispatch in the code.

I am not in a position to critique the programming language used or the authors' implementation. However, I think the idea of building "defensible software," or software that has the best chance possible of resisting intrusions, is a great idea. It's the software equivalent of my "defensible network architecture" idea, which describes how to build an enterprise with the best chance possible of resisting intrusions.

I will probably add this tool and approach to my classes. When I teach network forensics I describe the importance of being aware of handling malicious traffic that might seek to compromise analysis tools like Wireshark or Snort. Thus far the anti-forensics movement seems to have concentrated on denying host-centric forensics, but exploits have always been available for subverting network inspection tools.

Incidentally, there are a ton of interesting talks at the CCC this year.

Read More

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

MIB Browser

While reading a book on Nagios, I learned of net-mgmt/mbrowse, pictured above. It's not fancy -- just a graphical SNMP v1 MIB browser.

Read More

Network Forensics with NetWitness

Ten days ago I had the privilege of attending a day of product training for NetWitness. NetWitness is a real network forensics tool produced by a company of the same name. Anyone who's read my books or attended my training knows I am a big fan of open source tools. NetWitness, however, is built to facilitate investigating network traffic.

It's important to differentiate between packet collectors, protocol analyzers, and network forensics tools. Dumpcap is the prototypical packet collector. Simpler than Tcpdump and much simpler than Tshark, all Dumpcap does is record packets. It's especially suited for this role, however, because it offers native trace rotation capabilities.

Tcpdump, Tshark, and Wireshark are all protocol analyzers. Yes, Tcpdump is a protocol analyzer, although it is not as robust as Tshark or Wireshark. Protocol analyzers are suited for packet-centric inspection. For example, I used Wireshark extensively while learning about 802.11 traffic. Protocol analyzers are also helpful for network troubleshooting, with varying degrees of automated analysis. Commercial protocol analyzers are especially robust in this regard. Protocol analyzers often feature tools for rebuilding TCP sessions, but that is usually the extent of those features. Protocol analyzers also permit searching traffic, but the analyst generally must have a good grasp of what he is looking for and how to get that idea across to the protocol analyzer.

Network forensics tools are not packet-centric; they are data centric. NetWitness, for example, cares less about the underlying packets and more about the data they contain. The partial screen capture (original here) hints at NetWitness' depiction of files, accounts, and email addresses recognized in a network trace.

Investigators don't (necessarily) look at packets when they use NetWitness for network forensics. Rather, they look for useful data. One investigation might require finding all information related to a specific username. That username (or a portion of it) would be searchable in email, instant messaging, Web logins, documents, and so forth. While you could do some manual searching with tools like Ngrep or Flowgrep, NetWitness is built around discovering information and is well-suited for this process of discovery.

When you find results, they are presented within the context of the session in which they were contained. NetWitness rebuilds the session and presents it in human-friendly format. If they subject viewed an email, you will see the email. If he visited a Web page, you will see the Web page. There are limitations to this model, such as a browser displaying cache graphics instead of requesting them on the wire. However, this sort of model works very well for forensic analysts.

This second partial screen capture (original here) demonstrates two other powerful NetWitness features. First, NetWitness represents traffic using a noun-verb-adjective-like language. When you see the mention of "GET", for example, it's not necessarily an HTTP get. GET actions include FTP retrievals and other actions where a subject acquires data. This meta-language simplifies investigations by letting the analyst look for actions and not for specific protocol activities.

Second, NetWitness performs port-agnostic protocol identification. When you see "HTTP" it doesn't just mean port 80. HTTP is identified by inspecting traffic and looking for the HTTP protocol. This is an important mechanism for finding back doors and covert channels. Obviously encryption will hamper this feature, but port-agnostic protocol identification is a must-have for forensics tools.

I could say quite a bit about NetWitness, but I hope you've gotten the idea that it's a powerful tool. In case you are wondering, I am not being compensated for this review. I did get to attend the training class for free. I am also not selling NetWitness to anyone. The purpose of this review is to share insights on this tool, and to keep those of us with ties to the open source world aware of applications outside of it.

I am open to hearing from NetWitness' main competitors, Niksun and Sandstorm, if they'd like to comment. Sandstorm's NetIntercept holds a special place in my heart, since it runs on FreeBSD. NetWitness is a Windows-based product. (In production I recommend capturing traffic with a program like Dumpcap or Tcpdump, and then analyzing it in NetWitness.)

Read More

Notes for TCP/IP Weapons School Students

This note is intended for students in my TCP/IP Weapons School class at USENIX Security 2006.

These are the tools that will be discussed. Remember, this is a class on TCP/IP -- tools are not the primary focus. However, I needed something to generate interesting traffic.

• Nemesis


• Arping


• Arpdig


• Arpwatch


• Arp-sk


• Dsniff suite


• Ettercap


• Yersinia


• Fragroute


• Sing


• Gnetcat


• Packit


• Gont attacks


• ICMPshell

The traces we will analyze are available at www.taosecurity.com/taosecurity_tws_v1_traces.zip. You will need to have Ethereal, Wireshark, or a similar protocol analyzer installed to review the traces. Tcpdump might be somewhat limited for this class but you can at least inspect packets with it.

Read More

SPI Dynamics JavaScript Scanner

Ok, this is a little weird. Thanks to SecurityMonkey I just tried the SPI Dynamics JavaScript Scanner. From that page:

Imagine visiting a blog on a social site like MySpace.com or checking your email on a portal like Yahoo’s Webmail. While you are reading the Web page JavaScript code is downloaded and executed by your Web browser. It scans your entire home network, detects and determines your Linksys router model number, and then sends commands to the router to turn on wireless networking and turn off all encryption. Now imagine that this happens to 1 million people across the United States in less than 24 hours.

This scenario is no longer one of fiction.

I recommend reading the white paper (.pdf). I tried out the proof of concept on Windows 2000 as a non-admin user running the latest Firefox. Here's what I got. Now all three hosts exist, but due to known issues none are correctly detected. Still, this is a cool idea. Note that I ran the page while using a Web proxy, so all of the requests went through that device.

Read More

Beta Test Argus 3.0 and Tcpreplay 3.0

If you're a packet monkey like me, you probably use tools like Argus and Tcpreplay.

Carter Bullard is preparing to release Argus 3.0 soon, which includes a lot of community feedback. You can try the latest release candidates here. I helped testing by providing access to a box running FreeBSD 6.1 amd64.

Similarly, Aaron Turner just released a new beta version of Tcpreplay. I ran into a problem with Tcpedit on FreeBSD 6.1 i386 when running 'make'.

Try downloading and testing these beta versions and provide feedback to the authors. Thank you!

Read More

Sguil Makes 2006 Top 100 Security Tools List

Fyodor of Nmap fame has posted the results of his 2006 survey of security tools. Fyodor posted the results at his new site SecTools.org. On page 4 you'll find Sguil listed as number 85 out of 100. Unfortunately, BASE beat out Sguil at number 82. Another personal regret is seeing Argus listed after BASE at number 83. The next time Fyodor asks for suvery participation, I will have to respond!

Although the top 100 results are useful, some of the sub-categorization makes little sense. Sguil is listed in the Traffic Monitoring Tools subsection, along with Solar Winds and Nagios (?!?). The Intrusion Detection category lists BASE but not Sguil, along with Fragroute and Fragrouter (?!?). Bizarre.

Regardless, I recommend security pros familiarize themselves with all of the tools in the top 100. It makes for great discussions during job interviews, either as the employer or prospective employee.

Read More

Why Discard Your Brand?

Sometimes you have to make the best of a bad situation, with no warning. Good-bye Ethereal, hello Wireshark. Gerald Combs, original author and primary Ethereal developer, left his job at Network Integration Services, Inc. and joined CACE Technologies. Unfortunately, NIS owns the Ethereal trademark, and Mr. Combs wasn't able to take it with him. He also lost administrative rights to the servers hosting Ethereal.com, so he can't post news of the name change there. So, nearly eight years after the first public release, Ethereal is dead. Long live Wireshark -- especially with 1.0 expected very soon.

Read More