Net Optics Press Release on Book and USENIX Class

I'm a big fan of taps made by Net Optics, especially after reading advice from other manufacturers. Because I featured Net Optics taps in chapter 3 of my book, and brought one for my class network at USENIX, Net Optics published a press release on the two events today. I'd like to thank Net Optics for supporting my tap research and for giving expert advice on chapter 3.

On a related note, I came across this 1996 thread discussing early tap use.

Read More

Dru Likes My Book and Good BSD News

While visiting BSDNews.com I read Dru Lavigne's latest musings. She has some kind words on my book:

"So far, I'm really enjoying the book and appreciate Richard's logical, thorough approach and the plethora of useful URLs to additional references interspersed on nearly every page. His discussion on 'accessing traffic in each zone' is very practical and definitely written by someone who has "been there done that". And within the first 100 pages I've already come across undocumented or poorly documented BSD commands which Richard explains in detail.


My only caution to readers is that they'll enjoy the book a lot more if they bring to it a fairly solid understanding of networking, TCP/IP, and general security concepts. After all, this is an Addison Wesley, not a "teach yourself network monitoring in 24 hours". I do think that those with the networking and security background will appreciate the level of experience Richard has brought to the book. And, this point can't be championed enough: this book was written to demonstrate how open source tools on open source operating systems are ideal for network monitoring."

I'm glad a fellow BSD users appreciates the BSD information in a book on network security monitoring! Notice that the Amazon.ca listing discounts the book, and provides the table of contents and editorial reviews -- unlike Amazon.com.

Also, FreeBSD 5.3 is scheduled for a 3 Oct 04 release. This will make the 5 branch STABLE, after almost two years. Do your part by testing the release candidates when they become available.

Read More

Protecting Web Surfing from Prying Wireless Eyes

Well here I am at USENIX Security 2004, on the Town and Country Hotel's wireless network. I received an authorization code from the concierge, and no other instructions. This code wasn't a SSID since the guy after me received a different code. When I got to my hotel room, I fired up dstumbler to see what networks were available.

dstumbler wi0 -o

I found several LodgeNet access points, so I figured I'd try associating with those:

ifconfig wi0 ssid LodgeNet up

This got me associated:

ifconfig wi0

wi0: flags=8843 mtu 1500

        ether 00:04:e2:29:3b:ba

        media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)

        status: associated

        ssid LodgeNet 1:LodgeNet

        stationname "FreeBSD WaveLAN/IEEE node"

        channel 6 authmode OPEN powersavemode OFF powersavesleep 100

        wepmode OFF weptxkey 1

Next I needed an IP address:

dhclient wi0

ifconfig wi0

wi0: flags=8843 mtu 1500

        inet 10.2.2.3 netmask 0xffffff00 broadcast 10.2.2.255

        ether 00:04:e2:29:3b:ba

        media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)

        status: associated

        ssid LodgeNet 1:LodgeNet

        stationname "FreeBSD WaveLAN/IEEE node"

        channel 11 authmode OPEN powersavemode OFF powersavesleep 100

        wepmode OFF weptxkey 1



cat /etc/resolv.conf 

search 0012209.lodgenet.net

nameserver 10.2.2.254

This got me my IP and DNS settings. I was able to fire up my browser and found myself and a login screen, where I entered my super secret code. Notice there is no encryption of any kind. Wheee... watch out for driftnet...

Note: Skip to the end of this post to see a much simpler way to accomplish the same goal. Read on to see how I used to shield my Web browsing.

At this point I wanted to access sites that don't offer HTTPS-enabled logins, like Blogger and elsewhere. I turned to my SSH-based port-forwarding and tinyproxy system set up for my home network. My gateway at home has www/tinyproxy running, listening on port 8888 TCP:

moog:/root# sockstat -4 | grep 8888

nobody   tinyprox 43195    6 tcp4   172.27.20.1:8888      *:*                  

nobody   tinyprox   163    6 tcp4   172.27.20.1:8888      *:*                  

...truncated...

The /usr/local/etc/tinyproxy/tinyproxy.conf looks like this:

User nobody

Group nogroup



Port 8888

Listen 172.27.20.1



Timeout 600

Logfile "/var/log/tinyproxy.log"

LogLevel Info

PidFile "/var/run/tinyproxy.pid"

MaxClients 100

MinSpareServers 5

MaxSpareServers 20

StartServers 10



MaxRequestsPerChild 0



Allow 127.0.0.1

#List other networks allowed here, like local RFC 1918 space



ConnectPort 443

ConnectPort 563

This allows me to use this gateway as an HTTP and HTTPS proxy, but how can I access it from the hotel network? Using SSH port forwarding is the answer!

ssh -f -N -L 8888:proxy:8888 user@homegateway.com

-f says go to the background; -N says don't execute a remote command; -L says bind port 8888 TCP to the localhost, and port 8888 TCP on the proxy. Now I set up my Firefox connection settings with my "Manual Proxy Configuration" pointing to port 8888 TCP on localhost for HTTP and SSL (which takes care of HTTPS, apparently).

What is the point of this? Now when I visit a Web site, I connect through my SSH tunnel to my home gateway. The home gateway makes the necessary DNS and Web page requests. (A visit to a site like checkip.dyndns.org will show the IP of your proxy, not your workstation.) I get the results back from the proxy through the SSH tunnel. Although my HTTP traffic is still in the clear between my home proxy and the end Web site, no one on the local wireless hotel network can see where I'm going or what credentials I may be passing.

The main disadvantage of this setup is I'm sending all of my Web requests and receiving responses clear across the country, since I'm in San Diego now and my home gateway is in northern Virginia. I think it's worth it to keep people from sniffing my Blogger credentials though.

Update: Thanks to a very helpful suggestion from Jim O'Gorman, I learned I don't need to bother with Tinyproxy. I missed out on the addition of native support in ssh for a SOCKS proxy and dynamic port forwarding. All that needs to be done is this:

ssh -v -D 8888 user@homegateway.com

In your Firefox Preferences -> Connection Settings, select "Manual Proxy Configuration" and "SOCKS host" localhost, and port 8888. Click the SOCKS 4 radio button. Now, when you connect to a Web site like checkip.dyndns.org, you'll see this in your SSH terminal:

debug1: Connection to port 8888 forwarding to socks4 port 0 requested.

debug1: channel 2: new [dynamic-tcpip]

debug1: channel 2: dynamic request: socks4 host 63.209.15.212 port 80 command 1

debug1: channel 2: open confirm rwindow 131072 rmax 32768

...edited...

debug1: channel_free: channel 2: direct-tcpip: listening port

 8888 for 63.209.15.212 port 80, connect from 127.0.0.1 port

 62510, nchannels 3

This is beautiful because it also works for HTTPS:

debug1: channel 2: new [dynamic-tcpip]

debug1: channel 2: dynamic request: socks4 host 216.239.51.107 port 443 command 1

debug1: channel 2: open confirm rwindow 131072 rmax 32768

...truncated...

This makes life much easier and eliminates the need to add a proxy to your gateway. Thanks Jim!

Read More

Romanian Hacker and Friends Indicted

A friend and former Foundstone colleague informed me of the indictment of a Romanian (Calin Mateias, 24, of Bucharest) and five Americans for conspiring to steal more than $10 million US in computer equipment from Ingram Micro of Santa Ana, California. I worked this case two years ago as a Foundstone consultant and helped detect and remove the intruder's X-based back doors from Ingram Micro systems.

I commend Ingram Micro for publicly pursuing these intruders in court. This is one of the best ways to encourage other companies to go forward with prosecution, which is a form of deterrence. This CRN article says Ingram Micro is trying to reassure its value added resellers that its systems are secure. While I worked there, Ingram Micro was outsourcing its IT services to ACS, but security remained a "core competency" handled by Ingram Micro employees. As far as I am concerned, Ingram Micro handled the intrusions properly. I was very impressed by the way their CIO decided to take essentially whatever actions were necessary to remove the intruder from his network. This is one of the few times I've seen a CIO "get it."

Looking at IM's stock chart, the company seems to have taken a slight hit these past few days. The whole market has done poorly recently, so I don't attribute IM's performance to the hacker stories.

This case has appeared at CyberCrime.gov, so the public will be able to track its progress. At least one of the case studies in my The Tao of Network Security Monitoring: Beyond Intrusion Detection is based on my experience responding to this intrusion.

This InternetNews article says:

"According to officials at the Department of Justice (DoJ), the case was handled by the FBI cyber crimes squad, the Romanian National Police, 14 FBI field offices and the FBI's legal attache office in Bucharest.

Brian Hoffstadt, assistant U.S. Attorney at the DoJ, said authorities are working with the Romanian government to decide whether Mateias will be tried in Romanian or extradited to the United States to face charges.

'It's just a decision that hasn't been made yet -- which justice system is going to prosecute him,' he said.

Hoffstadt said there is still work to be done regarding the sentencing and fines that will be assessed against the defendants if they should lose their case. Mateias, if charged in a U.S. court, could get up to 90 years in prison and fined to repay Ingram Micro as well as other damages. The five Americans could face between five and 35 year prison sentences if convicted. More information will become available at the arraignment later this month."

During the incident response, I was asked when Ingram Micro would be "secure." I said they would be secure when the threat was eliminated. This could only be done via an arrest, prosecution, and conviction. Too many security professionals focus on the vulnerability side of the "risk = threat X vulnerability X asset value" equation. Sure, vulnerability is the one factor that administrators hope to control, but they can decrease the threat by supporting legal action against intruders. Ingram Micro understood this and I'm glad they worked with the authorities to arrest these perpetrators.

Read More

Hints on Using Oinkmaster and Sguil

I released an updated Sguil Installation Guide today that shows how to replace the Snort stream4 keepstats-based session data collection system with John Curry's SANCP code. SANCP is a better option than stream4, as SANCP tracks not only TCP like stream4 but also UDP and ICMP. The flows are also easier to work with, since they tend to occupy single entries.

I've also been experimenting with the best way to use Oinkmaster with my preferred directory layouts. When Oinkmaster runs, it works in the directory specified. For example:

perl ./oinkmaster.pl -b /tmp -o /usr/local/etc/snort/rules

 -C /usr/local/etc/snort/oinkmaster.conf

This syntax will tell Oinkmaster to place the files it manipulates in the /usr/local/etc/snort/rules directory. Besides the .rules files, this includes other important files:

    -> classification.config

    -> gen-msg.map

    -> reference.config

    -> sid-msg.map

    -> threshold.conf

    -> unicode.map

I like to keep these in /usr/local/etc/snort. To deal with this, I replaced these files in /usr/local/etc/snort with symlinks to the real files in /usr/local/etc/snort/rules:

orr:/usr/local/etc/snort# rm classification.config gen-msg.map reference.config  

 sid-msg.map threshold.conf unicode.map 

orr:/usr/local/etc/snort# ln -s rules/classification.config  classification.config

orr:/usr/local/etc/snort# ln -s rules/gen-msg.map gen-msg.map

orr:/usr/local/etc/snort# ln -s rules/reference.config  reference.config

orr:/usr/local/etc/snort# ln -s rules/sid-msg.map  sid-msg.map

orr:/usr/local/etc/snort# ln -s rules/threshold.conf threshold.conf

orr:/usr/local/etc/snort# ln -s rules/unicode.map unicode.map

This may seem a waste of time, but I have /usr/local/etc/snort coded into many of the Sguil config files as the location of these various .conf and .map configuration files.

Read More

Security Threat Profile in 2600 Magazine

2600 Magazine isn't the magazine I recommend to learn security tools and techniques, but the Summer 2004 issue has one article which justifies spending $5.50 to buy the whole issue. "A Guide to Internet Piracy" is a 4-page introduction to the "warez scene." The author, b-bstf, describes the piracy "food chain," from top to bottom:

- Warez/release groups: people who release warez to the warez community; often linked to the site traders
- Site traders: people who trade the releases from the above groups on fast servers
- FXP board users: script kiddies who scan/hack/fill vulnerable computers with warez
- IRC kiddies: users of IRC who download using XDCC bots or Fserves
- KaZaA kiddies: Users of KaZaA and other peer to peer programs

If you'd like to know how this community works and why they're interested in your servers or home workstations, buy the Summer 2004 2600 magazine.

Read More

Review of Defend IT Posted

Amazon.com just posted my four star review of Defend IT. From the review:

"I commend ch 2 ('Home Architecture') for insights I find lacking in most books on intrusion detection or incident response. The authors astutely state on p. 26 and 33: 'this incident was not discovered by flashing lights and alerts set off by an IDS... In fact, there was no early indication of a network compromise.' This explains the authors' next recommendation: 'It is a good idea to keep access logs that are as detailed as possible -- at least with respect to inbound and outbound connections... Though you may not use these logs on a regular basis, for those instances when you need them, especially including investigations of network compromise, they are invaluable." Exactly!"

Although I didn't mention it in the review, I found the authors' use of Cenzic's Hailstorm vulnerability testing software to generate IDS alerts, and Mercury LoadRunner to load the network, to be interesting. I had heard of Hailstorm but I'm not convinced it's an appropriate technology for assessing the effectiveness of an IDS.

If you read my review you'll notice I cautioned the authors about sanitizing data about clients. If you think you've identified the organization documented in chapter 4, email me at taosecurity at gmail dot com. I have my guess...

Read More