Google never says how many servers are running in its data centers. The new estimate is based on information the company shared with Stanford professor Jonathan Koomey, who has just released an updated report on data center energy usage. Download Link
Google’s David Jacobowitz, a program manager on the Green Energy team, told Koomey that the electricity used by the company’s data centers was less than 1% of 198.8 billion kWh – the estimated total global data center energy usage for 2010. That means that Google may be running its entire global data center network in an energy footprint of roughly 220 megawatts of power.
“Google’s data center electricity use is about 0.01% of total worldwide electricity use and less than 1 percent of global data center electricity use in 2010,” Koomey writes, while cautioning that his numbers represent educated guesses extrapolated from the company’s information. “This result is in part a function of the higher infrastructure efficiency of Google’s facilities compared to in-house data centers, which is consistent with efficiencies of other cloud computing installations, but it also reflects lower electricity use per server for Google’s highly optimized servers.”
South Korea blocked port 25 for Security Issues
Summary: South Korea is considering a nation wide block of port 25, as a anti-spam countermeasure aiming to reduce the volumes of spam affecting the country.
The ban, set to go in effect as of December, will replace port 25 with port 587 and 465 for SMTPS.
Spamming through web-based email is yet another way for cybercriminals to bypass the newly introduced regulations. Once the CAPTCHA-solving process for popular free web-based email providers has been outsourced to Indian providers of CAPTCHA-solving services, thousands of newly registered emails will be automatically used for outgoing spamming purposes, once again successfully bypassing the newly introduced regulation.
Mostly because of the way modern malware and spam networks operate. For instance, modern malware has built-in SMTP engines that are port-independent. Moreover, geolocated and malware-infected hosts within South Korea could be automatically updated using the new specs in a matter of seconds, once again continuing the abuse of legitimate networks, while playing by the newly introduced rules.
Code Vulnerability Scanner, Android Mobile App
The Nessus Android app enables you to log into your Nessus Scanner Server to Remotely Control your vulnerability scans by Applying start, stop and pause for your Hosted Internet Web-application as well as analyze the results directly from your Android device.
Download it NOW
Download it NOW
Ruby's RSA Crypto Bug
The Ruby developers had a near miss with a crypto disaster when an "awful bug" crept into the language's source code development tree. A simple programming error made the library generate RSA keys that caused the encryption mechanism to produce clear text. Luckily, the error was caught before it made it to any release version of Ruby, but it provides a good example of how a simple error can have potentially far-reaching effects.
The problem only affects programs that have generated RSA keys with development versions of Ruby. The recent release of Ruby 1.9.3 is not affected by the problem. Where the problem does exist, the encryption and decryption functions appear to be working correctly; the bug has no effect on externally generated keys that are imported. Users of the development version of Ruby should check their Ruby programs if they generate keys and, if necessary, generate new keys as soon as possible.
The RSA asymmetric encryption technique differentiates between secret and public keys. The public key consist of a modulus n and an exponent e. The plain text, m, is encrypted according to the mathematical formula c = m^e mod n
The point is that the cipher, c, can usually only be decrypted with the secret key. However, the Ruby bug generated RSA keys with an exponent e=1. This only leaves c = m mod n
As m is always less than n, the RSA formula collapses into a variation of the legendary ROT26 cipher : c = m
Among other things, RSA is used for digital signatures. A signature generated with a key from a Ruby system with the defect is equivalent of a blank cheque, as it will cause any signature to be considered valid. Incidentally, the problem was caused by a trivial programming error that has nothing to do with cryptography: in a for loop for setting individual bits, the criterion for abandoning the loop was set incorrectly, causing every loop to be abandoned after the first iteration.
The problem only affects programs that have generated RSA keys with development versions of Ruby. The recent release of Ruby 1.9.3 is not affected by the problem. Where the problem does exist, the encryption and decryption functions appear to be working correctly; the bug has no effect on externally generated keys that are imported. Users of the development version of Ruby should check their Ruby programs if they generate keys and, if necessary, generate new keys as soon as possible.
Juniper Routing Problem disrupts Level 3 network
Yesterday several US and UK ISPs, including Time Warner Cable, Research in Motion, Eclipse Internet, Easynet and Merula, reported a range of errors and problems on the Level 3 backbone. Level 3 has now confirmed the reports. The cause of the problems appears to have been a bug in Juniper's Junos router operating system affecting the border gateway protocol (BGP).
US ISP Phyber Communications has told various US media organisations that other networks using Juniper routers were also affected by the failure, with most affected devices generating a memory dump and then restarting. Juniper manager Mark Bauhaus confirmed that the company had been made aware of the BGP error in edge routers on Monday morning. He stated that the bug had affected only a small number of Juniper customers and that the company already had a patch for the problem which was awaiting distribution to affected routers.
US ISP Phyber Communications has told various US media organisations that other networks using Juniper routers were also affected by the failure, with most affected devices generating a memory dump and then restarting. Juniper manager Mark Bauhaus confirmed that the company had been made aware of the BGP error in edge routers on Monday morning. He stated that the bug had affected only a small number of Juniper customers and that the company already had a patch for the problem which was awaiting distribution to affected routers.
Source: Linux.com
XtreemOS, Enabling Linux for the Grid
XtreemOS is a Linux-based Operating System, supporting Virtual Organizations over Grid Computing platforms. The development of XtreemOS is currently funded as an Integrated Project by the European Commission under the Sixth Framework Programme (FP6) sponsorship program. The project started in June 2006 to last for 48 months, thus ending in May 2010. As of beginning 2010, the project has been extended and will last until September 2010. The project is led by INRIA and involves 19 research and industrial partners from Europe and China.
Download it :)
Download it :)
Slow HTTP DoS Attacks
the recent OWASP AppSec DC presentation on Slow HTTP POST DoS attacks, the issue of web server platform DoS concerns have reached a new high. Notice that I said, web server platform and not web application code. The attack scenario raised by slow HTTP POST attack is related to web server software (Apache, IIS, SunONE, etc...) and can not be directly mitigated by the application code. In the blog post, we will highlight the two main varieties of slow HTTP attacks - slow request headers and slow request bodies. We will then provide some new mitigation options for the Apache web server platform with ModSecurity.
Network DoS vs. Layer-7 DoS
Whereas network level DoS attacks aim to flood your pipe with lower-level OSI traffic (SYN packets, etc...), web application layer DoS attacks can often be achieved with much less traffic. The point here is that the amount of traffic which can often cause an HTTP DoS condition is often much less than what a network level device would identify as anomalous and therefore would not report on it as they would with traditional network level botnet DDoS attacks.
Layer-7 Connection Consumption Attacks
Ivan Ristic brought up the concept of connection consumption attacks in his 2005 book "Apache Security":
5.4.3. Programming Model Attacks
The brute-force attacks we have discussed are easy to perform but may require a lot of bandwidth, and they are easy to spot. With some programming skills, the attack can be improved to leave no trace in the logs and to require little bandwidth.
The trick is to open a connection to the server but not send a single byte. Opening the connection and waiting requires almost no resources by the attacker, but it permanently ties up one Apache process to wait patiently for a request. Apache will wait until the timeout expires, and then close the connection. As of Apache 1.3.31, request-line timeouts are logged to the access log (with status code 408). Request line timeout messages appear in the error log with the level info. Apache 2 does not log such messages to the error log, but efforts are underway to add the same functionality as is present in the 1.x branch.
Opening just one connection will not disrupt anything, but opening hundreds of connections at the same time will make all available Apache processes busy. When the maximal number of processes is reached, Apache will log the event into the error log ("server reached MaxClients setting, consider raising the MaxClients setting") and start holding new connections in a queue. This type of attack is similar to the SYN flood network attack we discussed earlier. If we continue to open new connections at a high rate, legitimate requests will hardly be served.
If we start opening our connections at an even higher rate, the waiting queue itself will become full (up to 511 connections are queued by default; another value can be configured using the ListenBackLog directive) and will result in new connections being rejected.
Defending against this type of attack is difficult. The only solution is to monitor server performance closely (in real-time) and deny access from the attacker's IP address when attacked.
The issue at hand with these attacks is that the client(s) are opening connections with the web server and sending request data very slowly. For those of you familiar with the old LaBrea Tarpit app for slowing down network based worms, this is somewhat of a reverse approach. Instead of the defender (LaBrea) sending back a TCP Window size of 0 to the attacker (worm) which would force the TCP client to wait for a period of time before resubmitting, in this scenario the attacker is the one forcing the web server to wait. If a web client opens a connection and doesn't send any data to the web server then the web server will default to waiting for the connection's Timeout value to be reached. Wanna guess how long that time interval is in Apache by default? 300 seconds (5 minutes). This means that if a client can simply open a connection and not send anything, that Apache child process thread will sit idle, waiting for data, for 5 minutes. Ouch... So the next logical question to ask from the attacker's perspective is - What is the upper limit on the number of concurrent connections for Apache? This depends on your configs but the main ServerLimit directive has a hard coded value of 20000 (most sites run much less). This limit makes it very feasible for a much smaller number of DDoS clients to take down a site vs. the extremely large number required for network-based pipe flooding.
There are two types of attack to cover when a malicious client never sends a complete Request as specified by the HTTP RFC:
Subscribe to:
Posts (Atom)
