The End Of IP As We Know It
Today, IANA announced that it had handed out two more /8 IPv4 assignments to APNIC. As a result, IANA is down to 5 /8s, triggering its special policy to hand out one address to each regional registrar (RIR). The 5 RIRs are AFRNIC (Africa), APNIC (Asia Pacific), ARIN (North America), LACNIC (Latin America) and RIPE (Europe). [1]
IANA hands IP address space to the RIRs in chunks of /8s, who then pass it on to ISPs, who then pass it on to end users. Some large end users may approach their RIR directly, and some "legacy assignments" are managed by IANA directly.
But in the end, what does this all mean?
A Quick FAQ To IPv4 Exhaustion
1 - Will the Internet stop working?
No. As a matter of fact, it is unlikely that the IPv4 internet will stop any time soon. It will likely happily exist next to the IPv6 internet. There are some transition mechanisms set up. While not pretty, the two "internets" can talk to each other via proxies and tunnels.
2 - Why do we run out of addresses?
IPv4 allows for about 4 billion addresses. There are about 6 billion people on the world... how many addresses do you need (phone, home, work...)? Its a simple math issue compounded by the fact that for efficient routing sake, we can't assign all addresses.
3 - A lot of IPv4 space is still unused. Why don't we use it more effectively?
The problem is not just that we are running out of addresses, even though that is the killer issue here. Assigning addresses more effectively would mean that assignments would become smaller and routing tables would become more complex. In order to make this work, we would have to essentially "renumber" the internet, and still be out of addresses at some point.
4 - What about legacy space? Does Apple really need a /8?
In the beginning of the Internet, IPv4 address space was handed out very liberally. Remember it was just an experiment? Some of the original participants still have large IPv4 assignments which they don't use efficiently. However, even if all of them are handed back, it would delay the problem only by 1-2 years at great expense to the effected companies (and they have contracts giving them the rights to use the address space). Some "legacy allocations" have been returned in the past
5 - What do I need to do today?
Relax. Nothing is going to happen fast. the RIRs still have space left, depending on the region a few month to a year. After that, it will get tricky. You may already find it harder to get IP address space. Eventually, your ISP may ask for some space back as they can't get new addresses from the RIR. Over time, IPv4 will get more expensive than IPv6.
6 - So I can just wait and do nothing?
No. What you should do tomorrow (maybe today?) is setup a test lab to familiarize yourself with IPv6. It is easy to get going. Ask your ISP if they support it (or when), or setup a tunnel with a free tunnel provider like Hurricane Electric [2] or Sixxs [3] (there are others). You need a plan on how to deal with it. Even if you don't need IPv6, maybe your business partners start using it and you need to connect to them via IPv6.
7 - Can't I just ignore it?
Remember why you are using IP in the first place? It allows you to connect to customers, suppliers, branch offices. In short: It keeps you in business. Once these people expect IPv6 connectivity, you will likely have to move along with it. It is like any technology in that it ultimately has to support the business (and well... it is fun too!).
8 - What will change from a security point of view?
Everything and nothing. The most important change is probably the fact that NAT will become less important. Endpoint protection and carefully configured firewalls will become more important. Passive asset detection will become more important compared to active scanning. There is a lot of security gear you own that probably does a lousy job dealing with IPv6. Did I mention it requires a plan and testing?
[1] http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
[2] http://www.tunnelbroker.net
[3] http://www.sixxs.net
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
How Not to Respond to a Security Incident
Finding out that your organization's computer defenses has been breached is a stressful experience. Many are unprepared to deal with such situations, and some have a false sense of security as the result of impractical incident response plans.
Having read about the recent PlentyofFish.com security incident, as described by its founder and a more measured perspective from Brian Krebs, I was inspired to create this short list of what not to do when responding to a security incident:
- Don't drive the incident response (IR) team to work for several days without sleep. People's ability to conduct cognitive tasks is severely diminished when they are sleep-deprived. You may need to pull a one-nighter initially, but after that, stagger people's response tasks so they can get some rest.
- Don't make rush decisions when deciding upon the initial incident response steps. It is OK to take some time to assess the situation before taking action to avoid making mistakes. Of course, you need to balance this with waiting too long before making decisions regarding the next steps.
- Don't immediately attribute the source of the breach to people, companies or countries without conducting a thorough investigation. In particular, don't assume that the entity who notified you of the breach of a vulnerable condition is the entity responsible for the incident.
- Don't attempt to hire the entity who notified you of the breach to assist with incident response, unless there's truly no one else qualified for the job. They might not be responsible for the breach, but it's best to control the situation where you might accuse them of extortion. Also, there's no reason to encourage ambulance-chasing practices.
For more recommendations on what not to do when someone reports an incident, as well as for tips on what to avoid doing when reporting an incident, see our earlier diary Incident Reporting - Liston's "How-To" Guide.
In addition, here are a few Emergency Incident Response steps from Mandiant, which are a good starting point for responding to a security incident. I also put together a few incident response cheat sheets:
- Initial Security Incident Questionnaire for Responders
- Network DDoS Incident Response Cheat Sheet
- Security Incident Survey Cheat Sheet for Server Administrators
- Critical Log Review Checklist for Security Incidents
-- Lenny Zeltser
Lenny Zeltser leads a security consulting team and teaches how to analyze and combat malware. He is active on Twitter and recently launched a security blog.
The Importance of HTTP Headers When Investigating Malicious Sites
Incident responders sometimes need to investigate the nature of a website reported as being malicious. They do this by connecting to the remote site, while taking care not to infect themselves, perhaps by using a laboratory machine that isn't connected to the production network. They also take care to conceal their origin, perhaps by connecting using a non-corporate DSL line or by using an anonymizing proxy, such as Tor. There are a few other connection elements they need to account for.
When connecting to malicious websites to investigate them, take care to set your User-Agent and Referer headers according to the attacker's expectations.
The Referer Field of the HTTP Header
For instance, Websense documented a recent Kookface variant whose website looked at the Referer field of the HTTP request. If the victim visited the malicious website directly by typing the URL into the browser, the website would redirect to an apparently benign page that looked like Google news search results.
HTTP request headers when visiting the malicious page directly, without a referrer:
GET http://url-redacted HTTP/1.1
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1)
Proxy-Connection: Keep-Alive
Host: hostname-redacted.com
Benign response from the website looked like this when rendered by the browser:
.png)
In contrast, when the victim clicked on a link embedded in some page, the "Referrer" field was set:
GET http://url-redacted HTTP/1.1
Referer: http://example.com
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1)
Proxy-Connection: Keep-Alive
Host: hostname-redacted.com
As the result, the website redirected the visitor to another page. This one attempted to social-engineer the person into downloading and installing malware under the guise of a Flash player update:
This particular site didn't seem to care about the specific contents of the Referer field, as long as it was set. However, many websites will only attempt to attack the visitor if the Referer field is set to a particular value, such as the one corresponding to Google. This is a defensive strategy to make it harder for security analysts to investigate the
The User-Agent Field of the HTTP Header
The Koobface website above also paid attention to the User-Agent field of the HTTP header, attacking only visitors coming from the Windows platform. For instance, this request made the site think the person is connecting from a Linux platform:
GET http://url-redacted HTTP/1.1
Referer: http://example.com
Accept-Language: en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) Gecko Ubuntu/9.10 (karmic) Firefox/3.5.1
Proxy-Connection: Keep-Alive
Host: hostname-redacted.com
The website responded by displaying the following message before redirecting to a non-malicious website http://rolly.com.
Tools for Controlling HTTP Headers
When investigating malicious websites using Firefox, you can control your Referer header by using the RefControl add-on. You can control your User-Agent header using the User Agent Switcher add-on.
Another option is to use command-line page retrieval tools, such as wget and curl. We discussed ways of controlling the headers sent by these tools in an earlier diary.
For more control over your browser's interactions with the malicious website, consider proxying your lab's browser through a local proxy tool, such as Paros Proxy, Fiddler, WebScarab, etc.
-- Lenny Zeltser
Lenny Zeltser leads a security consulting team and teaches how to analyze and combat malware. He is active on Twitter and recently launched a security blog.
Comments