Review of The Design and Implementation of the FreeBSD Operating System Posted

Amazon.com just posted my five star review of The Design and Implementation of the FreeBSD Operating System. I was excited to see this update of the 1996 classic The Design and Implementation of the 4.4BSD Operating System finally published. From the review:

"I have been administering FreeBSD systems for four years, and I read 'The Design' to get a better understanding of the system 'under the hood.' This book is definitely not for beginners, and intermediate users like myself can become quickly overwhelmed. Nevertheless, I am very glad FreeBSD developers like McKusick and Neville-Neil took the time to document the kernel in this book."

You can access the authors' works at Addison-Wesley or at McKusick.com and Neville-Neil.com.

Read More

What is the Ultimate Security Solution?

I received an email asking certain questions about digital security. Since the author said I could post my reply in my Blog, here is an excerpt from his email:

"I have read of many ways that hackers obtain access. But, I am uncertain what is comprehensive protection. Clearly, there are firewalls, anti-virus, anti-spyware, IDS, IPS, and many other three letter acronym tools available. I have read of your use/support for Sguil. Do you feel that is the ultimate solution?

There are other tools out there like eEye Blink, Pivx Qwikfix, and Securecore type products. I like them, but am uncertain if they do an adequate job at providing security. And I really don't know which would be considered the best of these.

So, I appeal to you for your insight. Would really appreciate any feedback - here or on your blog."

This is an interesting question, because at least one reader of my recent Focus-IDS post thought I was a "detection-only" advocate. Since I believe protection eventually fails (I do believe that, and it's true), did I not also believe protection was worthless?

Chapter 1 of my book lays out my philosophy on security, and Chapter 2 explains how I believe Network Security Monitoring meets the needs of my security philosophy. Anton Chuvakin's recent Slashdot review summarizes some of my thoughts. I recommend anyone interested in knowing how I define terms like security, risk, vulnerability, threat, and so forth thumb through the first two chapters of my book in your local Borders or Barnes and Noble store.

Regarding "ultimate solutions," I don't believe there is such a concept. I agree with Dr. Mitch Kabay that "security is a process, not an end state," and with Bruce Schneier who says security is a process, not a product." On p. 4 of my book I define security as "the process of maintaining an acceptable level of perceived risk." No organization can be considered "secure" for any time beyond the last verification of adherence to its security policy.

How does one best adhere to one's security policy? I believe the answer lies in following the security process, which consists of assessment, protection (prevention), detection, and response. Chapter 11 of my book presents best practices for each as they relate to implementing NSM.

This means none of the products you mentioned (yes, even Sguil) can provide ultimate security. Even all of the best of breed products in the world deployed simultaneously cannot perfectly secure an organization. Focus on products ignores people and processes. All three elements must be brought to bear on the security problem.

I clearly believe that network awareness is one of the keys to security. "Situational awareness" was drilled into my brain as a cadet at the US Air Force Academy, and for good reason. When one is ignorant of one's surroundings, it is impossible to discern the defensive landscape as well as any threats. I advocate NSM as a means to get real threat intelligence. I avoid taking a vulnerability-focused approach to security where possible. Remember that one of the best ways to prevent intrusions is to help put criminals behind bars by collecting evidence and supporting the prosecution of offenders. The only way to ensure a specific Internet-based threat never bothers your organization is to separate him from his keyboard!

I recommend you and other others define your requirements before speaking to any vendor or researching any products. Decide what you believe is lacking in your security posture, and determine what combination of products, people, and processes could best meet your needs. Hire a professional security consultant to perform an assessment if you feel you lack the necessary expertise. Avoid consultants who run Nessus and drop a vulnerability report on your desk. Consult those who can offer solutions to problems or who can supervise the implementation of solutions by third parties. For your personal education you might find reading one or more of my recommended books helpful.

Read More

Showing the FreeBSD Release Engineering Team is on schedule, FreeBSD 5.3-BETA2 is now available. Relating to my earlier post on GIANT, the announcement states "debug.mpsafenet (multi-processor safe network stack) is still turned off by default for BETA2 but will be turned on for BETA3."

Read More

GIANT-free Networking in FreeBSD 6.0 CURRENT and Upcoming 5.3 STABLE

I've been watching Robert Watson's work on removing the GIANT lock from the FreeBSD kernel. This is an aspect of the FreeBSD SMP project (aka SMPng). Robert's posts on 24 Aug 04 and 28 Aug 04 explain what is affected by these developments. The aspects I care about include the following:

- Those using KAME IPSec will not be able to disable the GIANT lock, and least not yet.
- FAST IPSEC does work with GIANT removed.
- The ath (802.11g), bge, dc, em (Intel gigabit), ep, fxp (Intel 10/100), rl, sis (Soekris Net4801), xl, and wi (802.11b Prism2) network interface drivers work with GIANT disabled.

You can see how the GIANT lock appears when enabled in the dmesg output from a Dell PowerEdge 750 running FreeBSD 5.3-BETA1.

John Baldwin's Locking in the Multithreaded FreeBSD Kernel explains what the GIANT lock does.

Read More

My Book on Slashdot

My book made Slashdot. Let's see how well this site and TaoSecurity.com hold up! Thank you to Anton Chuvakin for a positive review.

Update: Here's how the Slashdot effect looked to TaoSecurity.com:

Here's how the Slashdot effect looked to this Blog:

My Barnes and Nobles sales rank has dropped from the 40,000 range to 20 -- I've passed Bill Clinton and Harry Potter. :)

My Amazon.com sales rank has dropped from the 20,000 range to 119. Slashdot is absolutely amazing. If you find the Amazon price too high, remember Bookpool has the best deal going -- $27.25 plus shipping.

I'd been tracking the Amazon rank to see if I could make any sense of it. You can watch the Slashdot effect kick in between 5 and 6 pm EDT:

Fri Aug 27 17:00:02 EDT 2004
Amazon.com Sales Rank: 20,998 
 
Fri Aug 27 18:00:01 EDT 2004
Amazon.com Sales Rank: 9,363 
 
Fri Aug 27 19:00:02 EDT 2004
Amazon.com Sales Rank: 1,256 
 
Fri Aug 27 20:00:02 EDT 2004
Amazon.com Sales Rank: 614 
 
Fri Aug 27 21:00:01 EDT 2004
Amazon.com Sales Rank: 348 
...
Fri Aug 27 23:00:01 EDT 2004
Amazon.com Sales Rank: 313 
 
Sat Aug 28 00:00:01 EDT 2004
Amazon.com Sales Rank: 275 
 
Sat Aug 28 01:00:01 EDT 2004
Amazon.com Sales Rank: 212 

Sat Aug 28 03:00:02 EDT 2004
Amazon.com Sales Rank: 188 
...
Sat Aug 28 06:00:01 EDT 2004
Amazon.com Sales Rank: 163 

Note: These rankings represent the best-case scenario. Now that the Slashdot effect has ended, I've dropped at both Amazon.com and Barnes and Noble. It was fun while it lasted!

Read More

Senator Kennedy No-Fly Watch List and IDS "False Positives"

It struck me today that Senator Kennedy's no-fly watch list troubles are very similar to our digital security woes. Recently Kennedy said "he was stopped and questioned at airports on the East Coast five times in March because his name appeared on the government's secret 'no-fly' list." The Washington Post reported "a senior administration official, who spoke on condition he not be identified, said Kennedy was stopped because the name 'T. Kennedy' has been used as an alias by someone on the list of terrorist suspects."

"T. Kennedy" reminds me of a content matching IDS rule. Is this a "false positive"? If you consider that airline personnel were making decisions based on the rules they were given -- stop anyone using the name "T. [Ted, in the senator's case] Kennedy," this is not a false positive. Perhaps with more context, like personal recognition that the individual at hand is one of the most famous members of the US Senate, the airline "IDS" would meet more of the "spirit" of its mission and less its "letter."

How did Senator Kennedy handle being flagged when he checked into the airport? According to the Post, "When the senator checked in at the counter, airline employees told him they could not issue him a boarding pass because he appeared on the list. Kennedy was delayed until a supervisor could be summoned to identify him and give approval for him to board the plane." That process reminds me of an investigation by a human analyst. Luckily the analyst had the information he or she needed to make a decision. The "full content data" in the person of Senator Kennedy allowed the decision maker to realize the senator was not a terrorist. Without that data, say only knowing someone named "T. Kennedy" was on board a flight, the decision maker might not be able to take proper defensive actions.

What is better: (1) removing a "bad signature" ("T. Kennedy"), or (2) relying on a scrap of imprecise information that could potentially identify a serious threat? With all of this case's publicity, it's doubtful any terrorist will use that alias again. Whatever your decision, this case reminds security professionals to collect the information analysts need to transform indicators into warnings. Also, don't blame the identification system for making poor decisions if you feed it imprecise signatures.

Read More

Fascinating .gov and .mil Docs

Perhaps "fascinating" is too strong a word, but I've come across several intriguing government reports and documents which security professionals might find interesting. First, the CERT/CC and the Secret Service released a joint report titled Insider Threat Study. It's based on "23 incidents carried out by 26 insiders in the banking and finance sector between 1996 and 2002. Organizations affected by insider activity in this sector include credit unions, banks, investment firms, credit bureaus, and other companies whose activities fall within this sector. Of the 23 incidents, 15 involved fraud, four involved theft of intellectual property, and four involved sabotage to the information system/network." One of the incidents, mentioned in the beginning of the report, was the case prosecuted by the DoJ on behalf of UBS.

The major findings include:

"- Most of the incidents in the banking and finance sector were not technically sophisticated or complex. They typically involved the exploitation of non-technical vulnerabilities such as business rules or organization policies (rather than vulnerabilities in an information system or network) by individuals who had little or no technical expertise. In 87% of the cases the insiders employed simple, legitimate user commands to carry out the incidents, and in 78% of the incidents, the insiders were authorized users with active computer accounts.

- The majority of the incidents (81%) were devised and planned in advance. Furthermore, in most cases, others had knowledge of the insider's intentions, plans, and/or activities. Those who knew were often directly involved in the planning or stood to benefit from the activity.

- Most insiders (81%) were motivated by financial gain, rather than a desire to harm the company or information system.

- Insiders in this report fit no common profile. Only 23% held a technical position, 13% had a demonstrated interest in hacking and 27% had come to the attention of a supervisor or co-worker prior to the incident.

- Insider incidents were detected by internal, as well as external, individuals including customers.

- The impact of nearly all insider incidents in the banking and finance sector was financial loss for the victim organization: in 30% of the cases the financial loss exceeded $500,000. Many victim organizations incurred harm to multiple aspects of the organization.

- Most of the incidents (83%) were executed physically from within the insider's organization and took place during normal business hours."

The report also cites a 2000 study titled "DoD Insider Threat Mitigation," available in .doc format. I like reading these sorts of studies because they focus on threats, not vulnerabilities. I am always pleased when I see organizations working with law enforcement to prosecute intruders. A new firewall is not going to stop future intrusions; putting criminals in jail will. Don't focus on the vulnerability and forget about the threat!

On the .mil side, I came across fairly new documents from the Air Force describing their new network operations and security posture. It seems after four years of debate the dust is settling around a hierarchical structure led by the Air Force Network Operations and Security Center (AFNOSC). Several Air Force Instructions (AFIs), led by AFI33-115V1 "Network Operations (NETOPS)" (3 May 04) and other 33 series AFIs have redefined the relationship between the AFNOSC and the Air Force network. While the new structure looks good, I was sad to see the name "AFCERT" officially be replaced by "AFNOSC Network Security Division." I understand the desire to give the AFCERT the authority of being AFNOSC-NSD, but the AFCERT name has twelve years of history behind it. My friends still in the AFCERT report they still use the old name and plan to do so.

Read More

Helpful Technology Guides for PCI and RAID

If you ever need to deploy sensors to capture traffic in high load environments, you'll need quality NICs on a fast bus and plenty of hard drive storage. I came across guides for each technology that I thought people might like. The first is a .pdf by Digi.com on Peripheral Component Interconnect (PCI). The second guide describes Redundant Arrays of Inexpensive Disks (RAID). If you want to know what sorts of NICs I prefer, I usually try to deploy Intel products.

Read More

Best Way to Extract a Pcap Session from A Larger Pcap Session?

I was asked today to describe the best way to extract a session from a libpcap file into its own libpcap file. In other words, if I have a large collection of network packets, how can I extract a specific session but keep that information in libpcap format?

The answer I proposed relies on (1) identifying the session of interest and (2) telling Tcpdump what to extract. To meet the first goal, consider using a tool like Tcptrace to identify sessions in a sample.lpc file:

drury:/$ tcptrace -n sample.lpc 
1 arg remaining, starting with 'sample.lpc'
Ostermann's tcptrace -- version 6.4.2 -- Sat May 3, 2003

288 packets seen, 280 TCP packets traced
elapsed wallclock time: 0:00:00.002588, 111282 pkts/sec analyzed
trace file elapsed time: 0:00:37.256768
TCP connection info:
  1: 10.2.2.99:58583 - 216.239.51.107:443 (a2b)      9>   10<  (complete)  (reset)
  2: 10.2.2.99:58584 - 207.171.163.90:80 (c2d)      54>   70<  (complete)
  3: 10.2.2.99:58585 - 204.152.184.73:21 (e2f)      43>   60<  (complete)
  4: 10.2.2.52:22 - 10.2.2.99:54385 (g2h)            1>    1<
  5: 10.2.2.99:58586 - 204.152.184.73:24221 (i2j)    4>    4<  (complete)
  6: 10.2.2.99:58587 - 204.152.184.73:62393 (k2l)    6>    5<  (complete)
  7: 10.2.2.99:58588 - 204.152.184.73:62189 (m2n)    6>    7<  (complete)

If we want to extract session e2f, representing an FTP control channel, we use the following Tcpdump syntax:

drury:/$ tcpdump -n -r sample.lpc
 -w sample.e2f.lpc \( host 10.2.2.99 and port 58585 \)
 or \( host  204.152.184.73 and port 21 \)

If we look at sample.e2f.lpc, we see it has the packets from both sides of the session:

drury:/$ tcpdump -n -r sample.e2f.lpc -c 4
  
10:57:08.044699 10.2.2.99.58585 > 204.152.184.73.21:
 S 3823095630:3823095630(0) win 65535  wscale 1,nop,nop,timestamp 68783950 0> (DF)

10:57:08.124141 204.152.184.73.21 > 10.2.2.99.58585:
 S 2610354460:2610354460(0) ack 3823095631 win 65535
  (DF)

10:57:08.124221 10.2.2.99.58585 > 204.152.184.73.21:
 . ack 1 win 33304  (DF)

10:57:08.212221 204.152.184.73.21 > 10.2.2.99.58585:
 P 1:34(33) ack 1 win 65535  68783958> (DF)

A GUI option involves loading the pcap trace into Ethereal, selecting a packet from the session of interest, rebuilding the stream, and then saving the packets associated with that stream (not the packet contents, however). You could also pass a filter to see only the packets you want and then save them without doing session reconstruction.

If we simply wanted the contents of the session of interest (like application data), not in pcap format, we could use Tcpflow.

Read More

FreeBSD 5.3-BETA1 Released

A significant step has been taken down the road to FreeBSD 5.3. Ken Smith announced the availability of FreeBSD 5.3-BETA1 yesterday. You can download an ISO from one of the mirrors, where the directory for an .iso will look like ftp://ftp10.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/5.3/.

I downloaded an burned the disc 1 .iso to CD and installed it on a Dell PowerEdge 750. It seems to be working fine. I did not have to dance fandango on the keyboard like I did installing a snapshot from June. I did have to bang on the keyboard prior to OpenSSH key generation, however, to provide entropy for a process called by /etc/rc. I hope this is removed in the final RELEASE.

I am looking forward to the removal of the GIANT lock, especially in networking. Robert Watson explains what this means, along with caveats. This should make FreeBSD an even more capable packet capture platform. Check out this great tcpdump-workers thread for a variety of opinions on high-speed packet capture, led by Darren Reed.

Read More

Helix Linux Forensic Live CD

You may already know of the FIRE live forensic CD and the Knoppix-STD security tools CD. Last week I attended a free talk by Ed Skoudis, who spoke about his favorite forensic live CD -- Helix, by Drew Fahey of e-fense. I downloaded Helix 1.4 (2004-07-04), burned it to CD, and it started without incident on a Dell PowerEdge 750.

The major issues with forensic-minded live CDs is the degree to which they avoid touching the host computer's hard drive on boot. You don't want a live CD to mount the host hard drives, since you don't need to mount drives to image them. Helix is safe in this regard; it doesn't touch the drive unless you tell it to. Helix also sports the sorts of tools you'd expect on a forensic CD, including a nice graphical interface to dd and variants sdd and dcfldd.

Probably the most amazing aspect of Helix is its support for Windows. The Helix CD provides distributable Windows binaries, including a Windows shell, that run within Windows. I recommend browsing the Helix screen shots to see how useful this can be. Essentially you could image a running Windows system using Helix. (I don't think this is the best idea, but it's nice to have options.) I recommend the Helix developers also look at the sort of "live response" processes documented in books like Incident Response: Computer Forensics (2nd Ed) and incorporate those features into their great free CD.

It pays to keep an eye on Open Source Digital Forensics for developments in the forensics realm.

Read More

Comments on Firewalls, a New Security Magazine, and Wireless Wiretaps

My response to a thread about the differences between "firewalls" and "intrusion prevention systems" (IPSs) seems to have touched a nerve. A message from someone who works for an IPS vendor stated the following:

"I know that it is unlikely that I can sway you, but I do not see why the investigative role should preclude the protective role. Aren't you arguing that police should not interfere with the criminals of the world?"

I replied:

"I didn't mean to imply that 'the investigative role should preclude the protective role.' I support products which protect targets from exploitation. The best incident is the one that never happens. However, I believe the detection role should not be combined with the protection role.

Remember I stress that detection of failures of protection is more important than detecting attacks.

How can a single product that performs protection know when it has failed to provide protection?

Only a separate detection product, focused on network audit, can do that."
As a follow-up, here's an example implementation of what I mean. Assume your firewall provides access control to port 22 TCP, which offers OpenSSH on several of your DMZ servers. The firewall rules deny all traffic to port 22 TCP except from certain authorized addresses. This is a smart idea since the firewall is configured to protect OpenSSH on these servers from abuse (credential guessing) and exploitation (via zero-day attack, assuming OpenSSH is patched appropriately).

In this situation, I would create a Snort rule that fires whenever an IP not on the authorized list connects to port 22 TCP. That sort of rule detects failures of protection. If for some reason the firewall is misconfigured or fails, and an intruder connects to port 22 TCP on a DMZ server, the detection system will create an alert. A secondary action involves logging session records of all connections to and from the DMZ server if possible, or logging as many sessions as possible.

This advice stands in stark contrast to researchers at Gartner and elsewhere who advocate removing IDS in favor of "deep inspection firewalls." I found an excellent rebuttal of this approach by Mike Fratto in the relatively new Secure Enterprise magazine. This periodical was first published late last year by the same folks who produce Network Computing, and I encourage readers to subscribe to SE.
I became aware of SE after reading an Internet Week article on the legality of sharing wireless bandwidth. The article features comments by former DOJ'er Mark Rasch, who recently wrote Wi-Fi High Crimes. I've been wondering about the legality of sniffing wireless traffic, and I assumed such activity constituted a wiretap as defined by 18 U.S.C. 2510. Chapter 119 - Wire and Electronic Communications Interception and Interception of Oral Communications. Lawyers seem to prefer wider interpretation of laws so as to proscribe monitoring. Richard Salgado has exemplified this view. A reply to the Rasch article noted that wireless traffic, being radio signals, may be covered by 8 U.S.C. 2511. Interception and Disclosure of Wire, Oral, or Electronic Communications Prohibited, which states:

"(g) It shall not be unlawful under this chapter or chapter 121 of this title for any person--
(i) to intercept or access an electronic communication made through an electronic communication system that is configured so that such electronic communication is readily accessible to the general public;"

Of course, I am not a lawyer, and laws can be re-interpreted at whim. Nevertheless, this sets the groundwork for someone who might be prosecuted by the Feds for passively monitoring wireless traffic. Remember that your state statutes might expressly forbid the same activity the Feds consider to be legal.

Read More

InfoWorld published two articles of interest to the intrusion detection community this week. Network Detectives Sniff for Snoops is a review of "Internet Security Systems (ISS) Proventia G200, Lancope StealthWatch 4.0, Snort 2.10, and StillSecure Border Guard 4.3." I think they meant "Snort 2.1.0." Already you might suspect I have problems with this first article, which was done at the Naval Postgraduate School in Monterey, CA.

My major concerns with product reviews of this sort is their focus on alert-centric intrusion detection at the expense of other forms of network security monitoring data. Session, full content, and statistical data are completely ignored. Most reviews judge products primarily on their capability to identify "attacks," which in this case included "both live Internet traffic and a variety of attacks we launched from penetration testing tool Core Impact 4.0."

When an attack is launched, the IDS is judged to be "good" if it blinks its red light, and "bad" if the light stays dark. No mention is made of the analyst's capability to perform true incident analysis or the ability to determine how the product made its detection decision. The review stops with attack detection and does not consider the ability to track the intruder beyond the event which triggered an alert, let alone looking for non-alert evidence of prior intruder activity.

All reviewers also include a caveat like this:

"Its [Snort's] main weakness is its dependence on (sometimes poor) signatures. As with all signature-based IDSes, Snort can be defenseless against unknown or 'zero-day' attacks until a signature becomes available."

Unfortunately, dealing with events for which there is no signature or anomaly is the primary problem with all detection products. I believe that administrators should deploy network audit devices that detect failures in protection as well as keep records of all network activity, within the bounds set by legal, technical, and administrative policies. Products which focus on detecting "attacks" are merely documenting possible exploitation events. They are most useful against well-defined events like worm outbreaks but nearly worthless for incident scoping against rogue insiders, stealthy intruders, and unknown exploit techniques.

I was pleased to see some discussion of true enhancements to detection capabilities in the review. Areas like active asset discovery, vulnerability correlation, and passive mapping only make the analyst's job easier. These "contextuals" (as Marty says) give the analyst a better idea of his defensive landscape and should receive more attention in future IDS reviews.

The areas covered by popular IDS reviews which do matter (to a lesser degree) are those that make life easier for the administrator and analyst. These include sensor deployment, rule management, and reporting. Reports on these features (especially installation) remind me of nearly every Linux review published; most people want to know if the installer is an X application or a series of text-based instructions. Because it's hard for most people to judge the power of a new scheduler or the network capture improvements of device polling, reviewers spend their time on other matters.

Sguil users know sensor deployment, rule management, and reporting are lacking in our tool, but we are working on each. Sguil 0.5.2, for example, features new reporting features courtesy of Steve Halligan.

Editor Steve Fox wrote the second interesting article, The Luck of the Virus, subtitled "There's a reason you need intrusion detection systems." The article ends in a light-hearted discussion of the funny names attached to many open source products:

"Snort creator Martin Roesch — founder of security pioneer Sourcefire and an InfoWorld 2004 Innovator — confirmed our suspicions about the open source crowd in a post-test conversation. ACID, he confided, is on its way out as the preferred Snort GUI, soon to be replaced by SGUIL. And what does that stand for? Snort Graphical User Interface for Losers, of course.

That’s a winner in our book."

While that makes for a cute story, Sguil users know the "L" doesn't stand for "Losers." When I contacted Steve by email, he graciously offered to publish a reply from the Sguil team. Bamm decided to roll with the tone of the article and not publish a correction. I ask all Sguil users and potential users to not take such articles too seriously, and let our tools speak for themselves.

Read More

Need Help Proofreading My Book

In preparation for the second printing of The Tao of Network Security Monitoring: Beyond Intrusion Detection, my publisher has tasked me to find typos in the text. So far I've fairly thoroughly checked chapters 1 to 14. If anyone has found typos needing correction in chapters 15-18 and in the epilogue and appendices, I would really appreciate hearing about it. I am making changes to a copy of the book itself and plan to ship it via Priority Mail to my publisher Thursday afternoon. If you have any comments, please email them to taosecurity at gmail dot com. Thank you!

Update: Errata for the first printing are now online. Aside from minor typo changes, the one set of corrections I recommend readers check is the reference to figures in Appendix A. I've got an "off by one" error for the references to TCP sequence number figures.

Read More

Passive Asset Detection System Catalogs Hosts Offering Services

I'm happy to report successful use of Matt Shelton's Passive Asset Detection System (PADS). PADS watchs network traffic and tries to recognize and record services it sees. I was able to compile and run PADS on Red Hat 9.0 and FreeBSD 5.2.1. Here is a sample run with PADS in the foreground. Because I do not specify the network to watch (with the "-n" switch), PADS reports every host offering a service:

drury:/$ sudo pads -i fxp0

pads - Passive Asset Detection System

v1.1 - 08/14/04

Matt Shelton 



[-] Processing Existing assets.csv

[-] Listening on interface fxp0



[*] Asset Found:  IP Address - 10.2.2.99 / MAC Address

 - XX:30:48:XX:f9:56

[*] Asset Found:  Port - 0 / Host - 10.2.2.98 / Service

 - ICMP / Application - ICMP

[*] Asset Found:  Port - 80 / Host - 66.35.250.209 / Service

 - www / Application - Apache 1.3.26 (Unix)

[*] Asset Found:  Port - 80 / Host - 66.35.250.203 / Service

 - www / Application - Apache 1.3.27 (Unix)

^C

[*] 1587 Packets Received

[*] 0 Packets Dropped by Software

[*] 10 Packets Dropped by Interface



[-] Closing PCAP Connection

You can run PADS as a daemon by activating the "-d" switch. To view the results in an analyst-friendly manner, use pads-report:

drury:/$ pads-report -r assets.csv 

pads-report - PADS Text Reporting Module

1.1 - $Date: 2004/08/14 23:58:49 $

Matt Shelton 



1 ------------------------------------------------------

IP:       10.2.2.98

DNS:      mydns.mysite.com

ICMP:     Enabled



2 ------------------------------------------------------

IP:       10.2.2.99

DNS:      drury.mysite.com.

MAC(s):   XX:30:48:XX:f9:56  (2004/08/17 15:50:38)



3 ------------------------------------------------------

IP:       66.35.250.203

DNS:      sourceforge.net



Port  Service    Application                   

80    www        Apache 1.3.27 (Unix)          



4 ------------------------------------------------------

IP:       66.35.250.209

DNS:      projects.sourceforge.net



Port  Service    Application                   

80    www        Apache 1.3.26 (Unix)          

If you prefer to parse the results yourself, they are stored in a CSV file:

drury:/$ cat assets.csv 

10.2.2.99,0,0,ARP,XX:30:48:XX:f9:56,1092772238

10.2.2.98,0,1,ICMP,ICMP,1092772238

66.35.250.209,80,6,www,Apache 1.3.26 (Unix),1092772238

66.35.250.203,80,6,www,Apache 1.3.27 (Unix),1092772391

I believe this is a useful tool to run on sensors to quickly catalog the systems and services they see. Note that if a system in the watched network does not offer any services, and does not reply to ICMP echo packets with ICMP echo replies, PADS will not see them.

PADS makes it decisions using a pads-signature-list file which has entries like the following:

# WWW Signatures

www,v/Apache/$1//,Server: Apache\/([\S]+)[\r\n]

www,v/Apache/$1/$2/,Server: Apache\/([\S]+)[\s]+\((.*)\)

www,v/Apache/$1/$2/,Server: Apache\/([\S]+)[\s]+([\S]+)

www,v/Apache///,Server: Apache[\r\n]

PADS is unlike p0f in that p0f identifies operating systems passively, which PADS identifies hosts offering services. I'd like to see PADS do both, if possible.

Update: A buffer overflow vulnerability was found in PADS 1.1. Be sure to upgrade to 1.1.1.

Matt, if you see this, I can't get mail through to your matt at mattshelton dot com or mattshelton at users dot sourceforge dot net accounts. The error I see is:

    host smtp.secureserver.net [64.202.166.12]:

    553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

Read More

New Ethereal Release and Documentation

Ethereal 0.10.6 was released last week, and an up-to-date User's Guide (covering 0.10.5) was just published last Sunday. This document is a good alternative to those who can't afford to buy Syngress' Ethereal Packet Sniffing book. The User's Guide is over 200 pages in .pdf form, although a decent chunk of space is wasted for page and section breaks.

Read More

McAfee Buys Foundstone

McAfee just announced they bought Foundstone "for $86 million in cash, less various adjustments." The consultant core comprised of my former colleagues "will become part of the McAfee Expert Services team." I spoke with one of them and he doesn't foresee any major changes on the consulting side. He expects to continue doing assessments and other security work.

Given the price McAfee paid, McAfee primarily bought Foundstone for its technology and says it "is committed to supporting Foundstone customers and the continued development of the Foundstone technology. Once the transaction closes the company will begin to sell the Foundstone line of products including Foundstone Enterprise, Foundstone FS1000 appliance, Foundstone On-demand Service and Foundstone Professional TL." McAfee expects the transaction to close in the next 60 days.

This acquisition follows McAfee's sale of Network General (famous for its Sniffer) to Silver Lake Partners and Texas Pacific Group for $275 million in cash, "subject to working capital adjustment." McAfee is the former Network Associates; the name change was part of the sale of Sniffer. McAfee trades as MFE and was up over 3% today, exceeding the NASDAQ's gain of nearly 1.5%.

Read More

Perspectives on "Fed's Web Plan"

Today's New York Post opens with the following scare line:

"With little fanfare, the Federal Reserve will begin transferring the nation's money supply over an Internet-based system this month — a move critics say could open the U.S.'s banking system to cyber threats."

Apparently this is not the case. Reading from the Fedline Introduction, we find the following:

"FedLine is the Federal Reserve Bank’s proprietary electronic delivery channel for financial institution access to Federal Reserve financial services, and includes DOS-based FedLine and FedLine for the Web. FedLine for the Web is available to financial institutions for access to financial services deemed low-risk by the Federal Reserve but does not currently offer access to high-risk payment-related applications such as funds transfer." (emphasis added)

Federal Reserve Financial Services documents differentiate between the existing DOS-based, dial-up system and the new Web-based system. An informative Slashdot post by a former FRB Boston staffer explains the NY Post FUD:

"The Fed is not going to be transferring money over the Internet. Clearing and settlement will continue to take place over dedicated, leased, secured IP lines or in data centers with military-level security.

The change being made is how individual commercial banks interface with the computers at the Fed in order in initiate wire transfers and transmit data for bulk transaction processing. FedLine for the Web is a great improvement over the MS-DOS-based systems that are currently in use for small and medium-sized banks. Through these systems, banks do a variety of things, including initiate wire transfers, check intraday overdraft balances, submit batch files for overnight ACH payments processing, and many others."

I find the NY Post article interesting because the writer, Hilary Kramer, emailed to ask my opinion on the issue. Now that I have some background concerning the Fed's move, I know what she meant by "the Fed moving to the Internet with its money transfers." There's a big difference between a system which allows financial institutions to essentially perform online banking and a system used for settlement and clearing!

It may be easier to disrupt a Web-based system, since anyone in the world with Internet connectivity can potentially connect to the new "FedLine for the Web." It's slightly more difficult (and costly) to dial-up the target Fed system, and preserving anonymity is also tougher when making phone calls.

I found the comments by a Fed spokesperon interesting:

"Patti Lorenzen, a spokeswoman for the Federal Reserve, said the agency is taking every precaution. 'Of course, we will not discuss the specifics of our security measures for obvious reasons,' she said. 'We feel confident that this system adheres to the highest standards of security. Without disclosing the specifics, it is important to note that our security controls include authentication, encryption, firewalls, intrusion detection and Federal Reserve conducted reviews.'" (emphasis added)

I highlight the last two points for different reasons. Regarding intrusion detection, I like seeing people tasked with important security decisions still speaking of intrusion detection and not "intrusion prevention," since prevention fails and the "IPS" is a marketing invention. (An IPS is a layer 7 firewall.) On the Fed conducting "reviews," I hope these assessments are done by independent third parties. If the same group who designed the system is auditing it, the Fed is setting themselves up for a fall by violating an important security principle.

Read More

I Told Oprah and Dr Phil to Watch Out...

My Amazon.com book rank has been all over the map -- as high as 2.2 million and as low as 1,011. BestBookBuys.com lists my book at #85 in their Top 100 Sellers. I think this means I am kicking some Oprah and Dr. Phil butt like I promised. Bill Clinton's book is safe at #11... for now. :) Bookpool is now the most trustworthy online vendor selling the book at a steep discount. You can get the book for $27.25 plus shipping. Amazon.com shows no sign of discounting their price, although my publisher has VP-level people working to fix Amazon's pricing errors for all sorts of books. Apparently Amazon is putting more effort and personnel into their other (non-book-selling) stores, which make higher margins.

Read More

RSS Feeds, Bmonday Comments, and Airpwn

Thanks to an email from Jim O'Gorman, I learned of a way to publish a RSS feed, even though Blogger only supports Atom. Try feeding this to your RSS reader. I've been using the Firefox plug-in Sage since Chris Reining's Blog told me about it. Sage supports RSS and Atom in a Firefox sidebar.

Speaking of reading other people's Blogs, I was happy to see positive feedback on my book at Bmonday.com. My thoughts on logging packets allowed through the firewall, rather than logging packets dropped by the firewall, helped Beau identify someone trying to brute force his SQL server.

If you haven't thought about the use of airpwn at DefCon 12, consider the following. Airpwn is a traffic injection tool for 802.11 networks, released to Sourceforge.net last week. Essentially an intruder sniffs for outbound Web image requests, then tries to craft and transmit a response faster than the legitimate server can reply. In most cases the legitimate server loses the race. Combine this capability with the libpng vulnerability and unpatched browsers (like older versions of Mozilla and friends) and you have a wireless exploit system on your hands. One way to avoid becoming a victim on unencrypted wireless links is to tunnel your Web traffic to a safer connection, as I mentioned earlier.

Read More

Snort 2.2.0 Released

Brian just announced the release of Snort 2.2.0 You can look at the main Snort page or the ChangeLog for word on improvements and fixes. Combined with the changes for 2.2.0 RC1, this 2.2.0 release looks impressive. I will shortly update my Sguil installation guide using Sguil 0.5.2, Snort 2.2.0, and the appropriate supporting software.

Read More

New Sguil and Metasploit Releases

Bamm just released Sguil 0.5.1. This is a lot more than a bug fix release. There are some cool new features in Sguil 0.5.1, like enhanced reporting options, regular expressing matching for the autocat function, and searching packet payloads in the client. I will update my installation guide soon, probably by next week. The only major installation issue involves a change in directory structures to support multiple Sguil installations on a single sensor.

Incidentally, it appears the Prelude project has been taking a look at Sguil features. I cover Prelude in chapter 9 of my book, based on help by the Prelude team and their documentation folks at Dreamlab.

Also, the Metasploit Framework has released version 2.2. The Framework page shows new exploits which have been added.

Update: Sguil 0.5.2 was just released on 12 Aug to fix a bug in the autocat function, so don't bother with 0.5.1, as detailed in the CHANGES file.

Read More

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