Tuesday, August 31, 2004
"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.
Monday, August 30, 2004
"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.
Sunday, August 29, 2004
Saturday, August 28, 2004
- 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.
Friday, August 27, 2004
Update: Here's how the Slashdot effect looked to TaoSecurity.com:
Here's how the Slashdot effect looked to this Blog:
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!
Thursday, August 26, 2004
"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.
Wednesday, August 25, 2004
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.
Tuesday, August 24, 2004
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 - 184.108.40.206:443 (a2b) 9> 10< (complete) (reset)
2: 10.2.2.99:58584 - 220.127.116.11:80 (c2d) 54> 70< (complete)
3: 10.2.2.99:58585 - 18.104.22.168: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 - 22.214.171.124:24221 (i2j) 4> 4< (complete)
6: 10.2.2.99:58587 - 126.96.36.199:62393 (k2l) 6> 5< (complete)
7: 10.2.2.99:58588 - 188.8.131.52: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 184.108.40.206 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 > 220.127.116.11.21:
S 3823095630:3823095630(0) win 65535
wscale 1,nop,nop,timestamp 68783950 0> (DF)
10:57:08.124141 18.104.22.168.21 > 10.2.2.99.58585:
S 2610354460:2610354460(0) ack 3823095631 win 65535
10:57:08.124221 10.2.2.99.58585 > 22.214.171.124.21:
. ack 1 win 33304
10:57:08.212221 126.96.36.199.21 > 10.2.2.99.58585:
P 1:34(33) ack 1 win 65535
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.
Monday, August 23, 2004
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.
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.
"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 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.
Saturday, August 21, 2004
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.
Tuesday, August 17, 2004
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.
drury:/$ sudo pads -i fxp0
pads - Passive Asset Detection System
v1.1 - 08/14/04
[-] Processing Existing assets.csv
[-] Listening on interface fxp0
[*] Asset Found: IP Address - 10.2.2.99 / MAC Address
[*] Asset Found: Port - 0 / Host - 10.2.2.98 / Service
- ICMP / Application - ICMP
[*] Asset Found: Port - 80 / Host - 188.8.131.52 / Service
- www / Application - Apache 1.3.26 (Unix)
[*] Asset Found: Port - 80 / Host - 184.108.40.206 / Service
- www / Application - Apache 1.3.27 (Unix)
[*] 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 $
MAC(s): XX:30:48:XX:f9:56 (2004/08/17 15:50:38)
Port Service Application
80 www Apache 1.3.27 (Unix)
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
220.127.116.11,80,6,www,Apache 1.3.26 (Unix),1092772238
18.104.22.168,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
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 [22.214.171.124]:
553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
Monday, August 16, 2004
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%.
Sunday, August 15, 2004
"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.
Friday, August 13, 2004
Thursday, August 12, 2004
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.
Wednesday, August 11, 2004
Tuesday, August 10, 2004
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.
Sunday, August 08, 2004
On a related note, I came across this 1996 thread discussing early tap use.
"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.
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:
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
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:
inet 10.2.2.3 netmask 0xffffff00 broadcast 10.2.2.255
media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
ssid LodgeNet 1:LodgeNet
stationname "FreeBSD WaveLAN/IEEE node"
channel 11 authmode OPEN powersavemode OFF powersavesleep 100
wepmode OFF weptxkey 1
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 *:*
The /usr/local/etc/tinyproxy/tinyproxy.conf looks like this:
#List other networks allowed here, like local RFC 1918 space
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 email@example.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 firstname.lastname@example.org
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 126.96.36.199 port 80 command 1
debug1: channel 2: open confirm rwindow 131072 rmax 32768
debug1: channel_free: channel 2: direct-tcpip: listening port
8888 for 188.8.131.52 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 184.108.40.206 port 443 command 1
debug1: channel 2: open confirm rwindow 131072 rmax 32768
This makes life much easier and eliminates the need to add a proxy to your gateway. Thanks Jim!
Friday, August 06, 2004
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.
Wednesday, August 04, 2004
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
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:
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.
Monday, August 02, 2004
- 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.
Sunday, August 01, 2004
"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...