Bay Auction for "The Best Sr. Network/Security Engineer"

I searched for "VMS Alpha" today at eBay and found this item for auction by niteraven-99. This guy has put himself up for bid!

"You are bidding on myself to work at your company.

I will relocate at my expense and honor any offers received through eBay or otherwise.

Here is my information.

Over 15 years of extensive experience in the Information Technology Industry. Strengths are in networking, security, firewalls, LAN/WAN, Web Server, Application Server, SQL Server, and Oracle Server technologies including infrastructure design, integration, implementation, performance testing, problem resolution, security and network design, Firewall and IDS Implementation using a variety of platforms and products as well as, managerial and strong leadership skills."

The "buy it now" price is $100,000 and the starting price is $50,000. Hurry! The auction ends Jan-30-04 11:57:37 PST.

US-CERT National Cyber Alert System

ZDNet reports on the new National Cyber Alert System, also called the "National Cyber Advisory System." (Two names mean they're off to a great start I guess?) This portion of the new US-CERT provides the public with technical and non-technical email bulletins. I subscribed to both technical lists but have yet to hear back from the mail server. According to the press release:

"The new National Cyber Alert System security suite of products includes:

Cyber Security Tips: Targeted at non-technical home and corporate computer users, the bi-weekly Tips provide information on best computer security practices and "how-to" information.

Cyber Security Bulletins: Targeted at technical audiences, Bulletins provide bi-weekly summaries of security issues, new vulnerabilities, potential impact, patches and work-arounds, as well as actions required to mitigate risk.

Cyber Security Alerts: Available in two forms - regular for non-technical users and advanced for technical users - Cyber Security Alerts provide real-time information about security issues, vulnerabilities, and exploits currently occurring. Alerts encourage all users to take rapid action."

Another Internet Explorer Hole

This Slashdot thread discusses a new Internet Explorer hole posted to NT-BugTraq. A good story at Infoworld makes these comments:

"This hole could easily be combined with another Explorer spoofing problem discovered in December.

The previous spoofing problem allowed Explorer users to think they were visiting one site when in fact they were visiting somewhere entirely different. The implications are not only troublesome, but Microsoft’s failure to include a fix for the problem in its January patches has led many to believe it cannot be prevented.

If the same is true for this spoofing issue, then it will only be a matter of time before someone who thinks they are visiting one website and downloading one file will in fact be visiting somewhere entirely different and downloading whatever that site’s owner decides.

We also have reason to believe there is no fix. It may be that today’s flaw is identical to one found nearly three years ago by Georgi Guninski in which double-clicking a link in Explorer led you to believe you were downloading a text file but were in fact downloading a .hta file.

In both cases, the con is created by embedding a CLSID into a file name. CLSID is a long numerical string that relates to a particular COM (Component Object Model) object. COM objects are what Microsoft uses to build applications on the Internet. By doing so, any type of file can be made to look like a “trusted” file type i.e. text or pdf.

Guninski informed Microsoft in April 2001. The fact that the issue has been born afresh suggests rather heavily that the software giant has no way of preventing this from happening. "

This is ridiculous. How long will corporate America tolerate this before abandoning Internet Explorer for Mozilla? Unfortunately, in complete violation of all good software design principles, IE is tightly integrated into the Windows desktop. Running Mozilla is only part of the solution. Abandoning Microsoft for Mac OS X on the desktop is a better idea. I run FreeBSD 5.2 on my laptop but that's not the best idea for normal consumers.

For another essay on fundamental Windows flaws, read Shatter Attacks - How to Break Windows.

Installing a Single Port

Thanks to this thread I learned how to install a single port that doesn't appear in the ports tree. For example, GNU netcat just appeared at Freshports.org on 12 Jan. I wanted to install this one port to a FreeBSD 4.9 REL box that hasn't ever updated its port tree, as shown here:

moog# ls -al /usr/ports/INDEX*
-rw-r--r--  1 root  wheel  4003057 Oct  2 16:55 /usr/ports/INDEX
-rw-r--r--  1 root  wheel  4036779 Aug 15 21:56 /usr/ports/INDEX-5

I visited /ports/net/gnetcat and chose the download this directory in tarball option. This copied gnetcat.tar.gz to my system, and I moved it to /usr/local/ports/net. Next I extracted it and ran make and make install:

moog# tar -xzvf gnetcat.tar.gz 
gnetcat/
gnetcat/Makefile
gnetcat/distinfo
gnetcat/pkg-descr
gnetcat/pkg-plist
gnetcat/files/
gnetcat/files/patch-src-udphelper.c
moog# cd gnetcat
moog# make && make install
>> netcat-0.7.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
>> Attempting to fetch from http://us.dl.sourceforge.net/netcat/.
Receiving netcat-0.7.1.tar.bz2 (325687 bytes): 45%
...edited...

When done I did a "rehash" and found gnetcat on my system:

moog# rehash
moog# which gnetcat
/usr/local/bin/gnetcat
moog# gnetcat -h
GNU netcat 0.7.1, a rewrite of the famous networking tool.
Basic usages:
connect to somewhere:  gnetcat [options] hostname port [port] ...
listen for inbound:    gnetcat -l -p port [options] [hostname] [port] ...
tunnel to somewhere:   gnetcat -L hostname:port -p port [options]

Mandatory arguments to long options are mandatory for short options too.
Options:
  -c, --close                close connection on EOF from stdin
  -e, --exec=PROGRAM         program to exec after connect
  -g, --gateway=LIST         source-routing hop point[s], up to 8
  -G, --pointer=NUM          source-routing pointer: 4, 8, 12, ...
  -h, --help                 display this help and exit
  -i, --interval=SECS        delay interval for lines sent, ports scanned
  -l, --listen               listen mode, for inbound connects
  -L, --tunnel=ADDRESS:PORT  forward local port to remote address
  -n, --dont-resolve         numeric-only IP addresses, no DNS
  -o, --output=FILE          output hexdump traffic to FILE (implies -x)
  -p, --local-port=NUM       local port number
  -r, --randomize            randomize local and remote ports
  -s, --source=ADDRESS       local source address (ip or hostname)
  -t, --tcp                  TCP mode (default)
  -T, --telnet               answer using TELNET negotiation
  -u, --udp                  UDP mode
  -v, --verbose              verbose (use twice to be more verbose)
  -V, --version              output version information and exit
  -x, --hexdump              hexdump incoming and outgoing traffic
  -w, --wait=SECS            timeout for connects and final net reads
  -z, --zero                 zero-I/O mode (used for scanning)

Remote port number can also be specified as range.  Example: '1-1024'

I plan to test gnetcat to see how it compares to the original nc.

Review of Introduction to Microprocessors Posted

Amazon.com just posted my five star review of Introduction to Microprocessors. From the review:

"John Crisp's Introduction to Microprocessors (ITM) is an excellent book. It has a low average score because the author posted the first review with zero stars, which could be the result of an Amazon.com error. I loved this book. It gets right to the heart of the matter regarding the operations of microprocessors. Anyone who wants to really know what happens inside their CPU will love ITM too."

I learned a second edition was just published, so I hope to read and review that book soon.

Blogger is "Atom-Enabled"

I learned by reading the Blogger Knowledge Base that Blogger now exports Blog feeds in the Atom API. This means if your newsreader is Atom enabled, you can subscribe to it like a RSS feed. I found XML-Atom-0.05 at search.cpan.org and saw it was in the FreeBSD ports tree.

I first tried NewsMonster which integrates with Mozilla and supposedly supports Atom, but encountered an error when trying to run it.

I next tried BottomFeeder, and found the precompiled Linux version worked fine using FreeBSD's Linux application binary interface (ABI). If you use BottomFeeder to access http://taosecurity.blogspot.com/atom.xml, you'll see the screen shot at left.

Review of Intrusion Detection and Prevention Posted

Amazon.com just posted my three-star review of Intrusion Detection and Prevention. From the review:

"I had high hopes for "Intrusion Detection and Prevention" (IDAP) as it is the first book to devote chapters to different vendor IDS products. It's also the first to explicitly mention the buzzword "intrusion prevention" in its title. Unfortunately, the book does not deliver the value I expected...

I took exception to some of the authors' conclusions. (Keep in mind a team wrote this book.) A cheap shot on page 187 shows the ISS chapter author doesn't understand what real analysts need to "trust" their IDS: "These increases in product signatures have given more customers the capability to trust the comprehensive nature of RealSecure over every other product, including the freeware power player, Snort." Analyst trust is built on transparency and validation, meaning he can see why the product generated an alert, and use additional data to confirm its validity. Snort and NFR offer this; ISS does not. Furthermore, if you don't like how Snort works, you can modify the source code -- try that with a proprietary system."

Using Sysctl on FreeBSD

I read a thread on FreeBSD-Security about seeing ARP messages on FreeBSD servers acting as firewalls or gateways. Essentially FreeBSD reports seeing the MAC address for the upstream gateway flip-flop. In other words, the upstream gateway reports MAC address X, then Y, then X, and so on.

The replies in the thread reported using sysctl to change kernel state. How could you figure this out if you didn't know the appropriate variable to change?

First, use grep with sysctl to see if any variables involve ARP:

bash-2.05b$ sysctl -a | grep -i arp
net.link.ether.inet.log_arp_wrong_iface: 1
net.link.ether.inet.log_arp_movements: 1

These look interesting. What do they mean?

bash-2.05b$ sysctl -d net.link.ether.inet.log_arp_wrong_iface
net.link.ether.inet.log_arp_wrong_iface: log arp packets arriving on the wrong interface

bash-2.05b$ sysctl -d net.link.ether.inet.log_arp_movements
net.link.ether.inet.log_arp_movements: log arp replies from MACs different
 than the one in the cache

We can disable either of these variables using syntax like the following:

bash-2.05b$ sudo sysctl net.link.ether.inet.log_arp_wrong_iface=0
Password:
net.link.ether.inet.log_arp_wrong_iface: 1 -> 0

You can set it back to the default by setting the value=1. To make this a permanent change, make the following entry in the /boot/loader.conf:

net.link.ether.inet.log_arp_wrong_iface: 1

BSD for Linux Users

I just finished reading an excellent article called BSD for Linux Users by Matthew D. Fuller. He gets to the heart of the matter to describe how Linux and BSD are different. Here's an ex cerpt on the idea of the BSD base system:

"The concept of the "base system" is something that, I think, causes the most trouble for people used to the Linux methodology. Which is perfectly understandable, because the whole idea just doesn't even exist in the Linux world.

Linux, from the start, was just a kernel. Without getting into the eternal debate of what an "operating system" precisely consists of, it's easy to state that a kernel by itself isn't very useful. You need all the userland utilities to make it work. Linux has always been a conglomerate; a kernel from here, a ls from there, a ps from this other place, vim, perl, gzip, tar, and a bundle of others.

Linux has never had any sort of separation between what is the "base system" and what is "addon utilities". The entire system is "addon utilities". MySQL is no different from ls from KDE from whois from dc from GnuCash from ... Every bit of the system is just one or another add-on package.

By contrast, BSD has always had a centralized development model. There's always been an entity that's "in charge" of the system. BSD doesn't use GNU ls or GNU libc, it uses BSD's ls and BSD's libc, which are direct descendents of the ls and libc that where in the CSRG-distributed BSD releases. They've never been developed or packaged independently. You can't go "download BSD libc" somewhere, because in the BSD world, libc by itself is meaningless. ls by itself is meaningless. The kernel by itself is meaningless. The system as a whole is one piece, not a bunch of little pieces."

He explains the ports tree:

"The difference between ports and RPM's isn't just that ports compile and RPM's just install. Ports are designed to cover the full range of bits and pieces of installing stuff; encoding and tracking and installing dependencies, packaging, installing and deinstalling, local changes necessary to build on your system, compile-time configuration tweaks... all those things. An RPM is just a binary package. If you want to auto-install dependencies, you have to have a higher-level tool like urpmi or apt-get to do it. And, since it's binary, you have to deal with library versioning conflicts, or missing compile options, or any of the other limitations you incur by not building it on your own system.

And further, ports, like the rest of the BSD systems, are centralized... all those files in that big directory tree are maintained by the FreeBSD project itself. When somebody wrote KDE, for instance, it didn't magically appear in ports trees everywhere. Somebody had to write all the necessary "glue" to build a port for it, then commit the files into the FreeBSD CVS repository so it would be in the ports collection. So again, there's some level of assurance that it works with other things in the ports collection. Any dependencies it has will be there, because it can't declare a dependency on something not in ports."

He also talks about release engineering:

"In a very real sense, BSD systems are constantly developed; I can always update my system to the absolute latest code, irrespective of "releases". In Linux, that doesn't really have as much meaning, because the release process is very different. I think the most appropriate verb for a Linux release is "assembled". A Linux release is assembled from version A.B of this program, plus version C.D of this program, plus version E.F of this program... all together with version X.Y.Z of the Linux kernel. In BSD, however, since the pieces are all developed together, the verb "cut" makes a lot more sense; a release is "cut" at a certain time."

I highly recommend reading this article.

Microsoft Provides Mozilla 1.6?

Ok, not really. This is the work of a Slashdot poster offering this link. He exploits a vulnerability in Internet Explorer explain by CERT, for which there is not yet a patch...other than running Mozilla.

Network Sorcery Protocol Reference

While doing book research today I discovered the protocol resources at Network Sorecery. They clearly break down protocols by network, transport, and application layers by noting the following:

• Network layer protocols are assigned EtherTypes, like 0x0806 for ARP, 0x0800 for IPv4, and 0x86DD for IPv6.


• Transport layer protocols are assigned IP protocol values, like 1 for ICMP, 6 for TCP, 17 for UDP, 132 for Stream Control Transmission Protocol, and so on.


• Application layer protocols are assigned one or more SCTP, TCP or UDP port numbers, like 23 for Telnet, 80 for HTTP, and so on.

Most people argue about what protocols do and forget how they are carried. I like the way Network Sorcery cuts through this issue.

Besides describing all of these protocols and showing their header formats, Network Sorcery also links to the RFCs defining their operation.

Installing FreeBSD 5.2 REL on the Thinkpad a20p

Today I installed FreeBSD 5.2 REL on my Thinkpad a20p. I used the FreeBSD Laptop Compatability List and Paul Roe's example for guidance. I posted my results, such as dmesg output, and my XF86Config for others to reference.

Here are a few tweaks to get the system working:

I enabled sound with these entries in /boot/loader.conf

snd_pcm_load="YES"
snd_csa_load="YES"

I enabled my SMC wireless NIC with this entry in /etc/rc.conf:

ifconfig_wi0="inet 192.168.2.3 netmask 255.255.255.0
 ssid myssid wepkey 0xmywepkeyinhex wepmode on"

My biggest challenge and favorite achievement was getting Java to work properly. A visit to the FreeBSD Foundation Java site showed it was behind the times. It did give me a pointer to the FreeBSD-Java mailing list, which would prove to be invaluable. I eventually found FreeBSDDom and their patch sets of the Sun JDKs. I also read about the FreeBSD Java Project's work.

I decided to give the /usr/ports/java/jdk14 port a try. I saw it used the 1.4.2p5 patch set, so I downloaded it to /usr/ports/distfiles. Next I downloaded the following and also placed them in /usr/ports/distfiles:

j2sdk-1_4_2-bin-scsl.zip
j2sdk-1_4_2-mozilla_headers-unix.zip
j2sdk-1_4_2-src-scsl.zip
j2sdk-1_4_2_02-linux-i586.bin

The first three were available at the Sun Java 2 Download site. The last was in a different section, but it can be found here (or more generically, here).

Then, within /usr/ports/java/jdk14, I executed:

make
make install

Along the way I received some messages which prompted me to act:

This Java VM will attempt to obtain some system information by
accessing files in linux's procfs.  You must install the Linux
emulation procfs filesystem for this to work correctly.  The JVM
will exhibit various problems otherwise.  This can be accomplished
by adding the following line to your /etc/fstab file:

 linprocfs   /compat/linux/proc   linprocfs   rw   0  0

and then, as root, executing the commands:

kldload linprocfs
mount /compat/linux/proc

I did as the instructions warned. At one point the installation stopped with this error:

ERROR: JAVAWS_BOOTDIR does not point to a valid Java 2 SDK
       Check that you have access to
           /usr/local/linux-sun-jdk1.4.2_02/bin/java
       and/or check your value of ALT_JAVAWS_BOOTDIR.

ERROR: BOOTDIR does not point to a valid Java 2 SDK
       Check that you have access to
           /usr/local/linux-sun-jdk1.4.2_02/bin/java
       and/or check your value of ALT_BOOTDIR.

Exiting because of the above error(s).

gmake: *** [post-sanity] Error 1

I realized I needed to install the linux-sun-jdk14 port so I took these actions:

cd /usr/ports/java/linux-sun-jdk14/
make && make install

After that I returned to the /usr/ports/java/jdk14 directory, executed 'make', and continued installing the JDK. I received instructions on additions to my XF86Config file:

URW font collection for X.

You'll have to add /usr/X11R6/lib/X11/fonts/URW
to your X font path by either:

$ xset fp+ /usr/X11R6/lib/X11/fonts/URW
$ xset fp rehash

or by adding it to your X-server configuration file

I made the change as apparent in my XF86Config file. Once the JDK installation finished, I added Mozilla as a package. To get Mozilla to work with Java, I added the following symlink:

mkdir /usr/X11R6/lib/browser_plugins
ln -s /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so
 /usr/X11R6/lib/browser_plugins/libjavaplugin-oji.so

At this point I thought I was ready to go, but Java refused to work. Thanks to a FreeBSD-Java thread, I learned the JDK didn't work well with IPv6. I disabled IPv6 by a sysctl command and made the appropriate entry in /etc/sysctl.conf:

sysctl net.inet6.ip6.v6only=0
echo "net.inet6.ip6.v6only=0" >> /etc/sysctl.conf

When I fired up Mozilla, I was able to see the Java security news plug-in worked.

The last challenge was setting up OpenOffice.org. Luckily I found precompiled packages for FreeBSD 5.2 REL. Here are the highlights:

pkg_add -v openoffice-1.1.0_1.tbz
Requested space: 306061008 bytes, free space: 4291790848 bytes
 in /var/tmp/instmp.TMcvUV
dckage openoffice-1.1.0_1 registered in /var/db/pkg/openoffice-1.1.0_1
OpenOffice.org Build 1.1.0 Personal Install How-To
Written by:     Martin Blapp 

There are some wrappers installed for fast startup.
Add "${PREFIX}/bin/" to your PATH and you will be able
to use them.

${PREFIX}/bin/openoffice-1.1
${PREFIX}/bin/openoffice-1.1-sagenda
${PREFIX}/bin/openoffice-1.1-scalc
${PREFIX}/bin/openoffice-1.1-sdraw
${PREFIX}/bin/openoffice-1.1-setup
${PREFIX}/bin/openoffice-1.1-sfax
${PREFIX}/bin/openoffice-1.1-simpress
${PREFIX}/bin/openoffice-1.1-spadmin
${PREFIX}/bin/openoffice-1.1-sweb
${PREFIX}/bin/openoffice-1.1-swriter

If you have chosen US-ASCII as locale, you cannot load
and save documents with special characters and these
characters are also not available in swriter and scalc.

I ran 'openoffice-1.1' and chose 'local installation'. I specified '/usr/local/jdk1.4.2/jre' for my Java Runtime Environment, and OO found jdk1.4.2-p5 and used it. When I was done with the installation process, I reran 'openoffice-1.1', and found myself inside OO.

Aside from the length of time it took to install Java, the process worked very well.

My last work for the day involved checking to see if the laptop could suspend. I had downloaded and used IBM's stndalhd.exe program prior to installing FreeBSD to create a suspend partition. It created a partition of type 160 decimal or 0xa0. Unfortunately it did not create the partition table properly, as my first install of FreeBSD complained during setup and then refused to boot when done. I scrapped the old partition table and created a partition type 160 inside FreeBSD's fdisk during the FreeBSD installation. Once FreeBSD was installed I used newfs_msdos to create a FAT partition for my suspend work.

I allowed FreeBSD to boot with ACPI enabled. By experimenting I found I could suspend the laptop with acpiconf:

• turn off laptop: 'acpiconf -s 5'


• suspend to disk: 'acpiconf -s 3'


• wake up from suspend: 'Fn' key or raise cover after 'acpiconf -s 3' and closing cover

I found 'shutdown -h now' didn't work completely with ACPI, and shutting the laptop cover had no effect. When I return from a suspend, I have to reinitialize wi0 and HUP moused. The built-in NIC, fxp0, works fine after suspending.

Overall I'm really pleased with this new FreeBSD distro and I'm using it as my primary system.

Update: I've decided to abandon ACPI. I boot with ACPI disabled and use the Fn-F4 key to suspend the laptop. When it resumes I re-ifconfig any needed interface and run ntpdate to bring the system clock up to speed.

I installed xmms and mplayer. After a fresh reboot each works, but after resuming from suspending neither works. This appears to be a hardware issue as others report having the same problem with Linux.

FreeBSD 5.2 Released Today!

FreeBSD 5.2 was released today. Be sure to read the errata if you have trouble with ACPI. As soon as I download the .iso I need from a mirror I will install 5.2 REL on my Thinkpad laptop. I still use 4.9 on my production systems, although many people report good results with 5.x on their servers.

I was sad to see Slashdot repeated last year's debacle with FreeBSD 5.0 by posting news of the "release" prior to the official annoucement. What's wrong with them?

I encourage all FreeBSD users to support the project by buying a CD-ROM or T-shirt from FreeBSDMall. I've started buying copies of the releases, and for less than $40 you get four CDs. They include the install CD, and live CD-based distro, and two CDs of precompiled packages. The polo shirt pictured at left is really sharp too, not a flimsy piece of clothing.

Laptopsforless.com Laptop Parts

Slashdot redeemed itself today by posting a good thread on obtaining parts for your laptop. I checked out Laptopsforless.com and was able to browse for parts for my Thinkpad. While my favorite place to buy RAM remains Crucial, I'll keep Laptopsforless in mind when I need a battery or AC adapter.

TCP Sequence Numbers Explained

Today I was reading a new book on "intrusion detection and prevention" which repeats an often misinformed interpretation of TCP sequence numbers. The book said "When either party wishes to send data to the other, it will send a packet with the ACK flag set, with an acknowledgement of the last sequence number (in the Acknowledgement field) received from the remote host, and with its own sequence number incremented to reflect the amount of data being transmitted." This gets both the acknowledgement and sequence numbers wrong.

The following excerpt from my upcoming book The Tao of Network Security Monitoring explains how TCP sequence and acknowledgement numbers work by following a TCP session through Ethereal:

This brief section uses Ethereal screen captures to definitively explain TCP sequence numbers. 192.168.2.4 is a workstation named “caine” and 204.152.184.75 is ftp.netbsd.org, contracted to “netbsd” here.

Packet 1 shows a SYN from caine to netbsd. The TCP segment’s ISN is 1664882716. The hexadecimal shorthand is highlighted. Directly to the right of the ISN is a 4 byte value of zeroes. This is where the acknowledgement number would reside, if the ACK flag were set.



Packet 2 shows a SYN ACK from netbsd to caine. Netbsd sets a Initial Response Number of 829007135 and an ACK value of 1664822717. The ACK value is highlighted in the figure. ACK 1664822717 indicates that the next real byte of application data netbsd expects to receive from caine will be number 1664822717. That ACK value also indicates netbsd received a “byte of data” implied in the SYN packet caine sent, whose ISN was 1664822716. No bytes of data were actually sent. This is an example of a sequence number being “consumed” in the three-way handshake.



Packet 3 shows the completion of the three-way handshake. Caine sends an ACK 829007136, which acknowledges receipt of the one “byte of data” implied in the SYN ACK packet netbsd sent, whose IRN was 829007135. 829007136 indicates that the first real byte of data caine expects to receive from netbsd will be number 829007136. Again, no bytes of application data have actually been sent by either party. This is another example of a sequence number being “consumed” in the three-way handshake.



Packet 4 shows the first real bytes of application data sent from netbsd to caine. Netbsd still sends ACK 1664882717 because that is the sequence number of the first real byte of application data netbsd expects to receive from caine. Netbsd’s sequence number is 829007136, meaning the first byte of application data in packet 4 is numbered 829007136. That is the byte with hexadecimal value 0x32, which is ASCII 2 of the first digit in the “220” status code sent by Netbsd’s FTP service. You can see “32 32 30” in the line below the highlighted acknowledgement number in the screen capture.

Observe that this packet bears a sequence number indicating the sequence number of the first byte of application data in the packet. The value of this sequence number bears no relationship with the amount of application data in the packet. If netbsd sends 58 bytes or 580 bytes, it still uses sequence number 829007136, because that is the number of the first byte of data it promised to send to caine.

Ethereal reports the “next sequence number” to be 829007194. This value does not specifically appear anywhere in the packet. It is calculated by adding the number of bytes of application data in the packet (58) to the sequence number of the first byte of data in the packet (829007136). This does not mean the last sequence number of data in this packet is 829007194. Rather, the sequence number of the last byte of data is 829007193. How is this so? The following table tracks the sequence numbers of the bytes of application data in this packet.

Sequence Number	Hex Rep	ASCII
829007136	32	2
829007137	32	2
829007138	30	0
829007139	2d	-
...50 bytes omitted...
829007190	79	y
829007191	2e	.
829007192	0d	carriage return
829007193	0a	new line

This fact probably accounts for most of the misunderstandings regarding the relationship between sequence numbers and byte counts of application data.



Packet 5 shows caine acknowledges receipt of bytes 829007136 through 829007193 from netbsd by sending ACK 829007194. This means the next byte of application data caine expects to receive from netbsd will be number 829007194. Caine’s own sequence number 1664882717 is unchanged as it has not yet sent any application data.



Packet 6 shows netbsd sending more data to caine. The “next sequence number field” is highlighted to show there is no corresponding real field in the TCP header of the bottom pane. The value 829008140 means netbsd sent 946 bytes of application data. Netbsd sets its sequence number as 829007194 to represent the first byte of data in this packet. The sequence number of the last byte of application data is 829008139. Its acknowledgement number remains at 1664882717 because caine still has not sent any application data.



Packet 7 shows caine acknowledges receipt of 946 bytes of application data with an ACK 829008140. This means the last byte of data caine received was number 829008139. Caine expects to receive 829008140 next from netbsd. Caine’s sequence number is still set at 1664882717 because it has not yet sent any application data to netbsd.



In packet 8 caine finally sends its own application data to netbsd. Caine transmits 11 bytes, starting with sequence number 1664882717 (0x55, or ASCII U) and ending with 1664882727 (0x0a, or new line). Caine’s acknowledgement number stays at 829008140 because that is the number of the next byte of application data caine expects from netbsd. Should caine send more application data, the first byte will be number 1664882728, as depicted in the “next sequence number” calculated by Ethereal.

As we saw earlier when netbsd sent application data, the sequence number carried in the packet is the number of the first byte of application data. Here it is 1664882717, which is what caine promised to send netbsd way back in packet 2.



Packet 9 shows netbsd acknowledges bytes 1664882717 through 1664882727 by sending an ACK 1664882728. Netbsd sends 45 bytes of its own application data, demonstrating that TCP allows acknowledging data sent by another party while transmitting new data to that party.



By now you should have a good understanding of how TCP sequence numbers work. We skip packets 10, 11, and 12 as they offer nothing new in terms of watching sequence numbers. Packet 13 begins the TCP “graceful close” or “orderly release,” by which each side of the conversation closes the session. We can inspect the one-line summary of the sequence and acknowledgement numbers in the next screen shot to follow the closing of the session.

Packet 13 shows netbsd terminates the session by sending a FIN ACK packet. Netbsd sets its ACK number at 1664882734, indicating it has received bytes of data through 1664882733 from caine. Packet 13 bears a sequence number of 829008199.

Packet 14 shows caine’s response, an ACK 829008200. This acknowledges receipt of the “byte of data” implied by packet 13 from netbsd. This is similar to the way sequence numbers were “consumed” during the three-way handshake to confirm acknowledgement of SYN and SYN ACK packets. Packet 14 is caine’s way of saying it received the FIN ACK from netbsd.

Packet 15 is caine’s own FIN ACK. Caine uses ACK 829008200, the same as it used in packet 14. Caine sets its own sequence number at 1664882734. Netbsd will use this as the basis for its own acknowledgement in packet 16.

Why doesn’t caine combine packets 14 and 15 into a single FIN ACK? The reason lies with the work being done at different levels of the OSI model. Packet 14 shows the TCP layer talking. By immediately replying with an ACK to netbsd’s FIN ACK, caine indicates its receipt of packet 13. Caine’s TCP/IP stack then needs to check with its FTP client application to see if it has any more application data to send. When the stack learns the FTP client is done with the session, caine sends its own FIN ACK in packet 15.

Packet 16 is netbsd’s acknowledgement of caine’s FIN ACK. Netbsd sets its ACK value to 1664882735, indicating it received the “byte of data” implied by packet 15 from caine. This is another consumption of a sequence number used to complete the TCP graceful clo



I hope this helps dispel the fog surrounding TCP sequence numbers.

New Taps from NetOptics

Thanks to NetOptics, I've deployed their 10/100BaseT tap as a replacement for my Finisar model. The NetOptics device is intriguing in that it ships with redundant power inputs. I use a FreeBSD-based solution documented here to combine the two tap TX outputs into a single virtual interface. Beyond the Ethernet-based products shown here, NetOptics offers a variety of alternatives, including devices for tapping multiple ports.

Shortly I hope to try NetOptics new 10/100BaseT Port Aggregator Tap. This device has a single output, which removes the need for combining two TX outputs. Unlike a competitor's product, the Aggregator Tap specifically addresses the issues of combining streams which may exceed 100 Mbps:

"For cases where the NIC’s capacity is exceeded – for instance, if there is a traffic burst, and the 100 Mbps NIC is now receiving 140 Mbps of traffic – port buffering is offered as an additional innovative feature to help prevent data overload. Buffered memory handles an overflow of up to one megabyte per side of the full-duplex connection. This memory clears automatically once the NIC’s utilization is again below 100 percent."

NetOptics also plans to move the product to a PCI-based platform:

"Offered first in 10/100 models, Port Aggregator Taps will be available in a variety of configurations, including a standard rack-mount model, or a PCI-based unit designed for direct insertion into monitoring hardware. Port Aggregator Taps may also be ordered with active response capability, enabling injection of responses such as TCP resets back into the original network link."

A FreeBSD Kernel Module for Generating NetFlow Records

While visiting SourceForge, I queried for NetFlow and found ng_netflow, a NetGraph-based kernel module for FreeBSD. The project was started this week and the first release, ng_netflow 0.1, occurred three days ago! The author warns that this early version is for demonstration only, as the method ng_netflow uses to time out flow records can be extremely slow. With ng_netflow in the kernel, however, this method has the possibility for being much faster than userland implementations like Fprobe.

I tested ng_netflow on a FreeBSD 4.9 system named janney, with IP address 172.27.20.5. To use ng_netflow, download the archive and extract it. Change into the ng_netflow-0.1 directory and execute ‘make’.

janney# tar -xzf ng_netflow-0.1.tar.gz
janney # cd ng_netflow-0.1
janney # ls
CVS             Makefile        flowctl
ChangeLog       README          ng_netflow
janney # make && make install
...edited...
===> ng_netflow
install -o root -g wheel -m 555   ng_netflow.ko /modules
install -o root -g wheel -m 444 ng_netflow.4.gz  /usr/share/man/man4
===> flowctl
install -s -o root -g wheel -m 555   flowctl /usr/local/sbin
install -o root -g wheel -m 444 flowctl.8.gz  /usr/share/man/man8

To enable the kernel module, use the following syntax. Note it differs from the man page, which has errors. Interface em0 is the interface which will listen for traffic to be represented as NetFlow data. 172.27.20.3 is the NetFlow collector, bourque.

janney# kldload ng_ether
janney# kldload ng_tee
janney# kldload ng_netflow
janney# ngctl -f - << EOF
? mkpeer em0: tee lower right
? connect em0: em0:lower upper left
? mkpeer em0:lower netflow right2left iface0
? name em0:lower.right2left netflow
? msg netflow: setifindex { iface=0 index=1 }
? mkpeer netflow: ksocket export inet/dgram/udp
? msg netflow:export connect inet/172.27.20.3:4444
? EOF

You can check the status of the ng_netflow kernel module with the following command:

janney# flowctl netflow show
SrcIf   SrcIPaddress    DstIf  DstIPaddress    Pr SrcP DstP  Pkts
em0     192.168.1.2     em0    192.168.1.1      6 03f8 006f     5

These results show flows between 192.168.1.1 and 192.168.1.2. These are the IP addresses in the lab system for which monitoring interface em0 on janney has visibility. Once enabled, and traffic is flowing past the em0 interface on janney, the ng_netflow probe will emit NetFlow records to the collector. We verify this with Tcpdump on the collector, bourque:

bourque# tcpdump -n -s 1515 -i fxp0 -X port 4444
tcpdump: listening on fxp0
08:15:08.271115 172.27.20.5.1064 > 172.27.20.3.4444: udp 72
0x0000   4500 0064 0842 0000 4011 f208 ac1b 1405   E..d.B..@.......
0x0010   ac1b 1403 0428 115c 0050 f86c 0005 0001   .....(.\.P.l....
0x0020   0000 03c5 3ffe a98c 0004 df9c 0000 0000   ....?...........
0x0030   0000 0000 c0a8 0102 c0a8 0101 0000 0000   ................
0x0040   0001 0001 0000 0001 0000 0054 0000 03b2   ...........T....
0x0050   0000 03b2 0000 0000 0000 0100 0000 0000   ................
0x0060   1818 0000                                 ....

As you can see, janney (172.27.20.5) is emitting NetFlow records to port 4444 UDP on 172.27.20.3. Now you need to use something like Flow-captire to collect the records.

flow-capture -w /nsm/netflow/ng_netflow/test/ 0/0/4444

We use Flow-cat and Flow-print to see the records:

bourque# flow-cat * | flow-print | less
srcIP            dstIP            prot  srcPort  dstPort  octets      packets
192.168.1.2      192.168.1.1      6     1023     111      312         5
192.168.1.2      192.168.1.1      6     1022     111      312         5
192.168.1.2      192.168.1.1      6     1021     111      312         5
192.168.1.2      192.168.1.1      17    1023     111      84          1
192.168.1.2      192.168.1.1      6     1020     1023     312         5
192.168.1.2      192.168.1.1      17    1020     111      84          1
192.168.1.2      192.168.1.1      17    1022     111      84          1
192.168.1.2      192.168.1.1      17    1019     1023     156         1
192.168.1.2      192.168.1.1      17    1021     2049     68          1
192.168.1.2      192.168.1.1      17    1018     2049     6204        42
192.168.1.2      192.168.1.1      6     1019     111      312         5
192.168.1.2      192.168.1.1      6     1018     111      312         5
192.168.1.2      192.168.1.1      17    1017     111      84          1
192.168.1.2      192.168.1.1      17    1016     1023     156         1
192.168.1.2      192.168.1.1      17    1018     2049     9053528     56586

I personally prefer to work with Argus data, but many sites have extensive NetFlow-based monitoring systems.

If you prefer to implement a user-land NetFlow probe, try Fprobe, in the ports tree at /usr/ports/net/fprobe.

Fprobe allows a standalone NSM platform to export NetFlow records just as a Cisco router would. It’s an application installed on a server which listens for traffic and generates NetFlow records based on what it sees. Fprobe is a good alternative for analysts who want to create NetFlow data without adding to the processing load of their router, or whose routers don’t support NetFlow due to lack of memory or an old Cisco IOS version.

The following command tells Fprobe to listen on the ngeth0 monitoring interface and export NetFlow data to a collector on port 2055 UDP at 172.27.20.3:

/usr/local/bin/fprobe -i ngeth0 –f ip 172.27.20.3:2055

The default export format is NetFlow v5, although Fprobe also supports versions 1, 5, and 7. The “-f ip” switch tells Fprobe to use the Berkeley Packet Filter “ip” as a filter. Although the –f switch is optional, the Fprobe manpage advocates its use. In the configuration I use, I have Fprobe run on the NSM platform and export NetFlow data to a collector also running on the NSM platform.

We read the Fprobe records using the Flow-tools just as we did for ng_netflow.

rying Tenable's NeWT Security Scanner

After watching this TechTV piece on Tenable Security's new NeWT (Nessus Windows Technology) Security Scanner, I downloaded the trial version. It expires 31 Jan 04 and will scan the same class C address as the system on which it is run. I tried it on a Windows XP laptop with 384 MB RAM and a 1 GHz Pentium III CPU. It installed easily, accepting that I already had version 3.0 of WinPcap loaded.

Within minutes I was scanning one of the other systems on the same class C as my laptop. NeWT has a very "Windows Update" or Microsoft Baseline Security Analyzer feel to it. It's easy to configure and navigate, and the report results were clear.

NeWT is a Windows port of the Nessus engine. Currently the open source version of the Nessus server is UNIX-only, with clients for configuring scans available for Windows or UNIX. NeWT brings the power of Nessus to those preferring to scan from a Windows platform.

Tenable sells two versions of NeWT: one for $500, and one for $3000, with varying IP restrictions. Check out the NeWT home page for more information.

Using Device Polling and More to Improve Packet Capture

I just read a fascinating paper by Luca Deri, author of Ntop, about "Improving Passive Packet Capture: Beyond Device Polling" (.pdf). Luca claims that out of the box, Windows 2000 performs better as a traffic collection platform under high loads (~80 Kpps), capturing 68% of traffic compared to 34% for FreeBSD and 0.2% for Linux kernel 2.4.x. Linux's performance improves to 1% if the mmap libpcap version is used, and up to 4% if a Netfilter-based loadable kernel module is used. These percentages sound off to me. Luca explains the results:

"An explanation for the poor performance figures is something called interrupt livelock. Device drivers instrument network cards to generate an interrupt whenever the card needs attention (e.g. for informing the operating system that there is an incoming packet to handle). In case of high traffic rate, the operating system spends most of its time handling interrupts leaving little time for other tasks. A solution to this problem is something called device polling."

FreeBSD has had device polling available in the kernel since FreeBSD 4.5 REL, but you need to recompile the kernel and use a polling-aware NIC. From /usr/src/sys/i386/conf/LINT on my 4.9 REL box:

# DEVICE_POLLING adds support for mixed interrupt-polling handling
# of network device drivers, which has significant benefits in terms
# of robustness to overloads and responsivity, as well as permitting
# accurate scheduling of the CPU time between kernel network processing
# and other activities. The drawback is a moderate (up to 1/HZ seconds)
# potential increase in response times.
# It is strongly recommended to use HZ=1000 or 2000 with DEVICE_POLLING
# to achieve smoother behaviour.
# Additionally, you can enable/disable polling at runtime with the
# sysctl variable kern.polling.enable (defaults off), and select
# the CPU fraction reserved to userland with the sysctl variable
# kern.polling.user_frac (default 50, range 0..100).
#
# Only the "dc" "fxp" and "sis" devices support this mode of operation at
# the time of this writing.

options         DEVICE_POLLING

However, the man page says other cards are supported, including the important em Gigabit Ethernet driver.

SUPPORTED DEVICES
     Polling requires explicit modifications to the device drivers.  As of
     this writing, the dc(4), em(4), fxp(4), rl(4), and sis(4) devices are
     supported, with other in the works.  The modifications are rather
     straightforward, consisting in the extraction of the inner part of the
     interrupt service routine and writing a callback function, *_poll(),
     which is invoked to probe the device for events and process them.  See
     the conditionally compiled sections of the devices mentioned above for
     more details.

According to Luca, the new Linux 2.6 kernel supports polling as well. He re-ran his tests against Linux kernel 2.6 and FreeBSD 4.8 (polling enabled). Linux with standard libpcap now captured 5.6% of traffic while FreeBSD captured 99.9%. (That's my boy!) When Linux implemented capture using a kernel module, Linux's performance matched FreeBSD at 99.5%.

Not happy with this outcome, Luca modified the Linux Gigabit driver and wrote patches to create a ring-buffer based version of libpcap. He found this works much better and plans to port it to FreeBSD as well.

Update: I asked the community to provide opinions on this paper. You can read the thread at unix.derkeiler.com. The netbsd-tech-kern list hotly debated this paper in this thread.

Update: On 20 Feb 04 Luca released a significantly modified version of the paper at the same URL. The big issue for FreeBSD seems to be poor performance with higher packet sizes.

Happy 1st Birthday TaoSecurity Blog

Today this Blog is one year old. My first post was 8 Jan 03. I started this Blog as a "hard drive for my brain," since I dislike keeping bookmarks and I prefer to place Internet links and news within context.

I decided today to try to get VMWare 3.x working fully within FreeBSD, so I installed the VMWare3 port (version vmware3 3.2.1.2242-2) on my FreeBSD 4.9 STABLE system. First I made this change as recommended by the port install directions:

janney# sysctl kern.ipc.shm_allow_removed=1
kern.ipc.shm_allow_removed: 0 -> 1

I then added this line to /etc/sysctl.conf to enable this at boot time:

kern.ipc.shm_allow_removed=1

I then mounted linproc:

janney# mount_linprocfs linproc /compat/linux/proc
janney# mount
/dev/amrd0s1a on / (ufs, NFS exported, local)
/dev/amrd0s1h on /home (ufs, local, soft-updates)
/dev/amrd0s1g on /tmp (ufs, local, soft-updates)
/dev/amrd0s1e on /usr (ufs, local, soft-updates)
/dev/amrd0s1f on /var (ufs, local, soft-updates)
procfs on /proc (procfs, local)
linprocfs on /usr/compat/linux/proc (linprocfs, local)

I added this line to /etc/fstab to enable this at boot time:

linprocfs   /usr/compat/linux/proc  linprocfs   rw 0 0

I executed '/usr/local/etc/rc.d/vmware.sh start' and saw it created a new pseudo-interface:

vmnet1: flags=8943 mtu 1500
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 fe80::2bd:65ff:fee2:6601%vmnet1 prefixlen 64 scopeid 0x9
        ether 00:bd:65:e2:66:01

I also saw the following existed:

janney# ls /compat/linux/dev
hda     null    tty0    tty10   tty12   tty3    tty5    tty7    tty9    vmnet1
hdb     rtc     tty1    tty11   tty2    tty4    tty6    tty8    vmmon

I made sure my /usr/local/lib/vmware/licenses/user/license.ws.3.0 file had the appropriate license, and then fired up VMWare. I installed Red Hat Linux 6.2 as a test OS. For networking I created a "custom" entry with /dev/vmnet1. Once the OS installation was complete everything worked. I could ping my gateway and reach the VM from outside hosts.

Finisar Tap Advice Strains the Brain

At left is an image of the Finisar Ethernet tap I use in my basement to monitor traffic. I wrote about it last July when I explained the bad design of Intrusion Inc's tap. Today I was trying to find the UTP IL/1 at Finisar's site. I didn't find it, but I did find a document which shocked me. It's titled "Using Single Port Taps with IDS Systems" (.pdf). (Note to self: Intrusion Detection System Systems?)

This document mentions the IL/1 and advocates plugging the tap outputs into a hub. The problem with this is simple: a tap preserves the full-duplex nature of a link between switches. Full-duplex means both ends can transmit simultaneously. What happens to packets transmitted simultaneously when they enter a hub? BANG -- collision. That's no problem on a half-duplex medium like unswitched Ethernet, since the transmitters will sense the collision (hence Carrier Sense Multiple Access Collision Detection). The parties will back off and retransmit, hoping for better luck next time.

With a full-duplex tap, there is no retransmission. The two simultanous packets collide and the original transmitters never hear the packets' silent death scream. I see many posts to IDS newsgroups advocating this horrible design strategy, with posters cheerfully claiming their IDS handles Fast Ethernet speeds with no packet loss. The problem is their IDS never sees the majority of the traffic, as it dies in a collision-ridden blaze of misfortune.

Below is a capture of the document in question:

Note there is no problem with the Finisar tap itself, only with this poor design advice. This is in contrast with the Intrusion SecureNet IDS Tap 10/100. It sports a single transmit output, meaning it combines two transmission streams, potentially operating at over 50 Mbps, into a single output. When the total of the two TX inputs exceeds 100 Mbps, we have another traffic issue -- dropped packets.

Someone please email me at blogspot at taosecurity dot com to tell me I'm misinterpreting this Finisar document. I don't see how this is a good idea. The document even shows two cables going straight into a hub. Unbelievable.

Options for Security Shell History in FreeBSD

I was looking for a tool to secure shell histories in FreeBSD. Ideally I was looking for the FreeBSD equivalent of Snare, which can record user activities on Linux, Windows, and Solaris. I learned today Snare is the foundation for the Forensix Project. The Honeynet Project links to several tools, including the Sebek LKM. Ryan Barnett of honeypots.sf.net wrote an extensive guide (.pdf) to Snare usage.

Unfortunately I couldn't find exactly that, but I did locate this excellent article at DefCon1.org. The author explains how to use FreeBSD's chflags utility to prevent users from deleting the Bash .history file. The author also explains how to set up process accounting via acct and mentions briefly how to use the sa and lastcomm utilities. His recommendations worked on one of my FreeBSD 4.9 REL boxes as described.

Review of Understanding Open Source Software Development Posted

Amazon.com just posted my four star review of Understanding Open Source Software Development, a new addition to my Listmania List on Management and Policy. From the review:

"UOSSD is the perfect introduction to OSS for those outside the community. The book takes a fairly balanced look at the people and processes which define the open source movement. Although some aspects of the book have grown stale over the last three years, I still recommend UOSSD to those desiring a deeper look at the open source phenomenon."

This is my first new review of 2004. Last year I read and reviewed 33 technical books.

Binary Patching with OpenBSD

I tried the Binpatch binary patching system for OpenBSD today on an OpenBSD 3.3 system. I downloaded each of the archives listed for my version and then architecture, and sequentially applied them starting with 001 and ending with 008. The binpatch author Gerardo Santana Gómez Garrido told me I could avoid applying all of the kernel patches if I installed the newest one, but all of the userland patches needed to be applied. Since it was simple enough to install all of the eight archives, I tried that.

Essentially I downloaded all eight archives and applied each as follows. So, to apply the first set of patches:

wget http://www.openbsd.org.mx/pub/binpatch/3.3/i386/binpatch-3.3-i386-001.tgz

tar -xzvpf binpatch-3.3-i386-001.tgz -C /

Then I downloaded the second set and untarred them, and so on. When I was done I rebooted and found my system had a new kernel:

OpenBSD 3.3 (GENERIC) #3: Sat Oct 4 12:38:19 CDT 2003

santana@santana.openbsd.org.mx:/root/binpatch/work-binpatch-3.3/

 src/sys/arch/i386/compile/GENERIC

Note my kernel was GENERIC to begin with.

Chaosreader Rocks

For a while I've been looking for a program to extract application layer data from pcap files. We all know how to rebuild sessions using Ethereal and some of us know about tcpflow. Today I found Chaosreader. It's a Perl script which parses pcap or snoop files and extracts email, images, HTML, telnet sessions, and other application data. I think this part of the Perl script defines its capabilities:

#  These ports have been selected to be saved as coloured 2-way HTML files

#

@Save_As_HTML_TCP_Ports = (21,23,25,79,80,109,110,119,143,513,514,1080,

 3128,4110,5000,5555,6660,6665,6666,6667,6668,7000,8000,8080,9000);

@Save_As_HTML_UDP_Ports = (53);



#

#  These ports have been selected to be saved as realtime playback scripts

#  (telnet, login, and numerous IRC ports)

#

@Save_As_TCP_Playback_Ports = (23,513,4110,5000,5555,6660,6666,6667,

 6668,7000,8000,9000);

@Save_As_UDP_Playback_Ports = (7);

Chaosreader presents the information in .html files for easy browsing. When it rebuilds a session, say for telnet, it creates a Perl script that you can run to watch the keystrokes replay in real time. I'm looking forward to seeing the author implement X11 replay. The Review package is supposed to have this capability but I've never tried it.

Ipsumdump Summarizes Network Traffic

I came across Ipsumdump today. It's a program to read traffic and summarize what it sees in a user-defined format on one line. In the example below I watch the sf1 interface in real time and tell Ipsumdump to show a timestamp, source IP and port, and destination IP and port. Ipsumdump works against multiple interfaces simultaneously as well as pcap files and NetFlow traces. In the example below the first two packets are an ICMP echo and echo reply, followed by the beginning of an SSH session.

bourque# ipsumdump -tsSdD -i sf1

warning: sf1: no IPv4 address assigned

!IPSummaryDump 1.1

!creator "ipsumdump -tsSdD -i sf1"

!host bourque.taosecurity.com

!runtime 1073092478.545313 (Fri Jan  2 20:14:38 2004)

!data timestamp ip_src sport ip_dst dport

1073092486.925087 172.27.20.11 - 192.168.60.3 -

1073092486.925253 192.168.60.3 - 172.27.20.11 -

1073092529.535523 192.168.50.2 23924 192.168.60.3 22

1073092529.535689 192.168.60.3 22 192.168.50.2 23924

1073092529.543094 192.168.50.2 23924 192.168.60.3 22

1073092529.545758 192.168.60.3 22 192.168.50.2 23924