All of the public infrastructure is hosted at AWS, and can thus scale with the userbase. As Amazon charges anywhere from $0.055 to $0.150 per GB (pricing structure), each free user consumes from $0.11 to $0.30 per month. Even with 6.25% utilization of 8 Petabytes, Dropbox.com pays the $0.105 per GB rate, Given their next paid upgrade is for 50 GB and costs $9.99/month, one paid customer can support the storage fees for up to ($9.99 − 50 clients × $0.105) ÷ $0.21 = 22 clients covered in the cost of a single paid user, at full utilization of each user. However, most users won’t be using their full utilization (think Google mail), and their business model becomes more lucrative.

Starting with dropbox is simple. Download the client, register your account, and a folder is created where you can drag and drop your data. All data in this folder is replicated to dropbox servers, and to all dropbox client nodes that you link to your account.

The application ships with an intuitive user interface (no S3 accounts to configure, as this is done for you), and a rich feature set that includes automatic versioning, automatic syncing, cross-platform compatibility, intuitive web publishing, and a simple pricing model.

The one feature that really stood out however, was how they garner feedback for this actively developed product. Users can navigate to https://www.dropbox.com/votebox, where they can submit suggestions that get voted on and commented upon. This popularity contest likely helps the company focus on what projects need developing next.

All in all, this is an exciting company to be a customer of, and I would recommend y’all take a look at it too, as this appears to be what proper execution of a good idea looks like.

Kudos dropbox.com on a product well done.

With that thought in mind, let’s take a look at a couple different DoS attacks and the subsystem they target. The next series of articles will break down DoS types by the general subsystem they exploit.

Part 1: Memory Management / Behind Your Firewall

One type of DoS attack that takes advantage of poorly configured web servers is slowloris. This attack opens as many connections as your web server can handle, then keeps the connections open, with occasional

slowloris: hey.
webserver: what?
slowloris: ...
webserver: ...
webserver: are you still there?
slowloris: hey...
webserver: what?
slowloris: ...

statements.

Slowloris can be mitigated by rate limiting incoming connections to Apache and / or using a non-vulnerable front end web server, such as nginx.

Another tool that can be used maliciously is Google’s skipfish. This is a security scanner that can double as a load tester. Basically skipfish will form URLs based off of crawled data and dictionary based guesses. Used maliciously, it can overwhelm a poorly deployed LAMP stack. These servers may run out of memory and crash.

When it does, there may be an OOM_Killer message in your /var/log/messages file as a final, “OMG-help-me dump” right before reboot. Memory is a scarce resource in a system, and to improve performance, the Linux kernel will overcommit RAM to the numerous processes that request an allocation of memory space. Read more about the Linux kernel’s overcommit behavior here. In summary, it’s kind of like simultaneously sitting at five different $5 dollar black jack games with $20 in chips. Most times, a couple games will cash out, releasing chips back into the resource pool, and there is no net loss. The kernel runs faster, and everybody wins. That is, until traffic increases beyond what the system can handle, and everybody loses. When this happens, the kernel has to run from at least one table (and an angry pit boss). OOM_Killer is a program that was designed to handle exceptions to a linux kernel’s overcommit behavior and uses algorithms to determine which process to kill.

A particularly amusing analogy by Andries Brouwer describes OOM_Killer thus:

An aircraft company discovered that it was cheaper to fly its planes with less fuel on board. The planes would be lighter and use less fuel and money was saved. On rare occasions however the amount of fuel was insufficient, and the plane would crash. This problem was solved by the engineers of the company by the development of a special OOF (out-of-fuel) mechanism. In emergency cases a passenger was selected and thrown out of the plane. (When necessary, the procedure was repeated.) A large body of theory was developed and many publications were devoted to the problem of properly selecting the victim to be ejected. Should the victim be chosen at random? Or should one choose the heaviest person? Or the oldest? Should passengers pay in order not to be ejected, so that the victim would be the poorest on board? And if for example the heaviest person was chosen, should there be a special exception in case that was the pilot? Should first class passengers be exempted? Now that the OOF mechanism existed, it would be activated every now and then, and eject passengers even when there was no fuel shortage. The engineers are still studying precisely how this malfunction is caused.

So if you went to the win.tue.nl link I showed you, you’ll note that like a scared gambler, the kernel (after 2.5.30) can be instructed to be more reserved when allocating memory. The values in the below files will moderate this behavior.

echo 2 > /proc/sys/vm/overcommit_memory #this will tell the kernel to never commit memory over the swap space and a certain fraction of physical memory.*
echo 0 > /proc/sys/vm/overcommit_memory #(default) the kernel will do what it thinks is best
echo 1 > /proc/sys/vm/overcommit_memory #this will tell the kernel to go hog-wild and never refuse an app memory

*This fraction is defined in “/proc/sys/vm/overcommit_ratio” – the default value is 50 (=50%

But that’s not the cure-all to memory management. That just dictates kernel behavior. App behavior is another story. Here, you have to ensure your app never asks for more memory than your system can afford to give out. Now this is going to differ based on what type of server it is, but the most commonly exploited servers (from my perspective anyways) are LAMP stacks. And of the LAMP stack, the two most common reasons why OOM_Killer is invoked is:

For more on LAMP stack tuning, please refer to the following links:
http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html
http://www.interworx.com/forums/showthread.php?p=2346
http://www.ibm.com/developerworks/views/linux/…

Finally, you may wish to consider using a lighter web server, or a reverse proxy cacher to optimize performance. The bottom line is, when faced against an array of incoming attempts to overwhelm and disable your backend applications, you want your system to be robust enough to gracefully handle what it can, and redirect or ignore the rest.

In Part 2: Socket Management / Behind Your NIC, we’ll be looking at SYN Floods and other, non-port saturating attacks. Now as this series progresses, there will be some overlap in mitigation techniques that will impact more than one type of DoS attack. As long as these correlations are mutually beneficial, we’ll be just hunky-dory.

As I’m finding to be a trend for Linux guests, you must replace the default virtual NIC with the “Legacy Network Adapter” (you have to do this for Debian as well). Just follow the installer’s guidelines for the rest of the installation.

After it is installed, rebooting the OS becomes a problem. Hyper-V doesn’t seem to agree very well with the FreeBSD’s ACPI calls so in the interim, you can identify the hung VM by logging into powershell and running the following:

Get-WmiObject -Namespace root\virtualization msvm_computersystem | Format-Table ElementName,ProcessId

Then kill the process id with “kill [pid]“

In task manager,
- Inspect the “Command Line” field from the open vmconnect.exe process. Note the GUID of the VM (after the -G switch).
- Look for that GUID in the vmwp.exe “Command Line” field.
- Right click > End Process

The folks at peach.ne.jp have released a patch to correct this. Fetch it from here or failing that, locally.

On the VM, perform the following:


cd /usr/src
bzcat < /path/to/fbs80-200911-hvpatch.bz2 | patch -p1
make buildkernel
make installkernel
shutdown -r now


More to come as I start wading in.

Originals:
* http://shell.peach.ne.jp/aoyama/archives/577
* http://blogs.technet.com/abeshkov/archive/2008/12/15/3169299.aspx

=P

This is the first verse to KRS-One – Build Ya Skillz. Lyrics possibly NSFW.

Sean-One – Log Ya Mods
2010 erplefoo industries (erplefoo@gmail.com )

Check, I control your realm with one password I speak
And spread your auth all over like a raid level 5′s disk seeks
Admins get kicked in they mouth with cleats
Kuz their plans failed to reach servers at the beach
Have a seat quick, I’ll set up your account bits, time to complete shit
Looks like I need to reset shit, I mean set perms properly
I can feel myself becoming an admin monopoly
Others will copy mtree but apply my shit sloppily
Shocking me with static straps not entirely attached to me
Electroshock it seems to be
My true identity is never meant to be
Exposed in the sun that shit’s bright daily

(chorus)

But admins mod too much shit and fuckin’ forget to log it
LOG YOUR MODS
Admins talk too much shit
And send quotes up to reddit
LOG YOUR MODS

You can follow Sean on Twitter at @sdfoo

See http://www.internetworkexpert.org/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/ for a more in-depth discussion on this.

Most download accelerators are able to increase transfer rates by simply employing multiple TCP pipes that dump into the same file. This doesn’t solve the TCP window size problem, but takes advantage of what the uplink is capable of handling. Most modern browsers do this automatically, so download accelerators are really not a necessity any more.

You may wish to optimize your per-TCP connection transfer rates though. To do so, determine your optimal TCP window size based on the expected latency of your most bandwidth intense client-base (see the calculator at the above link). Then, based on that, adjust your TCP/IP stack to adjust below:

To tweak Windows 2008 TCP Window Scaling, please refer to the following:

http://www.minasi.com/newsletters/nws0802.htm

http://www.speedguide.net/read_articles.php?id=2574

Note that Windows 2008 doesn’t allow you to tweak settings like 2003 did. You can make the system adjust it “more aggressively,” but you can’t hard code numbers in.

To tweak Windows 2003 TCP Window Scaling, please refer to the following:

http://articles.techrepublic.com.com/5100-10878_11-5034413.html

You may wish to also try: http://www.speedguide.net/tcpoptimizer.php

To tweak Linux TCP Window Scaling, please refer to the following:

http://www.speedguide.net/read_articles.php?id=121

Note that many other factors come into play for bandwidth calculation. In a hosting environment, your server must compete with other servers in the data center to reach the core routers and from there, must concentrate in various nodes and exchanges to reach a packet’s destination. Along the way, routers must prioritize and queue packets for transmission. We can check the health of this process by performing a traceroute between “slow links.” Network congestion at any one of these nodes can reduce overall transfer rate. On either one of the endpoints, disk I/O, or other system stress may be a bottleneck.

All in all, an 100Mbps, or even an 1000Mbps uplink will not provide transfer rates greater than what the network fabric in between the source and destination can handle, and not greater than what the server / client can negotiate within the TCP pipe.

#18 Feb 2010 – Edited for spelling/grammar.

#24 Mar 2010 – Updated link for 2008 tuning.

I’ve edited out the ServerBeach specific stuff and will post pictures…. soonish.

The following link has some great pictures not included here. http://sqlblog.com/blogs/john_paul_c…h-hyper-v.aspx

I’ll add some nice little pictures here once I get some screenshots together.

CONFIGURE HYPERV

1. Configure an “Internal” HyperV network
2. Set each Virtual Machine to use the Internal network and assign them and your HyperV host on the correct subnet (in this example 10.0.0.1 for the host and 10.0.0.10 for the VM).

ENABLE ROUTING AND REMOTE ACCESS ON THE HOST MACHINE

1. Click -> Start -> Administrative Tools -> Routing and Remote Access
2. Right Click on Server#### (local) -> Configure & Enable Routing & Remote Access
3. Click -> Next on Welcome Window
4. Select Custom Configuration Click -> Next
5. Select NAT Click -> Next
6. Select your public interface
7. Select your Internal HyperV interface
8. Select “I will set up name and address services later” Click -> Next
9. Click -> Finish

CONFIGURE ROUTING AND REMOTE ACCESS ON THE HOST MACHINE

1. Routing and Remote Access should be running on the server now
2. Expand out the Server
3. Expand out IP Routing
4. Select NAT/Basic Firewall
5. Right-click your public interface. Select properties
7. Network Address Translation Properties Window will open
8. Select Radio Button for “Public Interface Connected to the Internet”
9. Select the check box for both “Enable NAT on this interface”
10. Click on the Address Pool Tab
11. Click the Add button and add your secondary IP addresses. The “Start Address” and “End Address” will be the same in most cases.

*NOTE* You do not want the secondary IP address configured in the TCP/IP Properties of the Host machine.

12. Click the Reservations button and enter your static IP mappings. That is, specify that you want traffic on your secondary IP mapped to your VM’s internal IP.
13. In services.msc, make sure that RRAS is set to start automatically and Windows ICS is disabled.

NOTES #1

When configuring and experimenting with the RRAS firewall, create a batch file to stop the service in case you forget to allow RDC or otherwise render the system inaccessible.

Code:

net stop “remoteaccess”

Then add the batch file to the scheduler and have it run some time after you apply your changes.

NOTE #2

RRAS is really finicky about the interfaces installed on the server. If an interface is changed in any significant way, it’ll have to be disabled and reconfigured.

Hyper-V is also similarly finicky about its virtual networks. I can’t count the number of times I had to remove and recreate networks. Thankfully, this was rather painless with only one VM to propagate changes to.

If you should encounter any difficulties with adding your additional VMs to the server, try resetting HyperV networking, individual VM network binding (in the VM’s settings), confirming physical host interfaces, and then reconfiguring RRAS in this order.

NOTE #3

Those who have had HyperV configuration problems solved it by disabling TCP/Offload Engine. Symptoms include, RRAS just not working, or working sporadically. If in doubt, disable TCP/Offload Engine

http://social.technet.microsoft.com/…8-d22aca6154ee
http://support.microsoft.com/default…b;EN-US;904946

So if this applies to you, run on the host and on any 2008 VMs:

$ netsh int ip set global taskoffload=disabled

and add the following registry key to any 2003 VMs:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\DisableTaskOffload

This is a DWORD entry that should have a value of 1.

You can install a Windows XP VM in Virtual PC on your Windows 7 workstation. The cool part is the integration. Install a Windows XP application, and it’s automatically integrated into your Start Menu in Windows 7.

I am so geeking out right now.

On October 3, T-Mobile Chief Operations Officer, Jim Alling wrote the following post on the T-Mobile forum site:

Dear valued T-Mobile Sidekick customers:

I realize that for many of you, your T-Mobile Sidekick is how you stay in touch with your friends, family and others.  I sincerely apologize for the impact the current disruption of data services may be having on you.  I assure you that T-Mobile is working very closely with Danger/Microsoft to resolve the issue as quickly as possible.  T-Mobile-supported services, such as voice calls and SMS/MMS, have not been affected and continue to be operational.  Danger/Microsoft has been working, and will continue working through the week, to restore data functionality and other features.

I understand that this data service disruption is very frustrating to our valued Sidekick customers.  For many years, the Sidekick has been, and continues to be, a cornerstone device for T-Mobile.  And we believe Sidekick customers are among the most loyal customers anywhere.  Recognizing that, and to address any inconvenience Sidekick data customers are experiencing, T-Mobile will automatically credit one month of data service to customers who subscribe to T-Mobile Sidekick data plans.  There is nothing you need to do to get this credit – T-Mobile will post the credit to these accounts in the coming days.

We will continue to post the latest information and FAQs to these Forums. I appreciate you being a loyal T-Mobile customer, and appreciate your patience as everyone works hard to resolve the current issues.  Thank you.

Sincerely,

Jim Alling, Chief Operations Officer, T-Mobile USA

Then, after a torrent of discussion on the forum site, the following update was provided earlier today:

Dear valued T-Mobile Sidekick customers:

We are thankful for your continued patience as Microsoft/Danger continues to work on preserving platform stability and restoring all services for our Sidekick customers.  We have made significant progress this past weekend, restoring services to virtually every customer.  Microsoft/Danger has teams of experts in place who are working around-the-clock to ensure this stability is maintained.

Regarding those of you who have lost personal content, T-Mobile and Microsoft/Danger continue to do all we can to recover and return any lost information.  Recent efforts indicate the prospects of recovering some lost content may now be possible.  We will continue to keep you updated on this front; we know how important this is to you.

In the event certain customers have experienced a significant and permanent loss of personal content, T-Mobile will be sending these customers a $100 customer appreciation card.  This will be in addition to the free month of data service that already went to Sidekick data customers.  This card can be used towards T-Mobile products and services, or a customer’s T-Mobile bill.  For those who fall into this category, details will be sent out in the next 14 days – there is no action needed on the part of these customers.  We however remain hopeful that for the majority of our customers, personal content can be recovered.
===
Dan
Moderator, T-Mobile Forums

At this time, neither Microsoft nor T-Mobile have confirmed conjecture that a SAN update caused the failure:

So yeah..

I would like to know what discounts are T-mobile going to give on a new Phone. I am probably going to move to the Moto Cliq, But I and other sidekick users should get a full phone discount not just a % of it..  (Microsoft should pay for it)

hmm Roz Ho haven’t you her of BACKUP…?

Quoting Hiptop3

“Currently the rumor with the most weight is as follows:

Microsoft was upgrading their SAN (Storage Area Network aka the thing that stores all your data) and had hired Hitachi to come in and do it for them. Typically in an upgrade like this, you are expected to make backups of your SAN before the upgrade happens. Microsoft failed to make these backups for some reason. We’re not sure if it was because of the amount of data that would be required, if they didn’t have time to do it, or if they simply forgot. Regardless of why, Microsoft should know better. So Hitachi worked on upgrading the SAN and something went wrong, resulting in it’s destruction. Currently the plan is to try to get the devices that still have personal data on them to sync back to the servers and at least keep the data that users have on their device saved. “

WOW.

Microsoft Do you understand that you are making yourself and T-mobile loose MONEY????

Also with me being a Sidekick owner I feel betrayed by Microsoft not T-mobile.

This outage I was all fine about at first but now it is just to much. We sidekick owners rely on Danger witch is now owned by Micro to keep are data stored on a secure server and that is why us users never backed up are data. I mean the sidekick does not even have a mass contact save Option. The user has to save them one by one. If I do stay with the sidekick I would like to see Options to save all on SD becuase a SIM can only hold around 250..

I have lost business and meetings from this outage and I am not happy.

So to everyone

It is not T-mobiles Fault so do not blame them. There customer service has been AWESOME

Also Danger and Microsoft do not comunicate with T-mobile as much that is why there is not much info.

“I wonder if we call Microsoft and bug them will they give us any info, they will probably say u have to call t-mobile. Well T-mobile is not the one who messed up,.they do not UPDATE THE SAN…..”

After a week of attempting to salvage the data, it would appear as though Microsoft was unsuccessful in doing so. If the SAN speculation is correct, then it was simply a failure of the data’s underlying SAN. The question is, why should a failing SAN bring with it the data of an entire customer base? I severely doubt that this would have occurred had this been a normal hardware breakdown. Well-designed storage solutions are built with the precondition of being able to survive a head failure, network failure, any sort of failure, really, without losing data. One would thus speculate that gross human error was at fault, and frankly, that means that management was not doing their job. Not enough layers of redundancy were built into this system, and not enough protective layers were written into policy to prevent this human error, or whatever it was, from cascading into a data-lost scenario. Data management is a big responsibility, and not enough resources go into its upkeep in many firms. It would thus appear that Microsoft appears to be one of the latter.

Back in July, http://ha.ckers.org/slowloris/ published an exploit against Apache and other web servers (go to the link for further) that takes advantage of multi-threaded applications. It works by tying up web server threads with partial HTTP requests, then sends TCP handshakes to keep the socket open. In general, multi-threaded web servers such as httpd, apache, and apache2 are vulnerable. IIS and most proxies are not vulnerable

CERT suggested using iptables to rate limit incoming port 80 requests. In general, this should be fine for many applications, though CERT has warned that some large clients behind NAT’s may be affected and thus the hitcount/time ratio should be adjusted according to your needs.

http://www.funtoo.org/en/security/slowloris/ offers tips on mitigating this attack by enabling delayed binding on hardware load balancers.

In short, it appears as though the consensus mitigation method involves connection restrictions in the form of iptables or apache modules (most are of limited value, frankly), or shielding the web servers behind load balancers (such as HA-Proxy).