Preview: Hunting Security Bugs

Yesterday I received a copy of Hunting Security Bugs. One of this book's authors is Tom Gallagher, who posted thoughts on Microsoft's security initiatives.

This looks like a great book, especially as a companion to The Security Development Lifecycle, also by Microsoft authors.

A third book, The Practical Guide to Defect Prevention, arrives in the spring. This may be too developer-oriented for my needs, but I might take a look at it.

I am glad to see Microsoft sharing the knowledge it has gained through its ongoing security program.

You can look at my Amazon.com Wish List to track books I plan to read, but don't have copies. My reading page shows books I own that I plan to read. The reading page also links to my recommended books lists.

Read More

Security Scruples Poll

Dark Reading is conducting a Security Scruples Poll. Some of the preliminary results are disturbing. I'll withhold commentary until I see the poll is closed and results are disclosed. Please consider taking the poll. It has some interesting questions, and it takes about 5 minutes.

Read More

Review of Apache Security Books Posted

Amazon.com just posted my two reviews on books about Apache. The first is Apache Security by Ivan Ristic. Here is a link to the five star review.
The second is Preventing Web Attacks with Apache by Ryan Barnett. Here is a link to the four star review.

Both reviews share the same introduction.

I recently received copies of Apache Security (AS) by Ivan Ristic and Preventing Web Attacks with Apache (PWAWA) by Ryan Barnett. I read AS first, then PWAWA. Both are excellent books, but I expect potential readers want to know which is best for them. The following is a radical simplification, and I could honestly recommend readers buy either (or both) books. If you are more concerned with a methodical, comprehensive approach to securing Apache, choose AS. If you want more information on offensive aspects of Web security, choose PWAWA.

These are my 39th and 40th reviews of 2006. I should break my previous high reading mark of 42 books, accomplished in 2001.

Congratulations to Ivan for the acquisition of Thinking Stone by Breach Security.

Read More

Symantec Internet Security Threat Report Volume X

Symantec has posted (for free, no registration!) the latest Internet Security Threat Report. I'm very pleased to see that such a high-profile report uses threat and vulnerability terms properly, and features details on the methodology used to produce the report. Here's some of the Executive Summary.

In contrast to previously observed widespread, network-based attacks, attackers today tend to be more focused, often targeting client-side applications... The current threat landscape is populated by lower profile, more targeted attacks, attacks that propagate at a slower rate in order to avoid detection and thereby increase the likelihood of successful compromise.

Instead of exploiting vulnerabilities in servers, as traditional attacks often did, these threats tend to exploit vulnerabilities in client-side applications that require a degree of user interaction, such as word processing and spreadsheet programs.

A number of these have been zero-day vulnerabilities. These types of threats also attempt to escape detection in order to remain on host systems for longer periods so that they can steal information or provide remote access.

Do you see how important it is to differentiate between threats and vulnerabilities when the terms are used in the same sentence? Bravo Symantec.

This volume of the Internet Security Threat Report will offer an analysis and discussion of threat activity that took place between January 1 and June 30, 2006. This brief summary will offer a synopsis of the data and trends discussed in the main report. Symantec will continue to monitor and assess threat activity in order to best prepare consumers and enterprises for the complex Internet security issues to come.

How does Symantec "monitor and assess threat activity"? By watching, of course.

The Symantec™ Global Intelligence Network comprehensively tracks attack activity across the entire Internet. The Global Intelligence Network, which includes the Symantec DeepSight™ Threat Management System and Symantec™ Managed Security Services, consists of over 40,000 sensors monitoring network activity in over 180 countries. As well, Symantec gathers malicious code data along with spyware and adware reports from over 120 million client, server, and gateway systems that have deployed Symantec’s antivirus products.

They're not using counts of vulnerabilities announced on mailing lists. They're watching exploitation of their customer base.

Their Vulnerability Trend Highlights are fascinating:

• Symantec documented 2,249 new vulnerabilities, up 18% over the second half of
  2005. This is the highest number ever recorded for a six-month period.


• Web application vulnerabilities made up 69% of all vulnerabilities this period.


• Mozilla browsers had the most vulnerabilities, 47, compared to 38 in Microsoft Internet Explorer.


• In the first six months of 2006, 80% of vulnerabilities were considered easily exploitable, up from 79%.


• Seventy-eight percent of easily exploitable vulnerabilities affected Web applications.


• The window of exposure for enterprise vulnerabilities was 28 days.


• Internet Explorer had an average window of exposure of nine days, the largest of any Web browser. Apple Safari averaged five days, followed by Opera with two days and Mozilla with one day.


• In the first half of 2006, Sun operating systems had the highest average patch development time, with 89 days, followed by Hewlett Packard with 53 days, Apple with 37 days and Microsoft and Red Hat with 13 days.

I think it's interesting that Mozilla had more vulnerabilities, but a far smaller vulnerability window, than Internet Explorer.

I recommend reading the whole report, or at least the executive summary.

Read More

Review of The TCP/IP Guide Posted

Amazon.com just posted my 4 star review of The TCP/IP Guide. From the review:

Right away I must state that I did not read "The TCP/IP Guide" (TTG) cover-to-cover. I doubt anyone will, which raises interesting issues. This review is based on the sections I did read and my comparisons with other protocol books.

Protocol books should be divided into two eras. The first is the "Stevens era" meaning those written around the time Richard Stevens' "TCP/IP Illustrated, Vol 1: The Protocols" was published. For six years (1994-2000) Stevens' book was clearly the best protocol book, and it taught legions of networking pros TCP/IP. The second is the "modern era," beginning in 2000 and continuing to today. TTG fits in this group.

I question the approach taken by TTG. The book contains extremely basic information (what is networking, why use layers, what is a protocol, etc.) and extremely obscure information (PPP Link Control Protocol Frame Types and Fields, SNMPv2 PDU Error Status Field Values, Interpretation of Standard Telnet NVT ASCII Control Codes, etc.). If TTG were an introductory book, it wouldn't need the obscure material. If TTG were a reference, it wouldn't need the introductory material.

At 1616 pages and nearly 5 pounds, we should be dropping these books out of B-2s!

Read More

Net Optics Think Tank Tuesday in Fairfax, VA

Don't forget to attend the free Net Optics Think Tank on Tuesday, 26 September 2006 in Fairfax, VA. It looks like I will be speaking during lunch from 1215 to 1315. Please register. I expect to see a lot of cool Net Optics gear on display, along with insights from those who make products for enterprise network instrumentation.

Read More

Throughput Testing Through a Bridge

In my earlier posts I've discussed throughput testing. Now I'm going to introduce an inline system as a bridge. You could imagine that this system might be a firewall, or run Snort in inline mode. For the purposes of this post, however, we're just going to see what effect the bridge has on throughput between a client and server.

This is the new system. It's called cel600, and it's running the same GENERIC.POLLING kernel mentioned earlier.

FreeBSD 6.1-RELEASE-p6 #0: Sun Sep 17 17:09:24 EDT 2006
    root@kbld.taosecurity.com:/usr/obj/usr/src/sys/GENERIC.POLLING
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel Celeron (598.19-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR,SSE>
real memory  = 401260544 (382 MB)
avail memory = 383201280 (365 MB)

This system has two dual NICs in it. em0 and em1 are Gigabit fiber, and em2 and em3 are Gigabit copper.

cel600:/root# ifconfig em0
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=48<VLAN_MTU,POLLING>
        inet6 fe80::204:23ff:feb1:7f22%em0 prefixlen 64 scopeid 0x1 
        ether 00:04:23:b1:7f:22
        media: Ethernet autoselect (1000baseSX <full-duplex>)
        status: active
cel600:/root# ifconfig em1
em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=48<VLAN_MTU,POLLING>
        inet6 fe80::204:23ff:feb1:7f23%em1 prefixlen 64 scopeid 0x2 
        ether 00:04:23:b1:7f:23
        media: Ethernet autoselect (1000baseSX <full-duplex>)
        status: active
cel600:/root# ifconfig em2
em2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=48<VLAN_MTU,POLLING>
        inet6 fe80::204:23ff:fec5:4e80%em2 prefixlen 64 scopeid 0x3 
        ether 00:04:23:c5:4e:80
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
cel600:/root# ifconfig em3
em3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=48<VLAN_MTU,POLLING>
        inet6 fe80::204:23ff:fec5:4e81%em3 prefixlen 64 scopeid 0x4 
        ether 00:04:23:c5:4e:81
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

I configure them in /etc/rc.conf this way:

ifconfig_em0="polling up"
ifconfig_em1="polling up"
ifconfig_em2="polling up"
ifconfig_em3="polling up"
cloned_interfaces="bridge0 bridge1"
ifconfig_bridge0="addm em0 addm em1 monitor up"
ifconfig_bridge1="addm em2 addm em3 monitor up"

The end result is two bridge interfaces.

bridge0: flags=48043<UP,BROADCAST,RUNNING,MULTICAST,MONITOR> mtu 1500
        ether ac:de:48:e5:e7:69
        priority 32768 hellotime 2 fwddelay 15 maxage 20
        member: em1 flags=3<LEARNING,DISCOVER>
        member: em0 flags=3<LEARNING,DISCOVER>
cel600:/root# ifconfig bridge1
bridge1: flags=48043>UP,BROADCAST,RUNNING,MULTICAST,MONITOR> mtu 1500
        ether ac:de:48:0c:26:66
        priority 32768 hellotime 2 fwddelay 15 maxage 20
        member: em3 flags=3<LEARNING,DISCOVER>
        member: em2 flags=3<LEARNING,DISCOVER>

Notice these two pseudo-interfaces are both in MONITOR mode. That was set automatically.

With the bridge in place, I can conduct throughput tests.

Here is the client's view.

asa633:/root# iperf -c 172.16.6.2 -t 60 -i 5
------------------------------------------------------------
Client connecting to 172.16.6.2, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 172.16.6.1 port 57355 connected with 172.16.6.2 port 5001
[  3]  0.0- 5.0 sec  55.9 MBytes  93.9 Mbits/sec
[  3]  5.0-10.0 sec  51.6 MBytes  86.6 Mbits/sec
[  3] 10.0-15.0 sec  72.3 MBytes    121 Mbits/sec
[  3] 15.0-20.0 sec  54.6 MBytes  91.6 Mbits/sec
[  3] 20.0-25.0 sec  61.4 MBytes    103 Mbits/sec
[  3] 25.0-30.0 sec  75.4 MBytes    127 Mbits/sec
[  3] 30.0-35.0 sec  60.2 MBytes    101 Mbits/sec
[  3] 35.0-40.0 sec  47.8 MBytes  80.2 Mbits/sec
[  3] 40.0-45.0 sec  74.7 MBytes    125 Mbits/sec
[  3] 45.0-50.0 sec  59.0 MBytes  99.0 Mbits/sec
[  3] 50.0-55.0 sec  54.0 MBytes  90.6 Mbits/sec
[  3] 55.0-60.0 sec  76.8 MBytes    129 Mbits/sec
[  3]  0.0-60.0 sec    744 MBytes    104 Mbits/sec

Here is the server's view.

poweredge:/root# iperf -s -B 172.16.6.2
------------------------------------------------------------
Server listening on TCP port 5001
Binding to local address 172.16.6.2
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  4] local 172.16.6.2 port 5001 connected with 172.16.6.1 port 57355
[  4]  0.0-60.0 sec    744 MBytes    104 Mbits/sec

Compared to the straight-through tests, you can see the effect on throughput caused by the bridge.

[  4]  0.0-60.0 sec  1.19 GBytes    170 Mbits/sec

Of interest during the test is the interrupt count on the bridge.

last pid:   728;  load averages:  0.00,  0.09,  0.06    up 0+00:06:36  17:58:40
22 processes:  1 running, 21 sleeping
CPU states:  0.4% user,  0.0% nice,  0.4% system, 17.1% interrupt, 82.1% idle
Mem: 7572K Active, 4776K Inact, 16M Wired, 8912K Buf, 339M Free
Swap: 768M Total, 768M Free

Let's try the UDP test. First, the client view.

asa633:/root# iperf -c 172.16.6.2 -u -t 60 -i 5 -b 500M
------------------------------------------------------------
Client connecting to 172.16.6.2, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[  3] local 172.16.6.1 port 51356 connected with 172.16.6.2 port 5001
[  3]  0.0- 5.0 sec    169 MBytes    284 Mbits/sec
[  3]  5.0-10.0 sec    169 MBytes    284 Mbits/sec
[  3] 10.0-15.0 sec    171 MBytes    287 Mbits/sec
[  3] 15.0-20.0 sec    171 MBytes    287 Mbits/sec
[  3] 20.0-25.0 sec    171 MBytes    287 Mbits/sec
[  3] 25.0-30.0 sec    171 MBytes    287 Mbits/sec
[  3] 30.0-35.0 sec    171 MBytes    287 Mbits/sec
[  3] 35.0-40.0 sec    172 MBytes    288 Mbits/sec
[  3] 40.0-45.0 sec    172 MBytes    288 Mbits/sec
[  3] 45.0-50.0 sec    172 MBytes    288 Mbits/sec
[  3] 50.0-55.0 sec    172 MBytes    288 Mbits/sec
[  3]  0.0-60.0 sec  2.00 GBytes    287 Mbits/sec
[  3] Sent 1463703 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  1.93 GBytes    276 Mbits/sec  0.014 ms 53386/1463702 (3.6%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order

Now the server view.

poweredge:/root# iperf -s -u -B 172.16.6.2
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 172.16.6.2
Receiving 1470 byte datagrams
UDP buffer size: 41.1 KByte (default)
------------------------------------------------------------
[  3] local 172.16.6.2 port 5001 connected with 172.16.6.1 port 51356
[  3]  0.0-60.0 sec  1.93 GBytes    276 Mbits/sec  0.014 ms 53386/1463702 (3.6%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order

Here's the result from the straight-through test.

[  3]  0.0-60.0 sec  1.94 GBytes    277 Mbits/sec  0.056 ms 62312/1478219 (4.2%)

The results are almost identical.

Here is the bridge's interrupt count as shown in a top excerpt.

last pid:   751;  load averages:  0.00,  0.03,  0.04    up 0+00:10:20  18:02:24
22 processes:  1 running, 21 sleeping
CPU states:  0.0% user,  0.0% nice,  0.4% system, 19.8% interrupt, 79.8% idle
Mem: 7564K Active, 4788K Inact, 16M Wired, 8928K Buf, 339M Free
Swap: 768M Total, 768M Free

With the Gigabit fiber tests done, let's look at Gigabit copper.

First, a TCP test as seen by the client.

asa633:/root# iperf -c 172.16.7.2 -t 60 -i 5
------------------------------------------------------------
Client connecting to 172.16.7.2, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 172.16.7.1 port 58824 connected with 172.16.7.2 port 5001
[  3]  0.0- 5.0 sec  76.3 MBytes    128 Mbits/sec
[  3]  5.0-10.0 sec  76.3 MBytes    128 Mbits/sec
[  3] 10.0-15.0 sec  76.8 MBytes    129 Mbits/sec
[  3] 15.0-20.0 sec  76.6 MBytes    129 Mbits/sec
[  3] 20.0-25.0 sec  76.8 MBytes    129 Mbits/sec
[  3] 25.0-30.0 sec  75.4 MBytes    127 Mbits/sec
[  3] 30.0-35.0 sec  76.3 MBytes    128 Mbits/sec
[  3] 35.0-40.0 sec  76.1 MBytes    128 Mbits/sec
[  3] 40.0-45.0 sec  76.5 MBytes    128 Mbits/sec
[  3] 45.0-50.0 sec  75.4 MBytes    126 Mbits/sec
[  3] 50.0-55.0 sec  76.7 MBytes    129 Mbits/sec
[  3] 55.0-60.0 sec  76.4 MBytes    128 Mbits/sec
[  3]  0.0-60.0 sec    916 MBytes    128 Mbits/sec

Here is the server's view.

poweredge:/root# iperf -s -B 172.16.7.2
------------------------------------------------------------
Server listening on TCP port 5001
Binding to local address 172.16.7.2
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  4] local 172.16.7.2 port 5001 connected with 172.16.7.1 port 58824
[  4]  0.0-60.0 sec    916 MBytes    128 Mbits/sec

That is better than the result for fiber from above.

[  4]  0.0-60.0 sec    744 MBytes    104 Mbits/sec

It's not as good as the result for straight-through copper.

[  4]  0.0-60.0 sec  1.16 GBytes    166 Mbits/sec

It seemed as though the bridge interrupt count was lower than the fiber TCP tests.

last pid:   754;  load averages:  0.00,  0.01,  0.02    up 0+00:13:48  18:05:52
22 processes:  1 running, 21 sleeping
CPU states:  0.0% user,  0.0% nice,  0.4% system, 16.7% interrupt, 82.9% idle
Mem: 7560K Active, 4792K Inact, 16M Wired, 8928K Buf, 339M Free
Swap: 768M Total, 768M Free

Finally, UDP copper tests. Here is the client view.

asa633:/root# iperf -c 172.16.7.2 -u -t 60 -i 5 -b 500M
------------------------------------------------------------
Client connecting to 172.16.7.2, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 9.00 KByte (default)
------------------------------------------------------------
[  3] local 172.16.7.1 port 62131 connected with 172.16.7.2 port 5001
[  3]  0.0- 5.0 sec    129 MBytes    217 Mbits/sec
[  3]  5.0-10.0 sec    129 MBytes    217 Mbits/sec
[  3] 10.0-15.0 sec    129 MBytes    217 Mbits/sec
[  3] 15.0-20.0 sec    129 MBytes    217 Mbits/sec
[  3] 20.0-25.0 sec    129 MBytes    217 Mbits/sec
[  3] 25.0-30.0 sec    129 MBytes    216 Mbits/sec
[  3] 30.0-35.0 sec    129 MBytes    216 Mbits/sec
[  3] 35.0-40.0 sec    129 MBytes    216 Mbits/sec
[  3] 40.0-45.0 sec    129 MBytes    216 Mbits/sec
[  3] 45.0-50.0 sec    129 MBytes    216 Mbits/sec
[  3] 50.0-55.0 sec    129 MBytes    216 Mbits/sec
[  3]  0.0-60.0 sec  1.51 GBytes    216 Mbits/sec
[  3] Sent 1103828 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  1.46 GBytes    209 Mbits/sec  0.047 ms 35057/1103827 (3.2%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order

Here is the server view.

poweredge:/root# iperf -s -u -B 172.16.7.2
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 172.16.7.2
Receiving 1470 byte datagrams
UDP buffer size: 41.1 KByte (default)
------------------------------------------------------------
[  3] local 172.16.7.2 port 5001 connected with 172.16.7.1 port 62131
[  3]  0.0-60.0 sec  1.46 GBytes    209 Mbits/sec  0.047 ms 35057/1103827 (3.2%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order

Let's compare that to the fiber UDP test from above.

[  3]  0.0-60.0 sec  1.93 GBytes    276 Mbits/sec  0.014 ms 53386/1463702 (3.6%)

This time, the results are much worse than the UDP over fiber results.

When I tested UDP over crossover copper, this was the result.

[  3]  0.0-60.0 sec  1.86 GBytes    267 Mbits/sec  0.024 ms 40962/1401730 (2.9%)

The top excerpt is about the same as the fiber UDP test.

last pid:   754;  load averages:  0.01,  0.01,  0.01    up 0+00:16:21  18:08:25
22 processes:  1 running, 21 sleeping
CPU states:  0.0% user,  0.0% nice,  0.0% system, 17.1% interrupt, 82.9% idle
Mem: 7564K Active, 4788K Inact, 16M Wired, 8928K Buf, 339M Free
Swap: 768M Total, 768M Free

It's not really feasible to make any solid assumptions based on these tests. They're basically get to get a ballpark feel for the capabilities of a given architecture, but you need to repeat them multiple times to get some confidence in the results.

If you want built-in repeatability and confidence testing, try Netperf.

With these results, however, I have some idea of what I can expect from this particular hardware setup, namely a bridge between a client sending data to a server.

• TCP over fiber: about 104 Mbps


• UDP over fiber: about 276 Mbps


• TCP over copper: about 128 Mbps


• UDP over copper: about 209 Mbps

Rounding down, and acting conservatively, I would feel this setup could handle somewhere around 100 Mbps (aggregated) over fiber and around 125 Mbps over copper. Note this says nothing about any software running on the bridge and its ability to do whatever function it is designed to perform. This is just a throughput estimate.

In my next related posts I'll introduce bypass switches and see how they influence this process.

I'll also rework the configuration into straight-through, bridged, and switched modes to test latency using ping.

Read More