Public Class Only Two Weeks Away

My only public Network Security Operations class scheduled for 2006 begins in two weeks. The class is almost full, but I have a few seats left. I've published new prices:

• Register by 5 June 2006: $2595/student


• Register by noon on 12 June 2006: $2695/student

I will not be able to accept any more students past noon on Monday 12 June.

ISSA members receive a 10% discount.

This week I will also teach a one day course on Network Security Monitoring with Open Source Tools at the USENIX 2006 Annual Technical Conference in Boston, MA on Friday, 2 June 2006. This is the course to attend if you want to learn the essential components of network security monitoring. We will use tools on my Sguil VM in this class.

Later this summer I will teach a brand new, two day course called TCP/IP Weapons School at USENIX Security 2006 in Vancouver, BC on 31 July and 1 August 2006. Are you a junior security analyst or an administrator who wants to learn more about TCP/IP? Are you afraid to be bored in routine TCP/IP classes? TCP/IP Weapons School is the class you need to take!

Finally, some of you have asked if I might offer courses on the weekend. I am considering a few options.

1. Teach two two-day courses on weekends, with one course on Saturday-Sunday of week one and a second course on Saturday-Sunday of week two. Students could choose to end either or both classes.


2. Teach on one day of the weekend -- probably Saturday, for two or four weeks.

These would be public classes in northern Virginia, probably Fairfax.

For 2007 I am considering offering public classes in one or more of the following locations: northern VA, New York city, Silicon Valley, San Antonio. Do you have any comments on these locations?

Read More

Recommended Reading on Federal IT

CIO Magazine absolutely hammered government IT in its lengthy story Federal I.T. Flunks Out. You wouldn't read that news in FCW. Commenting on the problem is this former IRS CIO:

"Ultimately this is a security threat," says John Reece, a former IRS CIO and now a consultant to the federal government. "If we can't get beyond the legacy systems we have today, while our enemies are starting off with state-of-the-art technology, what's going to happen is they're going to absolutely tear us to pieces again."

Wrong. It's not a security threat. Poor IT management is a vulnerability. Argh.

Read More

Three Threats

I thought three examples of threats, with corresponding vulnerabilities, etc., might help convince those who doubt the proper use of these terms. Let's start with a mythical example: Achilles. I'll use Achilles' point of view.

• Risk: Death of Achilles.


• Asset: Achilles' life.


• Vulnerability: Achilles' heel. (Achilles was invulnerable, save the portion of his heel where his mother held while dipping him in the River Styx. This is the most popular version of the myth.)


• Threat: Paris, who shot Achilles in the heel with an arrow.


• Exploit: The arrow show by Paris.

Let's now look at an example from one of the best movies of all time: The Karate Kid. I'll use Daniel's point of view.

• Risk: Loss of tournament, thereby letting Johnny Lawrence win.


• Asset: Daniel LaRusso's fighting ability.


• Vulnerability: Leg injured in previous fight.


• Threat: Johnny Lawrence.


• Exploit: Strike to the injured leg.

Man, that was funny. Here is the third example, from Star Wars. (Don't make me quote the episode -- this is geeky enough already.) I'll use the Empire's point of view.

• Risk: Loss of the Death Star and Imperial prestige.


• Asset: The Death Star.


• Vulnerability: "An analysis of the plans provided by Princess Leia has demonstrated a weakness in the battle station... It's a small thermal exhaust port, right below the main port. The shaft leads directly to the reactor system. A precise hit will start a chain reaction which should destroy the station."


• Threat: X-Wings, e.g: "[T]he Empire doesn't consider a small one-man fighter to be any threat, or they'd have a tighter defense." (Bravo Lucas!)


• Exploit: "The shaft is ray-shielded, so you'll have to use proton torpedoes."

Getting the hang of it? Try representing the Star Wars example from the Rebellion's point of view. It's fun, really.

Read More

Threat Term Used Properly in Government Report

It's time once again to talk about threats! Yes, you guessed it. While reading back issues of FCW I encountered good -- and bad -- uses of the term "threat." Mostly, threat was used where vulnerability should have appeared. Let's briefly review the definition I provided in my books:

A threat is a party with the capabilities and intentions to exploit a vulnerability in an asset.

A vulnerability is a weakness in an asset that could lead to exploitation.

For example, an intruder (the threat) exploits a hole (the vulnerability) in Microsoft IIS to gain remote control of a Web server. In other words, threats exploit vulnerabilities.

I've written about proper use of the term threat many times before. Let's look at a few examples from FCW that show why it's important to use the right term when communicating among security professionals.

First, consider the article Cybersecurity research plan identifies threats. The story discusses the Federal Plan for Cyber Security and Information Assurance Research and Development (.pdf).

Using proper terminology, I would expect this article to discuss plans by mostly law enforcement, intelligence, and military groups to investigate organized crime, state-sponsored groups, foreign intelligence services, and so on. Perhaps honeypot operators would also be involved tracking botnet herders and the like. I can't tell from reading the article. Here are two places where "threat" is used:

The report identifies critical threats to the nation’s information technology infrastructure and recommends that the government pay for research that would enable manufacturers to build IT security safeguards into infrastructure systems before they are delivered to power plants or other high-risk facilities.

That sounds like a discussion of vulnerabilities. When the term "safeguard" is used, it's a synonym for "countermeasure."

One of the action points is the following:

Focusing on threats with the greatest potential impact.

Again, I can't tell if the article is correctly referring to malicious parties, or incorrectly referring to the most serious vulnerabilities.

Thankfully, when I read the report, I see proper terminology in play:

Cyber threats are asymmetric, surreptitious, and constantly evolving ­ a single individual or a small group anywhere in the world can inexpensively and secretly attempt to penetrate systems containing vital information or mount damaging attacks on critical infrastructures. Attack tools and resources. (p. ix)

Bravo. Page 5 offers definitions:

A vulnerability is a flaw or weakness in the design or implementation of hardware, software, networks, or computer-based systems, including security procedures and controls associated with the systems. Vulnerabilities can be intentionally or unintentionally exploited to adversely affect an organization's operations (including missions, functions, and public confidence), assets, or personnel.

A threat is any circumstance or event with the potential to intentionally or unintentionally exploit one or more vulnerabilities in a system resulting in a loss of confidentiality, integrity, or availability. Threats are implemented by threat agents. Examples of threat agents are malicious hackers, organized crime, insiders (including system administrators and developers), terrorists, and nation states.

Risk is a combination of the likelihood that a particular vulnerability in an organization's systems will be either intentionally or unintentionally exploited by a particular threat agent and the magnitude of the potential harm to the organization's operations, assets, or personnel that could result from the loss of confidentiality, integrity, or availability.

Notice this report recognizes that vulnerability and threat are not synonyms! The report later names Malicious Hackers, Organized Crime, Terrorists, and Nation States as threats.

Let's close with an example of how not to use the term threat: SCADA on thin ice: Industrial control systems pose little-noticed security threat. "Little-noticed threat"? Maybe SCADA is little noticed as a "threat" because it suffers vulnerabilities.

Elsewhere in the story, however, the term vulnerability is used properly, and threat doesn't make a repeat appearance, save the following. For example:

Control systems security is one of six areas of critical vulnerabilities Borg included in a new cybersecurity checklist released in April by the research group...

Even if a facility has not been attacked, that doesn’t mean it’s secure or the threat isn’t real, said Michael Assante.

What is happening here? Reporters usually don't choose the titles for their stories. My guess is some editor at FCW decided to use the term "threat" where "vulnerability" should have appeared. Threat is shorter (fewer syllables = good) and sexier -- too bad it's wrong in this case.

Read More

DoD Certification Program Update

I've had a chance to read issues of Federal Computer Weekly delivered while I was on vacation. I like reading FCW because it gives me some insight into the madness found inside the Beltway.

I enjoyed reading Wanted: Information assurance-savvy people, which discussed DoD's plans for certifying IT staff. I've examined this issue before. Here's a quote by someone who understands the problems with DoD's plan:

Alan Paller, director of research at the SANS Institute, said DOD should have no problem meeting its initial target of 80,000-plus employees trained and accredited in information assurance. But he doesn’t think the baseline certification that DOD requires will produce a workforce capable of securing the military’s systems.

“The problem is that the bulk of the certifications don’t teach people how to do security,” Paller said. “Certified people will be able to talk about security, but they won’t know how to do it — to actually encrypt data and do the necessary work.”

Instead, DOD needs a way to evaluate actual information assurance work, Paller said. That requires hand-on training and scenario-based testing, he added.

Alan is absolutely right. A DoD certification program which accepts the CISSP as the top technical certification indicates the program designers are absolutely clueless.

Speaking of clueless:

Robert Lentz, DOD’s director of information assurance, said he respects Paller’s opinion but is not worried that the program is headed in the wrong direction. The important thing is to get baseline certifications awarded and then work from there, Lentz said.

Assuming the reported depicted Mr. Lentz's words accurately, I am extremely disappointed by this opinion. This attitude sounds to me like the following: "Who cares if our program is wrong? Let's just get it started." That is a recipe for failure, especially considering this quote from the article:

DOD’s success with IA training and certification could have wider implications, said Jim Flyzik, president of the Flyzik Group, a consulting firm. If successful, DOD’s approach would probably be adopted in other areas of government, he said.

Great. DoD starts down the wrong path, and the rest of the government follows? Ouch.

Read More

The Worst of All Possible Worlds

Sometimes I read configuration guides that advise installing anti-virus products on servers. Since I don't run Windows servers in production environments, I can usually ignore such advice. The proponents of the "anti-virus everywhere" mindset think that adding anti-virus is, at the very least, a "defense-in-depth" measure. This was debated last year, actually.

A lesson I learned from the excellent book Protect Your Windows Network is that "defense-in-depth" is not a cost-free justification for security measures. Every configuration and installation aspect of a system provides benefits as well as costs. Something implemented for "defense-in-depth" (whether truly believed to be helpful, or ignorantly applied) may turn out to harm a system.

Thanks to Harlan Carvey, I learned of another example of a defense-in-depth technique damaging security. This is the worst of all possible worlds -- adding a security measure that results in massive vulnerability. This upcoming eEye advisory warns:

A remotely exploitable vulnerability exists within the Symantec Antivirus program. This flaw does not require any end user interaction for exploitation and can compromise affected systems, allowing for the execution of malicious code with SYSTEM level access.

So you add anti-virus to a server, and BANG. 0wn3d.

Harlan focused on the following quote in the email he sent me:

"People shouldn't panic," [eEye's] Maiffret said. "There shouldn't be any exploits until a patch is produced."

This is a reference to the fact that once a patch is released, white, gray, and black hat security researchers race to analyze it to identify the vulnerable code fixed by the patch. Harlan wonders (accurately) if the underground (or others) already know about this vulnerability, and whether they are already exploiting it.

Keep this case in mind if you believe that "adding security" is a cost-free endeavor.

Read More

Security Clearance Story Continues

Apparently the Defense Security Service has resumed "processing initial Secret requests." That is "security officer"-speak meaning DSS is again working on requests for Secret clearances from people who have not held them before.

The notice continues: "DISCO [Defense Industrial Security Clearance Office] will begin processing initial Top Secret requests and periodic reinvestigation requests for both Secret and Top Secret upon receipt of additional funding." That means those who have not held a Top Secret clearance but require one will still wait. Also in the queue are those needing a periodic reinvestigation for their Secret or TS clearance.

The Washington Post noted that Congressman Davis planned to hold a hearing a week ago on the affair, but I can't find any transcripts.

I thought the comments in the SANS Newsbites Vol 8 Issue 41 (link will work shortly) were astute:

Editor's Note (Pescatore): What is really needed is a review to determine if the clearance process actually provides any security value, and if security clearances are being required for positions that really don't need them. A knee jerk reaction to just throw more money to pay for more background investigations just perpetuates long time problems in the entire process.

I agree with the first point, but the second would require a huge overheaul of the Federal information classification system. This is definitely needed (see a recent Schneier post) but wouldn't affect the clearance issue for years.

(Weatherford): I wonder if this temporary shutdown was simply a way for DSS to cry for help and get the government's attention. This has been a problem for years. Maybe now they will get the funding required to eliminate the backlog.

Wonderful comment. It's funny that DSS "identified funding" right before a Congressional hearing.

(Shpantzer): The situation is so bad that some technical staffing companies providing cleared employees to the government actually put the cart before the horse: They find cleared people first, then train them up to technical requirements... If that's not scary, I don't know what
is.

Here's a scarier thought: that is standard practice. Everyone does it.

(Paller): The "clearance first" policies of many agencies has led them to make people who have never secured a system responsible for telling people how to secure systems. In other agencies, contractors with abominable delivery records are being kept on, over the objections of those who take security seriously, because the ineffective contractors have people with clearances.

Another scary thought: these same clearance-holding contractors are exchanged between employers when the employee decides to switch jobs.

Incidentally, I put security officer in quotes when I mentioned the term earlier. I did that because it reminded me of the different sorts of people who perform work under the "security" umbrella. Far too many "security officers" are just paper-pushers. They are experts in the arcane world of passing clearance information when people visit remote locations. They read people into programs and out of programs. The maintain a lot of paperwork. They hold a lot of clearances but generally do not use the information in a productive manner.

These sorts of people can be in demand due to the clearances they hold, but they bring absolutely no expertise to technical problems. In some ways they remind me of "security auditors" who understand checklists but have no real idea if the checklist corresponds to any true security value.

If you thought I disliked the CISSP as a worthless indicator of practical security knowledge, imagine my attitude towards security clearances.

Read More

Host Fingerprinting with SinFP

I tried SinFP today. It's a host fingerprinting tool by Patrice Auffret, owner of the cat. The SinFP feature I find interesting is its lack of using odd packets (a la Nmap) to discover remote operating systems.

I tried installing SinFP using CPAN on FreeBSD 6.0, but I got the following errors.

cpan> install Net::SinFP
CPAN: Storable loaded ok
LWP not available
Fetching with Net::FTP:
  ftp://archive.progeny.com/CPAN/authors/01mailrc.txt.gz
Going to read /usr/local/cpan/sources/authors/01mailrc.txt.gz
LWP not available
Fetching with Net::FTP:
  ftp://archive.progeny.com/CPAN/modules/02packages.details.txt.gz
Going to read /usr/local/cpan/sources/modules/02packages.details.txt.gz
  Database was generated on Sun, 21 May 2006 09:26:33 GMT
  HTTP::Date not available

  There's a new CPAN.pm version (v1.87) available!
  [Current version is v1.7602]
  You might want to try
    install Bundle::CPAN
    reload cpan
  without quitting the current session. It should be a seamless upgrade
  while we are running...

LWP not available
...edited...
Running install for module Net::SinFP
Running make for G/GO/GOMOR/Net-SinFP-1.01.tar.gz
LWP not available
Fetching with Net::FTP:
  ftp://archive.progeny.com/CPAN/authors/id/G/GO/GOMOR/Net-SinFP-1.01.tar.gz
CPAN: Digest::MD5 loaded ok
LWP not available
Fetching with Net::FTP:
  ftp://archive.progeny.com/CPAN/authors/id/G/GO/GOMOR/CHECKSUMS
Checksum for /usr/local/cpan/sources/authors/id/G/GO/GOMOR/Net-SinFP-1.01.tar.gz ok
Scanning cache /usr/local/cpan/build for sizes
x Net-SinFP-1.01/
x Net-SinFP-1.01/lib/
x Net-SinFP-1.01/lib/Net/
x Net-SinFP-1.01/lib/Net/SinFP/
x Net-SinFP-1.01/lib/Net/SinFP/DB/
x Net-SinFP-1.01/lib/Net/SinFP/DB/SystemClass.pm
...edited...
t/01-use....Can't locate DBIx/SQLite/Simple.pm in @INC (@INC contains: 
/usr/local/cpan/build/Net-SinFP-1.01/blib/lib /usr/local/cpan/build/Net-SinFP-1.01/blib/arch 
/usr/local/lib/perl5/5.8.8/BSDPAN /usr/local/lib/perl5/site_perl/5.8.8/mach 
/usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl 
/usr/local/lib/perl5/5.8.8/mach /usr/local/lib/perl5/5.8.8 .) at 
/usr/local/cpan/build/Net-SinFP-1.01/blib/lib/Net/SinFP.pm line 72.
Compilation failed in require at t/01-use.t line 4.
BEGIN failed--compilation aborted at t/01-use.t line 4.
t/01-use....dubious                                                          
        Test returned status 2 (wstat 512, 0x200)
DIED. FAILED test 1
        Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/01-use.t     2   512     1    2 200.00%  1
Failed 1/1 test scripts, 0.00% okay. 1/1 subtests failed, 0.00% okay.
*** Error code 2

Stop in /usr/local/cpan/build/Net-SinFP-1.01.
  /usr/bin/make test -- NOT OK
Running make install
  make test had returned bad status, won't install without force

That's no good. Next I tried downloading the tar.gz archive, which did work.

orr:/usr/local/src# fetch http://umn.dl.sourceforge.net/sourceforge/sinfp/SinFP-1.01-6.tar.gz
SinFP-1.01-6.tar.gz                           100% of 2524 kB  470 kBps
orr:/usr/local/src# tar -xzvf SinFP-1.01-6.tar.gz 
x SinFP-1.01-6/
x SinFP-1.01-6/LICENSE
x SinFP-1.01-6/LICENSE.Artistic
x SinFP-1.01-6/Makefile
x SinFP-1.01-6/dbi/
x SinFP-1.01-6/dbi/DBI-1.50/
x SinFP-1.01-6/dbi/DBI-1.50/Changes
...edited...
orr:/usr/local/src# cd SinFP-1.01-6
orr:/usr/local/src/SinFP-1.01-6# make
cd dbi        && GOMOR_PATH=/usr/local/sinfp perl Makefile.PL && make install
...edited...
Manifying ../blib/man3/Net::Write.3
Manifying ../blib/man3/Net::Write::Layer4.3
orr:/usr/local/src/SinFP-1.01-6# make install
cd dbd-sqlite && GOMOR_PATH=/usr/local/sinfp make install
...edited...
Installing /usr/local/sinfp/bin/sinfp.pl
Installing /usr/local/sinfp/bin/np-anon-pcap.pl
Writing /usr/local/sinfp/lib/auto/gomor/.packlist
FreeBSD: Registering installation in the package database
Appending installation info to /usr/local/lib/perl5/5.8.8/mach/perllocal.pod
if [ ! -d /usr/local/sinfp/bin ]; then mkdir /usr/local/sinfp/bin; fi
if [ ! -d /usr/local/sinfp/db  ]; then mkdir /usr/local/sinfp/db ; fi
rm -rf /usr/local/sinfp/bin/*
cp gomor/Net-SinFP-*/sinfp.pl        /usr/local/sinfp/bin/
cp gomor/Net-SinFP-*/np-anon-pcap.pl /usr/local/sinfp/bin/
cp gomor/Net-SinFP-*/sinfp.db        /usr/local/sinfp/db/

That worked. Now I had a few new programs to try:

orr:/usr/local/src/SinFP-1.01-6# cd /usr/local/sinfp/bin/
orr:/usr/local/sinfp/bin# ls
np-anon-pcap.pl sinfp.pl
orr:/usr/local/sinfp/bin# ./sinfp.pl 

  -- SinFP - 1.01 --

Usage: sinfp.pl -i targetIp [-p openTcpPort] [-d device] [-f pcapFile]
       [-I sourceIp] [-r retryNumber] [-t timeout] [-v]
       [-m targetMac (for IPv6)] [-M sourceMac (for IPv6)]
       [-s signatureFile]
       [-4 | -6]
       [-P] [-F filter]
       [-H]
       [-O]

       -4: default, use IPv4 fingerprinting
       -6: use IPv6 fingerprinting
       -k: keep generated pcap file. Not by default.
       -P: passive fingerprinting
       -F: pcap filter for passive fingerprinting
       -H: use HEURISTIC2 mode to match signatures
           (mostly used as a human helper, or for passive OSFP)
       -O: print only operating system

Let's try profiling a nearby Win XP SP2 box:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.3 -p 445
T1: B11111 F0x12 W16616 O0204ffff M1460
T2: B11111 F0x12 W17520 O0204ffff010303000101080a000000000000000001010402 M1460
T3: B11011 F0x04 W0 O0 M0
IPv4: EXACT/FULL: Windows: Microsoft: Windows: 2000 (2000 srv SP2)
IPv4: EXACT/FULL: Windows: Microsoft: Windows: XP (XP pro SP2)

Here is the traffic:

1. 16:04:36.260439 IP 192.168.2.5.52221 > 192.168.2.3.445: S 1284670681:1284670681(0) win 5840
2. 16:04:36.261074 IP 192.168.2.5.52221 > 192.168.2.3.445: S 1284670681:1284670681(0) win 5840
3. 16:04:36.261321 IP 192.168.2.3.445 > 192.168.2.5.52221: S 3314059019:3314059019(0) ack 1284670682 
 win 16616 mss 1460
4. 16:04:36.261385 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
5. 16:04:36.261439 IP 192.168.2.5.52222 > 192.168.2.3.445: S 1284670682:1284670682(0) win 5840
 mss 1460,timestamp 1145389380 0,wscale 1,sackOK,eol
6. 16:04:36.261828 IP 192.168.2.5.52223 > 192.168.2.3.445: S 1284670683:1284670683(0) ack 1457354825
 win 5840
7. 16:04:36.262164 IP 192.168.2.3.445 > 192.168.2.5.52221: S 3314059019:3314059019(0) ack 1284670682
 win 16616 mss 1460
8. 16:04:36.262207 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
9. 16:04:36.262357 IP 192.168.2.5.52221 > 192.168.2.3.445: R 1284670682:1284670682(0) win 0
10. 16:04:36.269336 IP 192.168.2.5.52222 > 192.168.2.3.445: S 1284670682:1284670682(0) win 5840
 mss 1460,timestamp 1145389380 0,wscale 1,sackOK,eol
11. 16:04:36.270075 IP 192.168.2.5.52223 > 192.168.2.3.445: S 1284670683:1284670683(0) ack 1457354825
 win 5840
12. 16:04:36.275180 IP 192.168.2.3.445 > 192.168.2.5.52222: S 574001478:574001478(0) ack 1284670683
 win 17520 mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK
13. 16:04:36.275252 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0
14. 16:04:36.275759 IP 192.168.2.3.445 > 192.168.2.5.52222: S 574001478:574001478(0) ack 1284670683 
 win 17520 mss 1460,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK
15. 16:04:36.275805 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0
16. 16:04:36.275958 IP 192.168.2.3.445 > 192.168.2.5.52223: R 1457354825:1457354825(0) win 0
17. 16:04:36.276265 IP 192.168.2.3.445 > 192.168.2.5.52223: R 1457354825:1457354825(0) win 0
18. 16:04:36.276915 IP 192.168.2.5.52222 > 192.168.2.3.445: R 1284670683:1284670683(0) win 0

What strikes me about this traffic is the fact that it is not incredibly unusual. Sure, the pattern is not normal (there's no reason for the scanning host to send a SYN ACK packet), but the average sys admin is not going to detect this sort of reconnaissance. Here's the pattern.

1. Scanner: SYN


2. Scanner: SYN


3. Target replies: SYN ACK


4. Scanner tears down: RST


5. Scanner: SYN with options


6. Scanner: unsolicied SYN ACK


7. Target replies to SYN: SYN ACK


8. Scanner tears down: RST


9. Scanner tears down: RST


10. Scanner: SYN with options


11. Scanner: unsolicied SYN ACK


12. Target replies to SYN: SYN ACK


13. Scanner tears down: RST


14. Target replies to SYN: SYN ACK


15. Scanner tears down: RST


16. Target replies: RST


17. Target replies: RST


18. Scanner tears down: RST

Here are a few other runs. First, against

richard@janney:~$ uname -a
Linux janney 2.4.27-3-686-smp #1 SMP Wed Feb 8 12:27:28 UTC 2006 i686 GNU/Linux

Linux on i386:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.7 -p 22 
T1: B10111 F0x12 W5840 O0204ffff M1460
T2: B10111 F0x12 W5792 O0204ffff0402080affffffff4445414401030300 M1460
T3: B11110 F0x04 W0 O0 M0
IPv4: EXACT/FULL: GNU/Linux: OSS: Linux: 2.6.x (2.6.3)

Next,

richard@thornton:~$ uname -a
Linux thornton 2.6.8-2-32-smp #1 SMP Wed Aug 24 17:55:41 UTC 2005 parisc GNU/Linux

Linux on PA-RISC:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.15 -p 22
T1: B10111 F0x12 W5840 O0204ffff M1460
T2: B10111 F0x12 W5792 O0204ffff0402080affffffff4445414401030300 M1460
T3: B11110 F0x04 W0 O0 M0
IPv4: EXACT/FULL: GNU/Linux: OSS: Linux: 2.6.x (2.6.3)

Next, against the earlier Windows box, to a closed port:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 192.168.2.3 -p 22
T1: B11001 F0x14 W0 O0 M0
T2: B11001 F0x14 W0 O0 M0
T3: B11011 F0x04 W0 O0 M0
IPv4: unknown

Against www.freebsd.org:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 216.136.204.117 -p 80
T1: B11111 F0x12 W57344 O0204ffff M1460
T2: B11111 F0x12 W57344 O0204ffff010303000101080affffffff44454144 M1460
T3: B00000 F0 W0 O0 M0
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.7
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.9
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.10
IPv4: EXACT/FIREWALLED: BSD: OSS: FreeBSD: 4.11 (4.11-RELEASE)

Against one of the www.microsoft.com IPs:

orr:/usr/local/sinfp/bin# ./sinfp.pl -i 207.46.198.30 -p 80
T1: B11011 F0x12 W16384 O0204ffff M1460
T2: B11011 F0x12 W16384 O0204ffff010303000101080a000000000000000001010402 M1460
T3: B00000 F0 W0 O0 M0
IPv4: EXACT/FIREWALLED: Windows: Microsoft: Windows: 2000
IPv4: EXACT/FIREWALLED: Windows: Microsoft: Windows: 2003 (2003 SP1)

Give SinFP a try and let me know what you think as a comment here.

Incidentally, I am definitely not a "cat person." I am a dog person.

Read More

I'm Back

I haven't been blogging for the past two weeks because my family and I were traveling in Europe. Part of our trip included speaking at the University of Cambridge Computer Laboratory Security Group Seminar Series in Cambridge, UK, on network security monitoring. This was the same group I mentioned in February.

I'd like to thank Saar Drimer and Stephen Lewis for arranging my visit. I was fortunate enough to have Professor Ross Anderson, author of Security Engineering, and Frank Stajano, author of Security for Ubiquitous Computing, in the audience. I had lunch with FreeBSD core team developer Robert Watson and Netdude developer Christian Kreibich, both of whom I had wanted to meet for a while. Jolyon Clulow and Steven Murdoch were kind enough to show my family and me the various colleges. As a result of this trip, my family and me are strongly inclined to pursue the PhD program, starting in the fall of 2007.

I have a busy week of consulting lined up, but I hope to post my thoughts on security issues as they continue. A lot has happened in the last two weeks, and I'll do my best to catch up.

Read More

Two Pre-Reviews

Two publishers were kind enough to send me review copies of two of their new books. The first is Windows Forensics: The Field Guide for Corporate Computer Investigations by Chad Steel, published by Wiley. This book looks like more of an introductory text that does not delve too deeply into any single set of specifics. I'm worried that the section that mentions sniffing network traffic talks about "vampire taps." Hello early 1990s and coax cable.

The second book is Hacker's Challenge 3 by David Pollino, Bill Pennington, Tony Bradley, and Himanshu Dwivedi. published by Osborne. I liked the first two books in this series. I think scenarios to test analytical skills are good ways for people to learn security skills. Here's hoping this set of 20 stories offers a mix of problems and solutions.

Read More

Review ofThe Database Hacker's Handbook Posted

Amazon.com just posted my four star review of The Database Hacker's Handbook by NGS Software members David Litchfield, Chris Anley, John Heasman, and Bill Grindlay. From the review:

The Database Hacker's Handbook (TDHH) is unique for two reasons. First, it is written by experts who spend their lives breaking database systems. Their depth of knowledge is unparalleled. Second, TDHH addresses security for Oracle, IBM DB2, IBM Informix, Sybase ASE, MySQL, Microsoft SQL Server, and PostgreSQL. No other database security book discusses as many products. For this reason, TDHH merits four stars. If a second edition of the book addresses some of my later suggestions, five stars should be easy to achieve.

Read More

I've written about problems with security clearances before. Now I read Pentagon Halts Contractor Clearances. I recommend reading the article for details, but the bottom line is this sort of failure requires Congressional investigation. A private company with the same sorts of operational disasters would be without clients and bankrupt by now. The Federal government justs plods along.

Read More

Congratulations to USAFA

My alma mater, the United States Air Force Academy won the sixth annual Cyber Defense Exercise last month. The aggressors were members of NSA's Red Team, and the cadets were the defenders. I'd like to attend one of these exercises and monitor the activities using Sguil. Please send email to taosecurity at gmail dot com if you have any connections. Go Air Force!

Read More

Avoid Incident Response and Forensics Work in These States

Here's an informative and scary article titled Forensic Felonies. It warns of a new Georgia law that may require incident response and forensics investigators to be licensed private investigators. Article author Mark Rasch notes:

Georgia is not the only state that requires private investigators or private detectives to be licensed. Indeed, the Georgia law is in fact modeled after similar laws in California, Arizona, Utah, Nevada, Texas, Delaware, and New York – just to name a few. In each of these cases, the law requires that a person providing the defined "investigative" services for remuneration be licensed in that state as a Private Investigator.

Good grief. This has to be promoted by criminal elements. What a great way to keep security experts from helping identify and remove threats? It's probably also a play by the Private Investigator community to get their hands on more security work. That's similar to an argument I heard from a lawyer once that all security investigations should be run through law firms. That would be the only way to keep findings from prying eyes, thanks to attorney-client privilege. Again, another way for a non-technical party to make money from a technical problem.

Has anyone else encountered this issue?

Read More

More Unrealistic Expectations from CIOs

I found another article containing unrealistic expectations for IT staff. It's in the 1 May 2006 issue of CIO Magazine, titled The Postmodern Manifesto. It begins this way:

The service-fulfillment model for IT is dying. A new philosophy of innovation and productivity is being born. Here’s what CIOs need to do to usher in a new age of IT.

Excuse me? IT as a service is already dying? I know plenty of shops who are only now jumping on the service bandwagon. I guess magazines like CIO have an incentive to write about whatever they consider to be "new," since people want to stay "on the edge." Let's see what advice this article provides.

The Postmodern IT Department will be smaller, more distributed and dependent on a tightly integrated supply chain of vendors. It will be in desperate need of multitalented specialists who have in-depth technology knowledge but who can also create new products and capabilities that businesspeople might never have envisioned.

Yuck. "Postmodern" is a horrible name. What comes next -- PostPostmodern? Here's another buzzword -- "multitalented specialists". Let's hear more about this in the sidebar, The Unexpected Rise of the Multi-Specialist:

While CIOs increasingly demand that their programmers understand the business, they’re also asking for a deeper knowledge of new technologies.

While everyone agrees that IT needs generalists today, a more accurate term might be multi-specialists. Programmers who remain solely programmers will have to be highly specialized and extremely skilled to survive against international competition. Meanwhile, other jobs in IT will require at least a solid grounding in programming, along with a strong specialization in other skills, such as project management and business process (probably both).

Let me get this straight. IT people are expected to be technical experts and business experts? We're supposed to "have in-depth technology knowledge" and simultaneously "create new products and capabilities"?

This attitude really bugs me:

"You can’t say, ‘I can manage but I can’t do,’" says Verizon CIO Shaygan Kheradpir.

Is that true, Mr. Kheradpir? As a CIO you obviously manage. Why don't you try configuring routers or firewalls for a day? How about analyzing security events or writing new Snort rules? Incidentally, you'll have to learn the new Snort rule language to do that. Can't do it? You give up? So sorry!

I think the people who write these articles and the CIOs who feed these unrealistic expectations should remember Adam Smith and his ideas of division of labor. You cannot expect someone, especially in IT, to be an expert in everything. "Multitalented specialists" is another term for "someone who can do the job of two or more people, allowing me to further cut my IT staff."

I spend almost all of my professional time staying current on issues involving network security monitoring, and I struggle like everyone else to make sense of the new threats, vulnerabilities, and assets which comprise the risk equation. I am happy to encounter a person who is at least competent in one specialty, and I am suspicious of those who claim expert knowledge of several areas simultaneously.

Incidentally, I briefly mentioned this same problem in January.

Read More

Snort Dynamic Rules Preview

On my flights to and from the GFIRST 2006 conference this week, I got a chance to read the manual for Snort 2.6.0RC1. The most obvious addition to Snort 2.6 is the ability to add preprocessors, detection capabilities, and rules as dynamically loadable modules. This feature is activated by running configure with the --enable-dynamicplugin switch. Preprocessors and detection capabilities are more of an issue for Snort developers, since few Snort users code their own features. The advantage of the dynamic engine is that developers can write their own modules without having to patch Snort itself.

Most Snort users customize Snort by writing their own rules. Beginning with Snort 2.6.0RC1, the new C-style rule language is in place. If you read the snort_manual.pdf included with snort-2.6.0RC1.tar.gz, you will see a discussion of the new format starting in section 5.1.5 (Dynamic Rules). Here is an example of a rule in the old format:

alert tcp $HOME_NET 12345:12346 -> $EXTERNAL_NET any  (msg:"BACKDOOR netbus active"; 
flow:from_server,established;  content:"NetBus"; reference:arachnids,401; 
classtype:misc-activity;  sid:109; rev:5;)

Here is an example of the same rule in the new format. You can find this rule, sid109.c, in the /src/snort-2.6.0RC1/src/dynamic-examples/dynamic-rule directory.

It looks like this:

/*
 * sid109.c
 *
 * Copyright (C) 2006 Sourcefire,Inc
 * Steven A. Sturges 
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 *
 * Description:
 *
 * This file is part of an example of a dynamically loadable rules library.
 *
 * NOTES:
 *
 */

#include "sf_snort_plugin_api.h"
#include "sf_snort_packet.h"
#include "detection_lib_meta.h"

/*
 * C-language example for SID 109
 *
 * alert tcp $HOME_NET 12345:12346 -> $EXTERNAL_NET any  * (msg:"BACKDOOR netbus active"; 
 * flow:from_server,established;  * content:"NetBus"; reference:arachnids,401; 
 * classtype:misc-activity;  * sid:109; rev:5;)
 *
 */

/* flow:established, from_server; */
static FlowFlags sid109flow = 
{
    FLOW_ESTABLISHED|FLOW_TO_CLIENT
};

static RuleOption sid109option1 =
{
    OPTION_TYPE_FLOWFLAGS,
    {
        &sid109flow
    }
};

/* content:"NetBus";  */
static ContentInfo sid109content = 
{
    "NetBus",               /* pattern to search for */
    0,                      /* depth */
    0,                      /* offset */
    CONTENT_BUF_NORMALIZED, /* flags */
    NULL,                   /* holder for boyer/moore info */
    NULL,                   /* holder for byte representation of "NetBus" */
    0,                      /* holder for length of byte representation */
    0                       /* holder of increment length */
};

static RuleOption sid109option2 = 
{
    OPTION_TYPE_CONTENT,
    {
        &sid109content
    }
};

/* references for sid 109 */
static RuleReference sid109ref_arachnids =
{
    "arachnids",    /* Type */
    "401"           /* value */
};

static RuleReference *sid109refs[] =
{
    &sid109ref_arachnids,
    NULL
};

RuleOption *sid109options[] =
{
    &sid109option1,
    &sid109option2,
    NULL
};

Rule sid109 =
{
    /* protocol header, akin to => tcp any any -> any any */
    {
        IPPROTO_TCP,        /* proto */
        HOME_NET,           /* source IP */
        "12345:12346",      /* source port(s) */
        0,                  /* direction, uni-directional */
        EXTERNAL_NET,       /* destination IP */
        ANY_PORT            /* destination port(s) */
    },
    /* metadata */
    { 
        3,                  /* genid -- use 3 to distinguish a C rule */
        109,                /* sigid */
        5,                  /* revision */
        "misc-activity",    /* classification */
        0,                  /* priority */
       "BACKDOOR netbus active",    /* message */
       sid109refs           /* ptr to references */
    },
    sid109options, /* ptr to rule options */
    NULL,                   /* Use internal eval func */
    0,                      /* Holder, not yet initialized, used internally */
    0,                      /* Holder, option count, used internally */
    0,                      /* Holder, no alert used internally for flowbits */
    NULL                    /* Holder, rule data, used internally */
};

For an explanation of this rule, please see the snort_manual.pdf packaged with Snort 2.6.0RC1. It is not yet online.

For a simple rule like sid 109, the new structure looks very "heavy." However, consider a rule like the following, sid 2258:

alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"NETBIOS SMB-DS DCERPC Messenger Service
 buffer overflow attempt"; flow:to_server,established;  content:"|FF|SMB%"; depth:5; offset:4;
 nocase; content:"&|00|"; within:2; distance:56;  content:"|5C 00|P|00|I|00|P|00|E|00 5C 00|"; 
 within:12; distance:5; nocase;  content:"|04 00|"; within:2; byte_test:1,>,15,2,relative; 
 byte_jump:4,86,little,align,relative;  byte_jump:4,8,little,align,relative; 
 byte_test:4,>,1024,0,little,relative;  reference:bugtraq,8826; reference:cve,2003-0717; 
 reference:nessus,11888;  reference:nessus,11890; 
 reference:url,www.microsoft.com/technet/security/bulletin/MS03-043.mspx;  
 classtype:attempted-admin; sid:2258; rev:9;)

That rule demonstrates the difficulty of writing more complex rules. The new rules structure should make writing rules like sid 2258 easier.

The sid109.c example shown above, and the material in the snort_manual.pdf packaged with Snort 2.6.0RC1,, may not exactly be what is shipped with Snort 2.6.0 or even Snort 3.0.0. Sourcefire has not determined if it will completely replace the old style rule format in favor of the new format. I expect to see Snort 3.0.0 ship with rules in the new format.

Read More