IPv6 Focus Month: IPv6 over IPv4 Preference
Initially, most IPv6 deployments will be "Dual Stack". In this case, a host will be able to connect via IPv4 and IPv6. This brings up the question which protocol will be preferred, and if multiple addresses are possible, which source and destination address are used. RFC 6724 describes the current standard how addresses should be selected, but operating systems and applications, in particular browsers, do not always obey this RFC.
Lets consider a case where a web browser attempts to connect to a web server. Initially, the browser will resolve the web servers host name. The reply may include multiple IPv4 and IPv6 addresses, and the browser needs to select one destination address from the set of addresses returned. RFC 6724 offers a number of rules to accomplish this selection. I don't want to recite the detailed rules (which are a bit hard to parse and best left to the original RFC), but instead focus on the rules that are used in current operating systems and can explain some behavior seen in connections:
Rule 1: Rule one allows the operating system to maintain a list of addresses that turned out to be unreachable in the past. OS X for example does so. This rule takes into account that some connections may use tunnels or other mechanisms that make IPv6 (and later maybe IPv4) less stable. However, if an address once turned out to be bad and got blocklisted, it will remain unused even if connectivity is later repaired.
Rule 7: To continue with unstable tunneling mechanisms, Rule 7 will prefer native connectivity over tunneled connectivity. A "native" IPv4 address will be preferred over an automatically configured 6-to-4 tunnel with a 2002::/16 prefix. Teredo, another tunnel mechanism, was for example never meant to be preferred over IPv4 and is considered a connection of last resort. But for other tunnels it may not be obvious that they are tunnels (e.g. statically configured tunnels) and they are treated as native addresses)
In addition, applications may try to recover from a bad address choice on their own. This algorithm is usually referred to as "Happy Eyeballs" and Chrome is probably the most prominent implementation of it at this point. Normally, the preferred address pair is determined using an algorithm like the one outlined in RFC 6724, and a connection is attempted. Only after the connection timed out (which can take a while), the respective address is considered unreachable and a different address is used. Chrome on the other hand will wait only 300 ms to consider an address "bad". In addition, the address will not be added to a blocklist. Instead the address may be attempted again for the next connection. The result is that Chrome may flip forth and back between IPv4 and IPv6 as it connects to retrieve multiple pages from a dual stack web server. This can make it for example more difficult to analyze logs or conduct network forensics.
Happy Eyeballs is defined in more detail in RFC6555. It suggests not giving up too quickly on the IPv6 connection to avoid wasted network bandwidth. The recommended timeout per this RFC is 150-250ms.
https://isc.sans.edu/ipv6videos/HappyEyeBalls/index.html
https://isc.sans.edu/ipv6videos/
References: RFC6555: http://tools.ietf.org/html/rfc6555
RFC6724: http://tools.ietf.org/html/rfc6724
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
How Your Webhosting Account is Getting Hacked
If you're like me you actually have your own little website project hosted on one of the many inexpensive website hosting companies. Perhaps you've recommended one as a solution to a small business, or organization. You may also be aware that they are pretty attractive targets for professional computer criminals. Brian Krebs has a nice writeup of the value of your standard PC to a criminal here: http://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/
The Value of a Web-Hosting Account
I want briefly expand on the added value of compromising a box sitting in a rack in one of these hosting companies.
The first is that since they're already webservers, they do a better job with all the standard exploit-hosting, phishing-site, and other webserver values identified in Brian's analysis. Secondly, they usually enjoy more bandwidth access than the average home/business PC, which a big advantage for criminals interested in launching Distributed Denial of Service (DDoS) Attacks (http://ddos.arbornetworks.com/2012/12/lessons-learned-from-the-u-s-financial-services-ddos-attacks/) Thirdly, compromising a single session on a shared server opens up all of the other accounts on that server as well as other servers in that data-center.
How They Are Gaining Access
A webserver has a different attack surface from the normal workstation. This is how they're being compromised in no particular order.
Many webhosting providers limit the customer us using a web-based management tool like cpanel or webmin. They may have their own vulnerabilities that let an attacker in that way (if the hosting company isn't updating regularly or following good security practices.)
Many customers use these services because they don't have a lot of experience running servers, so they make make poor choices in selecting which applications they install and may be lax in keeping them up to date. Popular packages like wordpress, or drupal need to be regularly updated and configured securely. This is not always intuitive and there are a lot of vulnerable builds running out there.
FTP credentials are commonly targeted by other malware. For example, if your home PC stumbles upon an exploit site, one of the intermediary payloads will search for registry settings identifying FTP applications on the system and will attempt to extract the username/password and feed that up to the botnet controller. So while that botnet-for-hire is installing whatever banking trojan that they've been contracted for, they're also building up a database of credentials to other potential future hosting sites.
Once a criminal has an account on a server, it become easier for them to attack other accounts on the system or escalate privileges to take over the entire system. If a criminal has a stolen credit card or paypal account, they can easily gain access to an otherwise secure server.
What You Can Do
While you can't patch the server, cpanel, etc. you can keep your own services patched and configured securely. We live in an environment where you can't be certain that everything is secure, so you have to plan on something getting compromised and having a plan. In this case, you plan on the server being compromised some time in the future, and develop a recovery plan. This mean regular backups and inspection of the site. Logs should be exported off regularly for analysis and alerting. You want to quickly detect when things begin to go awry. So you should already work out what the best emergency/security/abuse contact process is for your hosting provider. These are things you will have to keep in mind when you recommend an inexpensive hosting solution to a friend, family member, or volunteer organization.
Comments