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.

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.

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).

Symptom: Every available port from 1024-5000 is used to connect to various servers on destination port 445. Basically, the worm opens these connections to download and wait for malicious binaries.

The removal tools at http://www.bdtools.net/ does not detect this variant, and you have to use Dr.Web’s Cureit to detect and remove it. According to them, the recommended procedure is to install the following hotfixes:
* MS08-067
(http://www.microsoft.com/technet/security/bulletin/ms08-067.mspx);

* MS08-068
(http://www.microsoft.com/technet/security/bulletin/ms08-068.mspx);

* MS09-001
(http://www.microsoft.com/technet/security/bulletin/ms09-001.mspx).

And then run Cureit, a fully functional shareware app.

In case you’re reading this from an infected server, I’ve downloaded and included some of these files here (because if you’re infected, you won’t be able to access certain sites, drweb.com being one).

Well this isn’t one of those times, because this tool hit me from left field while I was researching ways to mitigate a DDoS attack. Though there are many, many ways to do it, if all you have is a Linux box facing the world with nothing to hide its private parts except iptables, then this “flexible (and fun)” toolset is another weapon you can deploy when you get that 2:30AM call saying “our website’s down and I think it’s being DDoS’d.”

The tool is a simple set of scripts that make adding and removing specific IP’s quick and simple. The main site of the author is at http://www.ibm.com/developerworks/library/l-fw/, or is available (hosted locally) here.

Once installed, you can simply ban/unban an IP by typing ipdrop {IP ADDRESS} {on|off}

While perusing this thread at webhostingtalk.com, member dynamicnet mentioned grep-ing for ridiculous levels of SYN_RECV ‘d connections (this is indicative of a TCP SYN Flood attack) and generating ipdrop commands for quick banning of a SYN Flood-ing IP’s. Though you may accidentally drop one or two legitimate IP’s (have a rule already in place so you don’t ban yourself out of a remote box), you’ll likely get the bulk of the attacking IP’s.

Use netstat -n -p|grep SYN_REC | wc -l to count how many SYN_RECV connections you have.

Use netstat -n -p | grep SYN_REC | awk '{print $5}' | sort -u | awk -F: '{print "ipdrop "$1 " on"}' to generate code to ban IP’s in SYN_RECV status.

Use cat /root/.dynfw-ipdrop |awk -F: '{print "ipdrop "$1" off"}' to generates code to “undrop” those IP’s.

Our favorite worm got an update 8 April according to Network World. Read more here…
And of course, at downadup.org.

Join the discussion at the Open Cloud Manifesto site.

Key Genius is a product that leverages the Yubikey to provide a more secure platform for logging into websites. It recently won an award in the Yubiking competition, in partnership with Security Now. The site stores site-specific passwords in an encrypted database, and using a browser extension, replies to valid Yubikey passwords by automatically inserting the correct password for the site. Usernames are not stored by Key Genius at all, so it’s up to the user to supply them to the website in question. This is actually a good thing, as compromise of the Key Genius database cannot in of itself bely a user’s logon credentials. This is a neat product that not only enhances convenience, but does so in a secure manner.

The headline at dailymail.co.uk read “April Fool’s Day computer virus is activated… but fails to cause internet chaos.”

I guess the rumors were unfounded. However, it’s important to note that the virus is still rampant and speculation on the potential uses of such a huge botnet are as well. Some surmise that it might be used to DDOS the crap out of some poor server(s). It might also be used to crack passwords or encryption. Check out http://downadup.org to read more and for removal tools. It’s also a good idea to prepare your network for the potentiality of attack. Don’t be a soft target.

Here’s a couple (read non-comprehensive) ideas on how to not be a soft target:

• Backup, backup, backup
  • Have systems ready to leap into action if necessary, and keep at least one form of backup offline in case of worst-case scenarios.
  • If you don’t already have a backup strategy in place, it’s time to implement one.
• Control access to your critical services
  • Enforce strong passwords – or better yet, employ multi-factor authentication. PPP is a strong candidate for the thrifty.
  • Audit your users – does that guy who quit last year still have an active user account? Do your non-administrative users have access to critical servers?
  • Use fail2ban or iptables to detect and drop password-guessing attacks – even with 10 million + IP’s to choose from, it’s not easy to crack a password/one-time password combination when you only get 3 tries per IP.
• Watch your traffic (not really a botnet vulnerability, but good practice in general):
  • Control your legacy services – seriously, it’s time to retire telnet and other services that transmit passwords in cleartext.
  • https > http – especially when it comes to passwords. Don’t allow users the ability to transmit passwords over http.
• etc…

I’ve hardly compiled a comprehensive list, and I welcome comments for other good practices, but the most important takeaway is to be cognizant of your security stance. Don’t make it easy for the bad guys.

If you can stand the gripes from your users, disabling Autorun through a forced registry setting (scripts, custom built ADM) is not a bad idea in general, so what if they have to open the folder and double-click the executable that’s likely in the top-level directory anyways?. Read the Cert/CC blog for more about this work around. Of key importance is that for whatever reason, the setting in HKCU overrides the HKLM setting. It may go without saying, but your best bet is cover both fronts.

If your network is infected presently, the following site hosted by BitDefender has a good list of symptoms to look for. In addition, the company has recently published both a single-workstation tool and a network tool to remove the worm from your computers. You can find these resources at http://downadup.org/.