Kundra IPv6 Memo

I've written a few posts on IPv6 here. I read the short Transition to IPv6 Memo (.pdf) written by Federal CTO Vivek Kundra. I'd like to comment on two of the assumptions he makes in that memo:

The Federal government must transition to IPv6 in order to...

1. Reduce complexity and increase transparency of Internet services by eliminating the architectural need to rely on Network Address Translation (NAT) technologies;

2. Enable ubiquitous security services for end-to-end network communications that will serve as the foundation for securing future Federal IT systems;

I find the first point laughable. Anyone who has even obliquely worked with IPv6 knows that adopting the protocol will massively increase complexity, whether IPv6 is used natively or especially if it's used in a conjunction with IPv4. Take a few minutes to look at all the extra addresses an IPv6-enabled system provides to see what I mean. Complexity and unfamiliarity with configuring IPv6 will introduce exposures that intruders will exploit. IPv6 stacks are likely to possess vulnerabilities that intruders will also attack. Finally, did you know that many networks will keep NAT even with IPv6? The "abolish NAT" argument is just false.

The second point represents what I think is a a fundamental misunderstanding concerning IPv6. I've written about this before too, but the point is simple: IPv6 is not inherently more secure than IPv4. You can introduce the same level of "security" in IPv4 as you can with IPv6. In fact, IPv6 is in many ways less secure than IPv4; check out all the auto-configuration protocols included with IPv6. Anyone who thinks making "IPSec mandatory in IPv6" means IPSec must be enabled isn't paying attention. "IPSec mandatory in IPv6" means IPv6 must offer IPSec, not that it be enabled [RMB: fixed error, thank you!]. Since you can run IPv4 with IPSec now, there's no advantage to IPv6 in this regard.

I'd also like to comment on the two major directives in the memo:

In order to facilitate timely and effective IPv6 adoption, agencies shall:

1. Upgrade public/external facing servers and services (e.g. web, email, DNS, ISP services, etc) to operationally use native IPv6 by the end of FY 2012;

2. Upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014;

There's also a footnote for the first point:

To ensure interoperability, it is expected that agencies will also continue running IPv4 into the foreseeable future.

I think the first point means Federal servers will offer IPv4 and IPv6 services. I think they mean dual-stack will be allowed. I think the "native" comment means that Federal servers are not allowed to run only IPv4 but be accessible via an IPv6 gateway.

The second point is probably similar, meaning clients will have IPv6 addresses and speak directly to other IPv6 hosts without requiring gateways. That is going to be a security nightmare since the goal of IPv6 is to restore "end to end connectivity," which is inherently at odds with security.

What's your take on this IPv6 issue?

Tweet

Read More

Review of IPv6 Security Posted

Amazon.com just posted my five-star review of IPv6 Security by Scott Hogg and Eric Vyncke. From the review:

I've read and reviewed three other books on IPv6 in the last four years: IPv6 Essentials, 2nd Ed (IE2E) in September 2006, Running IPv6 (RI) in January 2006, and IPv6 Network Administration (INA) in August 2005. All three were five-star books, but they lacked the sort of attention to security that I hoped would be covered one day. IPv6 Security by Scott Hogg and Eric Vyncke is the book for which we have been waiting. Although some of the early "philosophical" security discussions (what's a threat, where are they) are lacking, the overwhelming amount of thorough and actionable content makes this book a winner.

Read More

Notes from OISF Meeting in DC

This month I was pleased to attend a public meeting of the Open Information Security Foundation in Washington, DC. I got a chance to meet several people I have known for many years through their work with Snort, such as Matt Jonkman, Will Metcalf, Victor Julien, Frank Knobbe, and two guys from a federal agency that have extended Sguil way beyond what I knew anyone was doing! The group posted DC Brainstorming Meeting Notes, but I wanted to record a few thoughts here.

OISF is a US nonprofit, a 501c(3). Their goal is to produce a new network inspection and filtering engine (IDS/IPS) that will be released under GPLv2. They can not and will not commercialize, sell, patent, copyright, or profit from the engine. Rather, others who participate in the OISF Consortium (listed on their Web site) are donating coders, equipment, and financial support in exchange for the ability to commercialize the engine.

OISF works with the Open Source Software Institute, famous for getting FIPS validation for OpenSSL -- something everybody wanted but no one wanted to fund alone. OISF is part of the DHS Homeland Open Security Technology (HOST) program. OISF has received legal guidance from the Software Freedom Law Center.

OISF has many goals for their engine, outlined in the notes I linked earlier. Most interesting is their goal for a production release by the end of this year. If they are to make this goal, I think the project needs to severely limit the requirements for the first release. I would focus on the following.

• Developing the rules language.


• Implementing IPv6.


• Implementing multi-threading.

Those three tasks are monumental, but they would immediately differentiate OISF from other options. There is talk within the project of semi-Snort compatible output, so you might send OISF data to a file in Snort Unified or Unified2 format to be read by Barnyard or Barnyard2.

If you want to know more about the project, the Mailing Lists are the best option. As it develops I will discuss it here.

Read More

SANS Forensics and Incident Response 2009 Summit Round-Up

I'd like to share a few thoughts from the second SANS WhatWorks Summit in Forensics and Incident Response, where I delivered the keynote. I could only attend the first day, but I thought it was definitely worthwhile. I was given a few questions which I promised to answer on this blog, so here they are.

With your background with Information Operations and cyber security, what would you advise the new U.S. Cyber Command? What should their priorities be?

I've written a lot on cyber command over the years. I believe their first priority is to create a real career path for cyber operators. Tools, tactics, and procedures are secondary to attracting and retaining talent. You can accomplish amazing feats if you have the right butts in the seats. Without that, you are guaranteed to fail. Part of that will involve identifying all of the people with cyber duties in the military. Once they have that part working, I would advise Cyber Command to think in terms of a Cyber NORAD.

Five years from now the Verizon Data Breach Report 2014 is published. What trend will be the "big red dot" in 2014? What will be your biggest surprise?

To clarify, the "big red dot" of 2009 was the huge number of records stolen by external parties, far exceeding internal intruders.

This is a really good question. I never see a future where insiders are more dangerous than outsiders. By insiders I mean people formally associated with an organization, e.g., employees, contractors, etc. Outsiders are people who are not formally associated with an organization. Insiders will remain capable of individual large incidents, but outsiders will continue to conduct repeated large and small incidents.

I will be really surprised if IPv6 is changing the way businesses operate in 2014. I think we may see internal business operations (like carrier networks) using IPv6, but I don't think we'll see a substantial user base for IPv6 by 2014. If that is not true I will be surprised.

What do you know about public/private partnerships to leverage known command and control servers? Is there any way for a CIRT to avoid third party notification by performing proactive detection?

There's a few options here. One is to join the Forum of Incident Response and Security Teams (FIRST). FIRST maintains a private mailing list that shares information among members. Another option is to look for private associations among peer businesses. A third idea is to make contact with the many volunteer and commercial security intelligence services organizations, including The Shadowserver Foundation, Support Intelligence, Secure Science, iDefense, and many others.

With the questions answered, I'd like to say I thought Summit organizer Rob Lee did a great job (again) keeping the event moving smartly. Kris Harms, Harlan Carvey, Jamie Butler/Peter Silberman, and Brendan Dolan-Gavitt all delivered great talks. The two user panels I saw (I missed the third) were also excellent.

I wanted to record a few tricks that Kris offered so I don't forget them.

• Use the PsTools handle.exe app and grep for "pid\:" in the output to see a different sort of process list.


• Grep handle.exe output for "Mutant" to see mutexes.


• Pay attention to digital signature output in autorunsc.exe, particularly for results that are not signed and/or not verified; and signed but verification failed. Check hashes against fileadvisor.bit9.com.


• Remember to teach junior analysts a methodology, like:




1. Determine if compromised.


2. Develop investigative leads.


3. Build a timeline.


4. Determine how compromised.


5. Suggest remediation measures.


6. Assess impact of compromise.

While listening to the speakers, it was clear to me the differences between three communities:

1. Intrusion detectors and responders


2. Computer forensics investigators


3. Litigation support and ediscovery investigators

I thought this slide by Jess Garcia from One eSecurity showing one practitioner's opinion on the variety of forensics tools was interesting.



I still need to try MANDIANT Audit Viewer. Jamie Butler and Pete Silberman noted that since MANDIANT Memoryze uses live analysis to access the Windows page file, they don't run into issues found when trying to combine a dead page file with a memory capture.

I'm looking forward to next year! If you do IR, you should try to be there.

---

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Late Las Vegas registration ends 22 July.

Read More

The Security World Is Not Just a Webbed, Virtual, Fluffy Cloud

If you've been watching the digital security scene for a while, you'll notice trends. Certain classes of attack rise and fall. Perceptions of risks from insiders vs outsiders change. I think it is important to realize, however, that globally, security vulnerabilities and exposures are persistent. By that I mean that if we forget or neglect problems from the past (or even present) and focus only the future, we will lost.

For example, the three big themes you'll see in many IT and security discussions are the following.

1. Web apps


2. Virtualization


3. Cloud

If you're not dealing with those three areas, you're a dinosaur, man! Forget all that other stuff you've learned!

The problem with that attitude is that it sees the world through a tunnel of shiny newness.

Consider the following list of recent security issues and see how many of them deal with those three hot topics.

• CPU-level attacks (e.g., Attacking Intel® Trusted Execution Technology)


• MPLS attacks (e.g., All Your Packets Are Belong to Us - Attacking Backbone Technologies)


• BGP attacks (e.g., Defending Against BGP Man-In-the-Middle Attacks


• IPv6 security (e.g., Attacking IPv6)


• Anti-forensics (e.g., SQL Server Anti-Forensics)


• Various nontraditional rootkits (e.g., .NET Framework Rootkits)


• Attacks on cryptography (e.g., MD5 considered harmful today: Creating a rogue CA certificate)


• DNS attacks (e.g., DNS 2008 and the New (old) Nature of Critical Infrastructure)


• Router attacks (e.g., multiple presentations on exploiting Cisco IOS at Black Hat US 2008)

I could continue. The point is there's a lot more to our security problems than Web, VM, and Cloud. It might be simpler to think of only those three problems, but there are at least a dozen more that require attention. This problem makes our security lives more difficult, but also more interesting.

---

Richard Bejtlich is teaching new classes in Europe and Las Vegas in 2009. Online Europe registration ends by 1 Apr, and seats are filling. "Super Early" Las Vegas registration ends 15 Mar.

Read More

IPv6 Tunnel on Windows XP Using Freenet6

Almost two years ago I described testing IPv6 using Freenet6 on FreeBSD. This morning I decided to try the same on Windows XP and document the process here.

I needed to use a tunnel method like Freenet6 because the test host is behind NAT.

First, visit go6.net and click "Free IPv6 Connectivity with Freenet6". Register yourself a user account. To install on my Windows XPSP3 32-bit system I downloaded "Gateway6 Client 6.0-BETA4 Windows Installer 32-bit". I installed and accepted the defaults:



When I first tried installing the software I got an error which denied installing the TUN driver. I had to back out of the installation and change this local group policy key using gpedit.msc:



I changed "Do not allow installation" to "Warn but allow installation" under Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Devices: Unsigned driver installation behavior.



Once The Freenet6 client was running I configured it with the username and password I registered, and I set broker.freenet6.net as my Gateway6 address. Once I connected I could visit ipv6.google.com, and even check my IPv6 address online.



You may notice I installed the ShowIP Firefox addon. I learned about that from Command Information. It's a good way to try to keep track of the IP address you're using to access IPv4 or IPv6 sites.

I was also able to access sites from cmd.exe, using ping6 to ping ipv6.google.com and ftp to connect to the IPv6-only FTP server at ftp6.netbsd.org.



I think the Freenet6 client is a good way for people behind NAT (or in the case of the test VM here, two NATs) to access IPv6-enabled sites.

---

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

Read More

Predictions for 2009

I better get with the program and post my 2009 predictions before any more of the new year slips by. I plan to build on my Predictions for 2008 in Hindsight and add a few new thoughts.

1. Expect greater government involvement in assessing the security of private sector networks. I wasn't inventing this a year ago, and I'm not inventing it now. I'm extrapolating from a trend line. My post Letters You Will Need to Know: 201 CMR 17.00 is just the latest example of increasingly aggressive government involvement in private sector security matters.


2. Expect to start learning about IPv6, or be confused quickly. 2009 is not the year of IPv6, but we're getting there. The US Department of Defense is already grappling with IPv6, despite the compliance charade of mid-2008. Wider adoption of Microsoft Vista and its tunnel mechanisms, along with IPv6-active consumer devices, are driving IPv6 in one form or the other into our lives.


3. Expect at least one cloud security incident to affect something you value. This is not the great Cloud Security blog, but I know many of us are already depending on cloud services. In 2007 and 2008 we started suffering denial when services suffered problems of availability. Next will be disclosure and then degradation. For more on these terms read First They Came for Bandwidth...


4. Expect network security to matter again. I may be a little late on this one, given problems we had with DNS, BGP, and even SSL in 2008. I think these sorts of problems demonstrate that there's lots of vulnerability left outside the platform, operating system, and applications. As IPv6 becomes more important this one is going to the top of the list, probably in 2010.


5. Expect to buy fewer "new" security products. We need to get back to basics by answering the sorts of questions that appeared in my post Marcus Ranum on Network Security. In tough economic times, managers are not going to spend on new equipment if they still don't know what the stuff you just bought does. Spend more time on consolidation and specialization and less time on looking for the next security silver bullet.

Good luck in 2009 everyone. It's going to be a good year -- "fine in '09"!

---

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

Read More

Predictions for 2008 in Hindsight

In late 2007 I posted Predictions for 2008, my first foray into the world of prognostication. I'd like to review what I said to see how those ideas panned out.

1. Expect greater government involvement in assessing the security of private sector networks. This is happening but not to the extent I expected. I predict more of this in 2009.


2. Expect greater military involvement in defending private sector networks. This also started to happen, as noted in my post Predictions Panning Out. I now think this point will happen more slowly than #1.


3. Expect increased awareness of external threats and less emphasis on insider threats. I nailed this one. In my posts More on 2008 Predictions and Insider Threat Prediction Materializing I documented several cases. Looking to a recent Jeremiah Grossman post as well, I doubt all those Web app hackers are insiders!


4. Expect greater attention paid to incident response and network forensics, and less on prevention. You can't expect people to stop thinking about prevention, but detection and especially response are huge right now. Check out the results of the SANS coolest security jobs survey. IR and forensics are at the top.


5. Expect talk of an "IPv6 gap," especially with respect to China. I missed this one. I really expected the Chinese to brag about their IPv6 network and for our politicians to push for some kind of upgrade to "catch" them. I wonder if President Obama will advocate IPv6 as part of his Internet infrastructure initiatives?

---

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

Read More

Command Information Securing, Hacking and Defending IPv6

Last week I had the good fortune to attend Securing, Hacking and Defending IPv6, a class offered by Command Information in Herndon, VA. I've experimented with IPv6, as noted most recently in my May 2007 post Freenet6 on FreeBSD. I thought I knew a decent amount about IPv6, although I recognized a class like this would be helpful.

One word: wow. IPv6 is more complicated than I expected. I only began to realize this as the two Command Information instructors, Joe Klein and TJ Evans, explained what they know about the protocol and how it is used and abused. When IPv6 becomes even moderately deployed, intruders are going to have a field day. The network teams who have been hiding in the shadows of the Web app folks are going to have to step into the light and learn quickly. You can forget any hype about IPv6 bringing "security" when deployed, at least in the short-to-mid-term. The operational realty of designing, building, and running IPv6 networks properly is going to rock everyone's world.

The instructors were the best aspect of the class. They could answer any IPv6 question anyone asked. The overall content needs to be adjusted, but the instructors were very open to feedback. The 3-day class I attended was only the second session taught thus far, so I expect continuous improvement during the next few sessions.

I haven't seen training on this subject anywhere else, by anyone I consider authoritative on the subject. Joe and TJ are helping shape the nature and use of IPv6 in Federal and other locations, and you will learn a lot in this class.

---

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

Read More

Don't Fight the Future

Digital security practitioners should fight today's battles while preparing for the future. I don't know what that future looks like, and neither does anyone else. However, I'd like to capture a few thoughts here. This is a mix of what I think will happen, plus what I would like to see happen. If I'm lucky (or good) the future will reflect these factors, for which I am planning.

A few caveats: I don't have an absolute time factor for these, and I'm not considering these my "predictions for 2009." This is not an endorsement of the Jericho Forum. I think it makes sense to plan for the environment I will describe next because it will be financially attractive, but not necessarily universally security-enhancing (or even smart).

1. Virtual Private Network (VPN) connections will disappear. For many readers this is nothing groundbreaking, but bring up the possibility with a networking team and they stare in bewilderment. Is there any reason why a remote system needs to have a simulated connection, using all available protocols, to a corporate network? Some of you might limit the type of connection to certain protocols, but why not just expose those protocols directly to the outside world and avoid the VPN altogether?


2. Intranets will disappear. This is the next step when you architect for situations where VPNs are no longer needed. What's the purpose of an Intranet if you expose all the corporate applications to the outside world? The Intranet essentially becomes a giant local ISP. That seems ripe for outsourcing. How many of you sit in a company office connected to someone else's network, perhaps using 3G, but still check your email or browse the Web? It's happening now.


3. Every device might be able to talk to every other device. This restores the dream of "end-to-end connectivity" destroyed by NAT, firewalls, and other "middleboxes." IPv6 seems to be making some ground, at least in mindshare in the Western world and definitely on the ground in the Far East. "End-to-end" is a core idea of IPv6, but scares me. Isolation is one of the few defensive measures that works in many intrusion scenarios.


4. Preferably, only authorized applications will talk to other authorized applications. This is one way to deal with the previous point. It's more complicated to implement, but will make me sleep better. I would like the ability to configure how my endpoint talks to the world, and how the world talks to it. For me, I would like to completely disable functionality, and abandon any kind of network-based filtering or blocking mechanism. It is a travesty that I have to use some aspects of Microsoft SMB for business functions, but generally allow any SMB traffic if I'm not willing to run a host-based layer 7 firewall (aka "IPS").


5. Every device must protect itself. This one really pains me, and I think it's the greatest risk. This one is going to happen no matter how much protests security people make. Again, it's already happening. Mobile devices are increasingly exposed to each other, with the owners completely at the mercy of the service provider. For me, this is an operational reality for which we must build in visibility and failure planning. We can't just assume everything will be ok, because prevention eventually fails. I'll say more on that later.


6. Devices will often have to report their own status, but preferably to a central location. Again, scary. It means that if an endpoint is exploited, the best you're likely to get from it is a last log event gasp as it reports something odd. After that a skilled intruder will make the endpoint appear as if nothing is wrong. At least if centralized logging is a core component you'll have that log as an indicator. However, past that point the endpoint cannot be trusted to report its state. This is happening more and more as mobile devices move from monitored connections (say a company network) to open ones (like wireless providers or personal broadband links).


7. As fast, high-bandwidth wireless becomes ubiquitous, smart organizations will design platforms to rely on centralized remote storage and protection of critical data. For certain types of data, we have to hope that our varied mobile devices act as little more than terminals to cloud-hosted, well-mannered information stores. The more data we keep centrally, the less persistent it needs to be on end devices, and therefore the less exposed it can be. Central data is easier to deduplicate, back up, archive, classify, inventory, e-discover, retain, destroy, and manage.

I called this post "don't fight the future" because I think these developments will transpire. The model they represent is financially more attractive to people who don't put security first, which is every decision maker I've met. This isn't necessarily a bad thing, but it does mean we security practitioners should be making plans for this new world.

---

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.

Read More

Predictions for 2008

For the last five years I've resisted the urge to write year-end predictions (thanks Anton). However, I'm seeing indications of the following, so maybe this is more about highlighting trends than taking wild guesses.

Here are my five predictions for 2008.

1. Expect greater government involvement in assessing the security of private sector networks. I base this item on what's happening in the UK following their latest data breach. The article Data watchdog seeks dawn-raid powers states the following:
   
   The Information Commissioner’s Office (ICO), which polices the security of the nation’s data, is to be given the power to raid Government departments suspected of breaching protection laws.
   
   The move, announced today by Gordon Brown, comes in response to the loss by HM Revenue & Customs (HMRC) of personal details of some 25 million Britons. The Prime Minister said the ICO would be given extra powers to carry out “spot checks” of government departments.
   
   However, it is unclear whether the new powers will extend to companies - something that Richard Thomas, the Information Commissioner, is pressing for.
   
   "Alarm bells must ring in every boardroom," Mr Thomas said today.
   
   He added: "For some time I have been pressing the government to give my Office the power to audit and inspect organisations that process people’s personal information without first having to get their consent."
   
   Mr Thomas also repeated a call for the law to be "changed to make security breaches of this magnitude a criminal offence." (emphasis added)
   
   Security raids would be an amazing event. I think it would significantly alter the way security is managed by every major company.


2. Expect greater military involvement in defending private sector networks. I base this item on reporting by the Baltimore Sun, no longer posted on their site but repeated elsewhere:
   
   In a major shift, the National Security Agency (NSA) is drawing up plans for a new domestic assignment: helping protect government and private communications networks from cyberattacks and infiltration by terrorists and hackers, according to current and former intelligence officials.
   
   From electricity grids to subways to nuclear power plants, the United States depends more than ever on Internet-based control systems that could be manipulated remotely in a terrorist attack, security specialists told The Baltimore Sun.
   
   The plan calls for the NSA to work with the Department of Homeland Security (DHS) and other federal agencies to monitor such networks to prevent unauthorized intrusion, according to those with knowledge of what is known internally as the "Cyber Initiative." Details of the project are highly classified.
   
   Director of National Intelligence Mike McConnell, a former NSA chief, is coordinating the initiative. It will be run by the DHS, which has primary responsibility for protecting domestic infrastructure, including the Internet, current and former officials said.
   
   At the outset, up to 2,000 people -- from the Department, the NSA and other agencies -- could be assigned to the initiative, said a senior intelligence official who spoke to The Baltimore Sun on condition of anonymity.
   
   I know nothing about this outside of what I just posted, and the story House panel chief demands details of cybersecurity plan discussing activities of the US House Committee on Homeland Security.


3. Expect increased awareness of external threats and less emphasis on insider threats. Maybe this is just wishful thinking, but the recent attention on botnets, malware professionalization, organized criminal cyber enterprises, and the like seems to be helping direct some attention away from inside threats. This may be premature for 2008, but I expect to see more coverage of outsiders again.


4. Expect greater attention paid to incident response and network forensics, and less on prevention. This could also be wishful thinking, but I am seeing a lot of movement in the commercial space involving effective incident response processes and tools. I've been speaking to several vendors while I build my IR and forensics lab for work and 2008 will see some very cool capabilities arrive, particularly in live response and remote forensic assessments. Several vendors will aggressively ship network forensic systems in 2008 with increased tie-ins to other existing products, like SIMs, firewalls, IPS, and the like.


5. Expect talk of an "IPv6 gap," especially with respect to China. Leading up to the start of the Olympic Games in China in 2008, I am sure we will here a lot about IPv6. I mentioned this last year. Talk of an "IPv6 gap" will build upon a perceived "space gap" as China pursues its vision to put men on the moon by 2020. You will hear people say we need IPv6 because it is "inherently secure" or something similar. The China hacking stories of a few months ago embedded themselves in the IT consciousness, and that will be a continuing theme. I'm not sure if any of this will result in IPv6 being effectively deployed in 2008, 2009, or even 2010 in the US.

A year from now I'll see how these trends played out in 2008 and report back.

Read More

Feds Plan to Reduce, Then Monitor

According to OMB directs agencies to close off most Internet links, by June 2008 the Federal government plans to reduce the number of Internet connections it maintains, and then monitor them more closely:

The Office of Management and Budget's Trusted Internet Connections (TIC) initiative likely is to be the last publicized program in the Bush administration's stepped-up focus on cybersecurity, some experts say. More importantly, the new initiative requires agencies to implement real-time gateway monitoring, which has been a deficit in federal network protection.

The TIC initiative mandates that officials develop plans for limiting the number of Internet connections into their departments and agencies. OMB officials want to reduce the number of gateways from the more than 1,000 to about 50, said Karen Evans, OMB's administrator for e-government and information technology. (emphasis added)

This sounds promising. The story continues:

The initiative also asks chief information officers to develop a plan of action and milestones for participating in the Homeland Security Department's U.S. Computer Emergency Readiness Team's Einstein initiative. The program offers agencies real-time gateway monitoring capabilities and helps them react more quickly to security incidents. About 13 agencies voluntarily participate in the Einstein program.

"The reduction of access points to trusted Internet connections will improve our situational awareness and allow us to address potential threats in an expedited and efficient manner," Evans said. "While we optimize and improve our security, it is also our goal to minimize overall operating costs for services through economies of scale."

Reduction of gateways + enhanced monitoring = better, stronger, faster -- and cheaper.

The story With Internet gateways, less is more adds:

A June deadline for agencies to consolidate their Internet connections coincides with another OMB deadline. June is also when agencies must upgrade their backbone networks to run the next-generation Internet protocol, IPv6...

“The [TIC] initiative is saying, ‘We have to know what we own in order to protect it,’ ” Evans said. “We also must know we are managing risk at an acceptable level.”

Evans said the federal government has more than 1,000 gateways to the public Internet.

The target number is 50, but that is not an absolute number, she said. “We know 1,000 or more is not the way to do it. At a minimum, 50 is two per department.”

Fifty gateways is a reasonable number, Evans said, adding that the Defense Department has reduced its Internet gateway count to 18. The Homeland Security Department expects to have only two Internet gateways after it completes its OneNet initiative.

“The 50 or so points of presence [would] become the perimeter of the federal government,” Evans said. (emphasis added)

Kudos to Karen Evans. I am hopeful that someone who realizes FISMA Is a Joke has begun steering the Federal government away from worthless documentation and towards real network security operations.

Read More

Snort Report 10 Posted

My 10th Snort Report on Snort 2.8.0 new features: IPv6 and port lists is now available online. From the start of the article:

Snort 2.8.0 was recently published with several features long desired by Snort veterans. These new features include IPv6, port lists, packet performance monitoring and control of actions enabled by preprocessor or decoder events. This edition of the Snort Report provides details on IPv6 and port lists that VARs and systems integrators can use to optimize their use of the open source intrusion detection system.

In the next Snort Report I plan to look at other features in Snort 2.8.

Read More

Black Hat USA 2007 Round-Up Part 2

I'm waiting in another airport, so it's time to summarize my second day at Black Hat USA 2007. (The first day is Black Hat USA 2007 Round-Up Part 1.)

• I started the day in Bruce Schneier's keynote. Bruce's talk was interesting but plauged by audio problems (not his fault). Bruce reiterated his ideas of the "security consumer" who asks "is it worth it?" when deciding whether or not to wear a bullet-proof vest when walking out his front door. Bruce seems to have changed his mind about the evils of "security theater," because he said "security is a feeling and a reality," and sometimes security theater is needed to right imbalances between the feeling and the reality. This imbalance can come about when citizens watch television, which impairs their availability heuristic by making rare and catastrophic events seem common and personal.
  
  Bruce focused on psychology, stating people, on average, are risk-seeking when facing losses but risk-adverse when facing gains. In other words, they are more likely to take a chance to avoid a loss than they are to take a chance to acquire a greater gain. Bruce published a paper describing his views at The Psychology of Security. Pay attention to the five aspects of the security trade-off.


• Jim Hoaglund from Symantec presented my first technical talk of the day. He described the new Windows Vista TCP/IP stack and emphasized the role of tunnels for IPv6. It's probably best just to read the papers behind the talk, namely Windows Vista Network Attack Surface Analysis (.pdf), The Teredo Protocol: Tunneling Past Network Security and Other Security Implications (.pdf), draft-ietf-v6ops-teredo-security-concerns , Microsoft's Objectives for IPv6, and Jim's blog post. Jim said "stacks are complex entities that take years to mature." Jim discussed stack vulnerabilities found in beta versions of Vista. I was very interested in hearing about the new fragmentation reassembly standard used in Vista, which differs from previous versions. (Hello trouble for IDS/IPS/etc, good news for stack fingerprinters.)
  
  Jim spent a lot of time talking about Teredo, documented in RFC 4380. Teredo is designed as an IPv6 transition mechanism "of last resort." I've documented my tests with Miredo, a Unix implementation. What struck me about Jim's comments were his revelation that Teredo was designed without visibility or control. This directly contradicts my idea of Security Application Instrumentation. Essentially, unless an inspection product analyzes every UDP packet, it is not possible to control Teredo. It is possible to "starve" Teredo traffic by blocking outbound to Teredo servers on UDP port 3544, but that is not a complete solution. Also, Jim claimed that in some cases Teredo "may be preferred even over native IPv4." He recommended that Teredo not be deployed on "managed networks," which is just about anywhere that matters.


• Nick Harbour of MANDIANT discussed basic, intermediate, and advanced ways to hide malware. He talked about hook injection to hide malware in existing processes, library injection (the most common attack) via CreateProcessThread() to hide in libraries, and direct injection, where code is inserted directly into processes. He mentioned registry tricks like Image File Execution Options to launch malware as a "debugger" that calls a legitimate process. Nick said he would release Malvm and his Executable Toolkit on nickharbour.com soon.


• I watched almost all of Gadi Evron's talk about the Estonia "information war," but I felt like he took over an hour when probably 20 minutes would have sufficed.


• One of the best talks on the second day was delivered by Tom Ptacek and Eric Monti who described vulnerabilities and exposures in extrusion detection and related products. Because they could not name the products they had tested, they profiled a "fake" product called PlugBoy. Basically, these products are nearly worthless, except for the value they deliver in demonstrations to executives and the launch pad they provide for intruders. They focused on host-based systems instead of those that sit inline or offline.
  
  Tom and Eric said "evasion is a given." For example, you can trivially bypass their filters using any number of techniques at layers 3, 4, or higher. It could take as simple a technique as changed text in a word document to bold or adding a space between every character of the document. The problem with these products is that they need to do some sort of file format decoding in order to have a prayer of making sense of a document's contents. Unfortunately, by introducing file format dissection decoding, they are incredibly vulnerable (think of Wireshark's security history with protocol dissectors and recent file format fuzzing exploits.)
  
  Here's another problem with extrusion products on the host: they tend to communicate what they find in the clear to their management platforms. (Zlib compression doesn't count as "encryption.") So, think of this: you have a product sitting between a remote SSL-enabled site, inspecting and grabbing sensitive content, then retransmitting a subset of that content in the clear to the management server. Who designed this train wreck? Furthermore, these products tend to have application, service, and kernel components. This means you have a piece of code that by design has access to everything you consider sensitive sitting in the kernel.
  
  Tom and Eric said this code is rife with vulnerabilities. They described how sending a malformed AIM packet would root the agent and therefore the kernel and therefore the box. Returning to agent to manager communications, this channel is unauthenticated. This means anyone could spoof traffic or send traffic to the management console. That content tends to be rendered in a Web application viewable by the administrator. Now you can send traffic to the management console (think XSS or other file rendering attacks) and own it.
  
  In case you didn't put all these steps together, here they are: 1) Web browser with ED agent visits malicious Web site; 2) Web site attacks and owns ED agent; 3) Owned ED agent attacks ED manager; 4) Owned ED managed attacks and owns all ED agents on all hosts; Game Over.
  
  In brief, the host-based ED products Eric and Tom reviewed are "latent botnets" in addition to all their potential violations of PCI and other regulations protecting data.
  
  I managed to briefly talk with Tom and Eric prior to their presentation, which was cool. They reminded me I need to try their tools, like Black Bag, which is "Netcat on steroids."


• I finished the day watching my friends Keith Jones and Rohyt Belani present three case studies on insider attacks. Keith talked about the Duronio case. Rohyt described a wireless exploit at a retail company and a law firm document management system abused by an administrator.

I had the following thoughts after watching these talks.

• We cannot eliminate the probability of compromise of the general Internet population. This is another way to say "prevention eventually fails." We can reduce the probability of compromise by applying costing countermeasures or drastically limiting exposure. You could think of this situation as the difference in the lives between the President and his Secret Service vs Joe Sixpack. The President can try to venture outside if protected by agents, but Joe is a sitting duck. His best bet is to stay home if he feels threatened. This deserves more thought, so I will probably address it later. A digital equivalent is hiring a team to build your own special Web browser or using a text-based Web browser and living a more monastic life.


• Modern countermeasures applied to reduce vulnerability and/or exposure in many cases increase both vulnerability and exposure. This is certainly the case with so many agents (see Matasano is Right About Agents.)


• Developers continue to ignore history by reintroducing old vulnerabilities and exposures. Tom and Eric talked about how so many products ship old vulnerable versions of Gzip libraries, as one example.


• As assets are increasingly managed, it becomes easier for intruders to exploit vulnerabilities in them and assume management of those assets. Eric and Tom noted that monolithic agents are being placed on assets of all types for purposes of managing them (if operating system homogeneity weren't enough of a problem). These agents are not coded to the standards found in the OS (props to Microsoft for getting its act together in recent years). The problem with these agents is that they open a brittle window for takeover by malicious parties.


• Firewalls are channel restriction products, not compromise prevention products. As the number of channels proliferates, the firewall is increasingly irrelevant. Inspection products (which include detection and filtering devices) are caught in a quandry. Application-unaware (think content matching alone, maybe via regex) inspection and filtering systems are less able to understand content and counter attacks. Application and protocol awareness would seem to be the answer, but those dissectors are directly targted by intruders and are heavily vulnerable to protocol and file format attacks. (Previously the content inspectors were mainly vulnerable if their content-matching system [think regex library] had a flaw.) No one wins.

I'm really rushed here so I may revisit this post to fix a few thoughts. I will post my overall defensive recommendations in a future post.

Read More

Black Hat USA 2007 Round-Up Part 1

I'm waiting in the airport for my flight home after spending 6 days in Las Vegas at Black Hat USA 2007. I last attended in 2003. Put simply I was blown away by the quality of the majority of the talks I saw. I'll summarize the talks and my response.

I spent four days teaching TCP/IP Weapons School in two two-day sessions, to a total of 116 students. I think both classes were well-received. The students were some of the sharper ones I've had in class, which is what I hoped for and expected. The first day of teaching I was lucky enough to share lunch with some of my students and Joanna Rutkowska. We discussed covert channels related difficult detection problems.

The following are thoughts on the first day of briefings. I spent the majority of the day in the application security track.

• I sat in Richard Clarke's keynote. He emphasized how what he called "visualization exercises" help decision makers envisage digital risk. I described this phenomenon last year in Analog Security Is Threat-Centric and Disaster Stories Help Envisage Risks. Mr. Clarke explained how human-machine interfaces are the next security frontier and how DoD's Net-Centric Warfare (see Thoughts from IATF Meeting depends on the vast number of IP addresses available in IPv6. Unfortunately Mr. Clarke has fallen for the myth that IPv6 will bring greater security and "prioritization," which means we must have it. I debunked these misconceptions held by many executives in Chinese IPv6 in CIO. It struck me that Mr. Clarke mentioned that executives view spending on security as a "cost center" but spending on breach recovery is a "loss center." I wonder where we've heard that before?


• David Byrne delivered an exceptional talk on the security consequences of anti-DNS pinning. The purpose of his attack is to use Web clients as a conduit for attacking intranet hosts. He demo'd conducting a remote Nessus scan and Metasploit attack of intranet hosts via a "tunnel" of HTTP POSTs and replies passed through a Web browser. David's talk showed that DNS resolutions which result in an Internet hostname resolving first to an Internet host and next to an intranet host can be used as a detection mechanism. A Web server vulnerable to XSS is required, and the presence of Java or other rich content vehicles on the host only exacerbates the problem by providing additional attack vectors.


• Jeremiah Grossman and Robert Hansen continued to pile on Web application attacks. They showed a variety of ways to exploit Web clients and internet hosts without Javascript. Robert (aka Rsnake of ha.ckers.org said that everyone who links to his site from the intranet Web pages and uses his files for penetration tests leaks data on their company to him.


• I only saw the last half of Brad Hill's talk because I had lunch with several ex-Foundstoners, but the part I saw was impressive. Brad explained how to exploit XML digital signatures, such as running arbitrary executables (like cmd.exe) from within a signature!


• Bryan Sullivan and Billy Hoffman rocked, showing how their demo site www.hackervacations.com exemplified the many vulnerabilities in Ajax Web sites. They really made me understand the problem with Ajax: most, if not all in some cases, of Ajax applications are executing on the client. Previously, attacking Web applications centered on providing malicious input to influence the execution of the Web app. Now, attacking Ajax Web applications means malicious clients manipulate every aspect of the program, including variables, order of execution, and control of the server. They showed how to "DoS a plane" by reserving all seats on a flight booking system, and keeping all seats filled by sending an HTTP message every 30 seconds. They showed how to buy a plane seat for $1, or buy all seats for nothing. They accessed hidden administrative functions by directly talking to the remote Web service and dumping the entire database (with zero knowledge of the remote database) with two commands. This emphasized that testing inputs through the Web applications is completely insufficient; all the Web services must now be similarly assessed.


• Ben Feinstein and Daniel Peck showed a way to crawl and de-obfuscate malicious Javascript. They mentioned an integrity attack whereby malicious eBay sellers used XSS to provide fake positive seller ratings to unsuspecting buyers. The showed how their Caffeine Monkey tool profiles Javascript, providing a fingerprint of current malicious Javascript compared to nonmalicious Javascript. For example, string and object instantiations are very common in malicious Javascript but rare in nonmalicious Javascript. This is essentially the same detection problem we've been wrestling with for years, and it shows that intruders could begin to write their Javascript to resemble normal versions.


• I ended the day in Hacker Court, where the "Crimson Knight" was tried for cheating the "Masters of Mayhem" online game. As usual Hacker Court was great, especially because Jennifer Granick moved from her traditional role as defense counsel to the new role of prosecutor. She lost her case, but I spoke with her briefly and learned the experience gave her a chance to think like the other side in front of an audience in a simulated trial.

My overall impression from the first day of briefings can be summarized in this manner.

• Existing defenses are absolutely ineffective against current attacks. I am struggling to describe the importance of this insight. It does not matter if you are fully patched, "properly configured," not running Javascript, or adopting any number of other current defensive stratgies if you use a Web browser that renders modern rich content. Almost none of the techniques described in the Black Hat talks relies upon exploiting vulnerable software. Almost all of them abuse inherent functionality for malicious reasons.


• Detecting current attacks in "real time" is increasingly difficult, if not impossible. Even if you assume attacks are not obscured by encryption, recognizing and understanding the variety of Web-based attacks shown at Black Hat is almost a lost cause. There is basically no way for defenders to address the expanse of the attack surface exposed by "rich Internet applications" and frameworks. I realized that the "rich" in "RIA" refers to the money intruders will make by exploiting Web clients.


• The average Web developer and security professional will never be able to counter these attacks. Intruders are so far ahead of the defenders with respect to tools and techniques that it is simply not possible to prevent the attacks I saw at Black Hat. This statement will probably offend many people but it's time to face the truth. There is no way to get "ahead of the threat" here.

I realize I've painted a very bleak picture. In my next post (time to board the plane) I will summarize day 2 of the Black Hat Briefings. In the post after that I will provide some defensive strategies and concluding thoughts.

Read More

RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls

All you fans of mindlessly blocking ICMP traffic are going to be in trouble if you try that strategy with IPv6. Luckily this month RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls was just published. This Informational RFC provides concrete guidance using these categories:

• Traffic That Must Not Be Dropped


• Traffic That Normally Should Not Be Dropped


• Traffic That Will Be Dropped Anyway -- No Special Attention Needed


• Traffic for Which a Policy Should Be Defined


• Traffic That Should Be Dropped Unless a Good Case Can Be Made

This is a nice reference for those who wish to implement some degree of control over ICMPv6, which is an integral part of IPv6 and not something one can blindly block.

Read More

USENIX Santa Clara Update

Last month USENIX posted details on USENIX Annual 2007 in Santa Clara, CA, 17-22 June 2007. I'll be teaching Network Security Monitoring with Open Source Tools and TCP/IP Weapons School (layers 2-3) day one and day two.

I just finished uploading my slides for the three days of training. It seemed everyone liked the NSM course, but I received feedback concerning the coverage of layer 1 in TWS. Therefore, I axed 80% of the layer 1 material (probably 50-60 slides) and created a lot more new material. Specifically, I added sections on IP protocol scanning, Cisco Discovery Protocol use and abuse, and a big section on ICMPv6 Neighbor Discovery and IPv6. These last sections are an introduction really, but it's cool to see the traffic and walk through what it all means.

I will most likely teach layers 4-7 for USENIX at USENIX Security in Boston, MA, 6-10 August 2007. I plan to update the material to cover Metasploit 3 and some of its evasion methods. I'll also cover the traffic begind the Best April Fool's Joke this year.

Register before 1 June to get the best deal.

If you can't make it to Santa Clara for TCP/IP Weapons School (Layers 2-3), I'll be teaching the same material at Techno Security 2007 a few weeks earlier in Myrtle Beach, SC. That class is filling fast though.

I hope to see you there or at another training event this year!

Read More

Freenet6 on FreeBSD

Last year I wrote IPv6 Only FreeBSD Scenario. I described using the net/tspc2 port and registering with Hexago/Freenet6. On Friday the net/tspc2 port will be deprecated. I spoke with the port maintainer and he said that he deprecated the port because the source code was no longer available at hexago.com. I looked around and found that I could download gw6c4_2_2src.tar.gz from go6.net, an IPv6 portal sponsored by Hexago. Furthermore, I found the FreeBSD port net/freenet6 -- which appears to be the same thing as the net/tspc2 port. In fact, the net/freenet6 maintainer just updated the port to point to the go6.net download location for gw6c4_2_2src.tar.gz.

I decided to remove the net/tspc2 port from my gateway and replace it with net/freenet6.

mwmicro:/usr/local/tbz# pkg_add -v freenet6-2.1.1_6.tbz 
Requested space: 154796 bytes, free space: 881494016 bytes in
 /var/tmp/instmp.qCS7Fo
extract: Package name is freenet6-2.1.1_6
extract: CWD to /usr/local
extract: /usr/local/man/man5/tspc.conf.5.gz
extract: /usr/local/man/man8/tspc.8.gz
extract: /usr/local/bin/tspc
extract: /usr/local/share/examples/freenet6/tspc.conf.sample
extract: /usr/local/bin/tspc-freebsd.sh
extract: /usr/local/bin/checktunnel.sh
extract: /usr/local/etc/rc.d/freenet6.sh
extract: CWD to .
Running mtree for freenet6-2.1.1_6..
mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null
Attempting to record package into /var/db/pkg/freenet6-2.1.1_6..
Package freenet6-2.1.1_6 registered in /var/db/pkg/freenet6-2.1.1_6

Now that the package is installed, please finish it with the following steps:

- Copy /usr/local/share/examples/freenet6/tspc.conf.sample to /usr/local/etc/tspc.conf
- Check the values of /usr/local/etc/tspc.conf. If you have registered at
  the website, fill in your userid and password there.
- Run /usr/local/etc/rc.d/freenet6.sh to start the tunnel.
- Try to ping a IPv6 host, for example: ping6 www.jp.freebsd.org

Please note that tsps[12].freenet6.net are not in service anymore,
please use broker.freenet6.net instead.

Net/freenet6 now supports rc.subr.
Please add 'freenet6_enable="YES"' to your /etc/rc.conf to make it
start autoamtically at startup.

I made the changes as noted below to the tspc.conf file:

mwmicro:/usr/local/etc# diff -u /usr/local/share/examples/freenet6/
 tspc.conf.sample /usr/local/etc/tspc.conf

--- /usr/local/share/examples/freenet6/tspc.conf.sample Sat Sep  2 16:11:17 2006
+++ /usr/local/etc/tspc.conf    Tue May  8 13:38:39 2007
@@ -54,7 +54,8 @@
 #  your_userid means the userid you registered to the broker. The userid
 #   must be using only legal dns label names (eg: [a-zA-Z0-9-] ) since
 #   the userid is used inside your user hostname.
-userid=anonymous
+#userid=anonymous
+userid=taosecurity
 
 #
 # password:
@@ -62,7 +63,8 @@
 #  leave empty if userid=anonymous
 #  your_password means the password you have been assigned with your
 #   userid
-passwd=
+#passwd=
+passwd=OBSCURED
 
 #
 # Name of the script:
@@ -106,7 +108,8 @@
 #
 # The default value is the Freenet6 tunnel broker for 
 # anonymous accounts (anon.freenet6.net)
-server=anon.freenet6.net
+#server=anon.freenet6.net
+server=broker.freenet6.net
 
 #
 #
@@ -175,20 +178,20 @@
 #
 # host_type=host|router
 #  default = host.
-#host_type=router
+host_type=router
 
 #
 # prefixlen specifies the required prefix length for the TSP client 
 #  network. Valid values are 64 or 48. 64 is for one link. 48 is for
 #  a whole enterprise network (65K links).
-#prefixlen=48
+prefixlen=48
 
 #
 # if_prefix is the name of the OS interface that will be configured
 #  with the first /64 of the received prefix from the broker and the
 #  router advertisement daemon is started to advertise that prefix
 #  on the if_prefix interface.
-#if_prefix=
+if_prefix=sf3
 
 #
 # For reverse DNS delegation of the prefix, define the following:

Next I added this

freenet6_enable="YES"

to /etc/rc.conf.

Finally I started the client.

mwmicro:/root# /usr/local/etc/rc.d/freenet6.sh start
Starting freenet6.
tspc - Tunnel Setup Protocol Client v2.1.1
Initializing (use -h for help)

Connecting to server with reliable udp
Got tunnel parameters from server, setting up local tunnel
Going daemon, check tspc.log for tunnel creation status

The client creates gif0 for use in tunneling.

mwmicro:/root# ifconfig gif0
gif0: flags=8051 mtu 1280
        tunnel inet 69.143.202.28 --> 64.86.88.116
        inet6 2001:5c0:8fff:fffe::5889 --> 2001:5c0:8fff:fffe::5888
         prefixlen 128 
        inet6 fe80::204:e2ff:fe29:4c3c%gif0 prefixlen 64 scopeid 0x9 

mwmicro:/root# netstat -nr -f inet6 | grep gif
default                           2001:5c0:8fff:fffe::5888      UGS      gif0
2001:5c0:8fff:fffe::5888          link#9                        UHL      gif0
fe80::%gif0/64                    link#9                        UC       gif0
fe80::204:e2ff:fe29:4c3c%gif0     link#9                        UHL       lo0
ff01:9::/32                       link#9                        UC       gif0
ff02::%gif0/32                    link#9                        UC       gif0

With gif0 set up to tunnel IPv6 in IPv4, I was able to ping6 www.kame.net.

mwmicro:/root# ping6 -c 1 www.kame.net
PING6(56=40+8+8 bytes) 2001:5c0:8fff:fffe::5889 --> 2001:200:0:8002:203:47ff:fea5:3085
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=0 hlim=49
 time=228.016 ms

--- www.kame.net ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 228.016/228.016/228.016/0.000 ms

I was also able to ping6 www.kame.net from an IPv6-only host behind the gateway.

How about this for coolness -- this version of Freenet6 also supports working on an IPv4 client behind NAT. To test this I installed net/freenet6 on VMware, copied /usr/local/share/examples/freenet6/tspc.conf.sample to /usr/local/etc/tspc.conf, added the "enable" statement to /etc/rc.conf, and started freenet6.sh. The VM now had a tun1 interface:

tun1: flags=8051 mtu 1280
        inet6 2001:5c0:8fff:ffff::133 --> 2001:5c0:8fff:ffff::132
         prefixlen 128 
        Opened by PID 580

And this routing table:

neely-bsd# netstat -nr -f inet6 | grep tun1
default                           2001:5c0:8fff:ffff::132       UGS      tun1
2001:5c0:8fff:ffff::132           link#5                        UHL      tun1
ff01:5::/32                       link#5                        UC       tun1
ff02::%tun1/32                    link#5                        UC       tun1

I was able to ping6 www.kame.net.

neely-bsd# ping6 -c 2 www.kame.net
PING6(56=40+8+8 bytes) 2001:5c0:8fff:ffff::133 -->
 2001:200:0:8002:203:47ff:fea5:3085
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=0 hlim=50
 time=295.101 ms
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=1 hlim=50
 time=292.508 ms

In fact, from the VM I could ping6 the gateway's public address:

neely-bsd# ping6 -c 2 2001:5c0:8fff:fffe::5889
PING6(56=40+8+8 bytes) 2001:5c0:8fff:ffff::133 -->
 2001:5c0:8fff:fffe::5889
16 bytes from 2001:5c0:8fff:fffe::5889, icmp_seq=0 hlim=63
 time=127.114 ms
16 bytes from 2001:5c0:8fff:fffe::5889, icmp_seq=1 hlim=63
 time=132.455 m

The difference between these implementations is the encapsulation. For the gateway, Freenet6 uses IP protocol 41, like this:

richard@neely:~$ tcpdump -n -r ipv6.lpc ip proto 41

reading from file ipv6.lpc, link-type EN10MB (Ethernet)
14:14:01.775391 IP 69.143.202.28 > 64.86.88.116: IP6 2001:5c0:8fff:fffe::5889
 > 2001:5c0:8fff:fffe::5888: ICMP6, neighbor solicitation, who has 
 2001:5c0:8fff:fffe::5888, length 24

14:14:01.838210 IP 64.86.88.116 > 69.143.202.28: IP6 2001:5c0:8fff:fffe::5888
 >  2001:5c0:8fff:fffe::5889: ICMP6, neighbor advertisement, tgt is 
 2001:5c0:8fff:fffe::5888, length 24

14:14:17.083741 IP 69.143.202.28 > 64.86.88.116: IP6 2001:5c0:8fff:fffe::5889
 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 0, length 16

14:14:17.317006 IP 64.86.88.116 > 69.143.202.28: IP6 
 2001:200:0:8002:203:47ff:fea5:3085 > 2001:5c0:8fff:fffe::5889:
 ICMP6, echo reply, seq 0, length 16

For the client behind NAT, Freenet6 uses IPv6 in UDP port 3653. In this example I send two ICMPv6 echo packets to www.kame.net. Tshark decodes it like this:

richard@neely:~$ tshark -n -r udp.lpc udp.port==3653

  1   0.000000  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
  Destination port: 3653
  2   0.000017  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
  Destination port: 3653
  3   0.051616 64.86.88.117 -> 192.168.2.9  UDP Source port: 3653 
 Destination port: 49454
  7   0.080622  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
  8   0.080641  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
  9   0.314504 64.86.88.117 -> 192.168.2.9  UDP Source port: 3653 
 Destination port: 49454
 10   0.947704  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
 11   0.947737  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
 12   1.175285 64.86.88.117 -> 192.168.2.9  UDP Source port: 3653 
 Destination port: 49454

If I tell Tshark to decode the protocol as Teredo (which implies IPv6 in UDP) I see this.

richard@neely:~$ tshark -n -r udp.lpc udp.port==3653 -d
 udp.port==3653,teredo

  1   0.000000 2001:5c0:8fff:ffff::133 -> 2001:5c0:8fff:ffff::132
 ICMPv6 Echo request
  2   0.000017 2001:5c0:8fff:ffff::133 -> 2001:5c0:8fff:ffff::132
 ICMPv6 Echo request
  3   0.051616 2001:5c0:8fff:ffff::132 -> 2001:5c0:8fff:ffff::133
 ICMPv6 Echo reply
  7   0.080622 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
  8   0.080641 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
  9   0.314504 2001:200:0:8002:203:47ff:fea5:3085 ->
 2001:5c0:8fff:ffff::133 ICMPv6 Echo reply
 10   0.947704 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
 11   0.947737 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
 12   1.175285 2001:200:0:8002:203:47ff:fea5:3085 ->
 2001:5c0:8fff:ffff::133 ICMPv6 Echo reply

What's interesting about that is the ICMPv6 used earlier in the trace to 2001:5c0:8fff:ffff::132, the other side of the tun1 tunnel, to prepare to carry the ICMPv6 traffic to 2001:200:0:8002:203:47ff:fea5:3085 (www.kame.net), e.g.:

$ host 2001:200:0:8002:203:47ff:fea5:3085
5.8.0.3.5.a.e.f.f.f.7.4.3.0.2.0.2.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa
 domain name pointer orange.kame.net.

Look at that result. IPv6 is a pain.

Read More

Snort 3.0 Alpha and IPv6

For the past few days I've been playing with alpha code for Snort 3.0, recently announced. One of the most interesting aspects of Snort 3.0 is the fact that operation is controlled by a Lua interpreter. It's a little like logging into a Cisco router and it's going to change the way everyone uses and interacts with Snort.

I tested snort-03.0.0.a1.4 on a FreeBSD box 6.x box with the lua-5.1.1_2 package installed. I compiled it:

$ ./configure --with-lua-includes=/usr/local/include/lua51/ 
 --with-lua-libraries=/usr/local/lib/lua51/
 --prefix=/usr/local/snort-03.0.0.a1.4/
$ make
$ make install

The alpha code does not have a detection engine yet. It's like the original Snort -- it's only a packet decoder. I thought you might like to see what it looks like when Snort 3.0 decodes IPv6 packets. I'm using this IPv6-only FreeBSD scenario.

When you start Snort, it activates but does nothing until you tell it.

cel433:/usr/local/snort-03.0.0.a1.4/bin# ./snort 
[*] DAQ Modules Loaded...
[*] Loading decoder modules
[+] Loaded ethernet
[+] Loaded null
[+] Loaded arp
[+] Loaded ip
[+] Loaded tcp
[+] Loaded udp
[+] Loaded icmp
[+] Loaded icmp6
[+] Loaded gre
[+] Loaded mpls
[+] Loaded 8021q
[+] Loaded ipv6
[+] Loaded ppp
[+] Loaded pppoe
[+] Loaded raw
[*] Decoder initialized...
[*] Flow manager initialized...
[*] Data source subsystem loaded
[*] Engine manager initialized
[*] Loading command interface
[!] Loading sfips command metatable
[!] Loading data source command metatable
[!] Loading engine command metatable
   ,,_     -*> Snort! <*-
  o"  )~   Version 03.0.0.a1.4 (Build 7) [PRE-ALPHA]
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 2006 Sourcefire Inc.

You tell Snort to begin sniffing using these commands.

> dofile("/usr/local/src/snort-03.0.0.a1.4/etc/snort.lua")
snort> fsniff("fxp0")
Creating new data source
Engine "e2" created
Linking engine "e2" to data source "src2"
init_pcap: Initializing network interface fxp0
init_pcap: netmask lookup for device fxp0: fxp0: no IPv4 address assigned
Device type is Ethernet on interface fxp0
Flow manager "a5a891c4-e448-11db-b5e1-00045a7822bf" created with 16384 flow capacity
[*] Data Source Config:
        Name: src2
        Type: pcap
        Interface: fxp0
        Filename:  
        Snaplen: 1514
        Flags: 0x00000002
        Display: ethernet (4)
        Filter command:  
        DAQ: 0x807e400
        User Context: 0x808f3c0
        User Data: 0x0
        Max flows: 16384
        Max idle: 10
        Memcap: 10000000
[*] Flow Manager Config:
        Max flows: 16384
         Max idle: 10
           Memcap: 10000000
[*] DAQ config:
   Interface: fxp0
   Snaplen: 1514
   Datalink: 1
   Count: 0
   Packet Count: 0
   Promisc flag: 1
   File flag: 0
   pcap ptr: 0x80ac400
   analysis context ptr: 0x80a9600
[*] Spawning engine thread!

I generate ICMPv6 traffic that Snort can see.

mwmicro:/home/string$ ping6 -c 1 p200
PING6(56=40+8+8 bytes) fe80::200:d1ff:feed:8c74%sf3 --> fe80::204:5aff:fe79:43a7%sf3
16 bytes from fe80::204:5aff:fe79:43a7%sf3, icmp_seq=0 hlim=64 time=1.131 ms

--- p200 ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.131/1.131/1.131/0.000 ms

Here is what Snort reports.

snort> [*] Packet on interface fxp0
[*] Packet Info
    Serial:                 1
    Packet Time:            04/06-14:11:13.098377
    Packet Bytes:           70
    Captured Bytes:         70
    Layers:                 4
[*] Ethernet (14 bytes)
    Source MAC Address:     00:00:D1:ED:8C:74
    Dest MAC Address:       00:04:5A:79:43:A7
    Encapsulated Protocol:  IPv6
[*] Internet Protocol version 6 (40 bytes)
    Version:                6
    Class:                  0 (0x0)
    Flow Tag:               96 (0x60)
    Packet Length:          16
    Next Header:            ipv6-icmp
    Hop Limit:              64
    Src Addr:               fe80::200:d1ff:feed:8c74
    Dst Addr:               fe80::204:5aff:fe79:43a7
[*] Internet Control Message Protocol Version 6
    Type:       128 (Echo Request)
    Code:       0 
    Id:         11124
    Seq:        0
    Checksum:   22822 (INVALID 0000)
[*] Payload (8 bytes)
0x0000: 46 16 55 0E 00 0A 64 63                          F.U...dc         

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[*] Packet on interface fxp0
[*] Packet Info
    Serial:                 2
    Packet Time:            04/06-14:11:13.098802
    Packet Bytes:           70
    Captured Bytes:         70
    Layers:                 4
[*] Ethernet (14 bytes)
    Source MAC Address:     00:04:5A:79:43:A7
    Dest MAC Address:       00:00:D1:ED:8C:74
    Encapsulated Protocol:  IPv6
[*] Internet Protocol version 6 (40 bytes)
    Version:                6
    Class:                  0 (0x0)
    Flow Tag:               96 (0x60)
    Packet Length:          16
    Next Header:            ipv6-icmp
    Hop Limit:              64
    Src Addr:               fe80::204:5aff:fe79:43a7
    Dst Addr:               fe80::200:d1ff:feed:8c74
[*] Internet Control Message Protocol Version 6
    Type:       129 (Echo Reply)
    Code:       0 
    Id:         11124
    Seq:        0
    Checksum:   22566 (INVALID 0000)
[*] Payload (8 bytes)
0x0000: 46 16 55 0E 00 0A 64 63                          F.U...dc         

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[*] Packet on interface fxp0
[*] Packet Info
    Serial:                 3
    Packet Time:            04/06-14:11:18.096779
    Packet Bytes:           86
    Captured Bytes:         86
    Layers:                 4
[*] Ethernet (14 bytes)
    Source MAC Address:     00:00:D1:ED:8C:74
    Dest MAC Address:       00:04:5A:79:43:A7
    Encapsulated Protocol:  IPv6
[*] Internet Protocol version 6 (40 bytes)
    Version:                6
    Class:                  0 (0x0)
    Flow Tag:               96 (0x60)
    Packet Length:          32
    Next Header:            ipv6-icmp
    Hop Limit:              255
    Src Addr:               fe80::200:d1ff:feed:8c74
    Dst Addr:               fe80::204:5aff:fe79:43a7
[*] Internet Control Message Protocol Version 6
    Type:       135 (ND Neighbor Solicitation)
    Code:       0 
    Checksum:   32787 (INVALID 0000)
[*] Payload (8 bytes)
0x0000: 01 01 00 00 D1 ED 8C 74                          .......t         

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[*] Packet on interface fxp0
[*] Packet Info
    Serial:                 4
    Packet Time:            04/06-14:11:18.097203
    Packet Bytes:           78
    Captured Bytes:         78
    Layers:                 4
[*] Ethernet (14 bytes)
    Source MAC Address:     00:04:5A:79:43:A7
    Dest MAC Address:       00:00:D1:ED:8C:74
    Encapsulated Protocol:  IPv6
[*] Internet Protocol version 6 (40 bytes)
    Version:                6
    Class:                  0 (0x0)
    Flow Tag:               96 (0x60)
    Packet Length:          24
    Next Header:            ipv6-icmp
    Hop Limit:              255
    Src Addr:               fe80::204:5aff:fe79:43a7
    Dst Addr:               fe80::200:d1ff:feed:8c74
[*] Internet Control Message Protocol Version 6
    Type:       136 (ND Neighbor Advertisement)
    Code:       0 
    Checksum:   40574 (INVALID 0000)
[*] Payload (8 bytes)
0x0000: 02 04 5A FF FE 79 43 A7                          ..Z..yC.         

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[*] Packet on interface fxp0
[*] Packet Info
    Serial:                 5
    Packet Time:            04/06-14:11:18.097456
    Packet Bytes:           86
    Captured Bytes:         86
    Layers:                 4
[*] Ethernet (14 bytes)
    Source MAC Address:     00:04:5A:79:43:A7
    Dest MAC Address:       00:00:D1:ED:8C:74
    Encapsulated Protocol:  IPv6
[*] Internet Protocol version 6 (40 bytes)
    Version:                6
    Class:                  0 (0x0)
    Flow Tag:               96 (0x60)
    Packet Length:          32
    Next Header:            ipv6-icmp
    Hop Limit:              255
    Src Addr:               fe80::204:5aff:fe79:43a7
    Dst Addr:               fe80::200:d1ff:feed:8c74
[*] Internet Control Message Protocol Version 6
    Type:       135 (ND Neighbor Solicitation)
    Code:       0 
    Checksum:   32787 (INVALID 0000)
[*] Payload (8 bytes)
0x0000: 01 01 00 04 5A 79 43 A7                          ....ZyC.         

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
[*] Packet on interface fxp0
[*] Packet Info
    Serial:                 6
    Packet Time:            04/06-14:11:18.097744
    Packet Bytes:           78
    Captured Bytes:         78
    Layers:                 4
[*] Ethernet (14 bytes)
    Source MAC Address:     00:00:D1:ED:8C:74
    Dest MAC Address:       00:04:5A:79:43:A7
    Encapsulated Protocol:  IPv6
[*] Internet Protocol version 6 (40 bytes)
    Version:                6
    Class:                  0 (0x0)
    Flow Tag:               96 (0x60)
    Packet Length:          24
    Next Header:            ipv6-icmp
    Hop Limit:              255
    Src Addr:               fe80::200:d1ff:feed:8c74
    Dst Addr:               fe80::204:5aff:fe79:43a7
[*] Internet Control Message Protocol Version 6
    Type:       136 (ND Neighbor Advertisement)
    Code:       0 
    Checksum:   24128 (INVALID 0000)
[*] Payload (8 bytes)
0x0000: 02 00 D1 FF FE ED 8C 74                          .......t         

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Finally I tell Snort to shut down.

sfips.shutdown()
[*] SFIPS ACTIVE data source src2 received 6 packets on fxp0
     Analyzed: 6 (100.000%)
      Dropped: 0 (0.000%)
[-] Ethernet Stats:
        Count: 6
[-] IPv6 Stats:
        Count: 6
[-] ICMPv6 Stats:
        Count: 6
     Bad Csum: 6
[-] Raw Stats:
        Count: 6
        Bytes: 48

This is obviously only the beginning. I plan to learn more about Lua to take advantage of the power in Snort 3.0.

Read More