Keeping it Up | TechSNAP 20 | Jupiter Broadcasting

Apache and PHP have hooked up at the fail party, and we’ll share all the details to motivate you to patch your box!

Then Microsoft takes a stab at AES and we wrap it all up with a complete run down of Nagios, and how this amazing tool can alert you to a potential disaster!

All that and more, on this week’s TechSNAP!

Direct Download Links:

Subscribe via RSS and iTunes:

[ad#shownotes]

Show Notes:

All versions of the apache web server are vulnerable to a resource exhaustion DoS attack

A single attacker with a even a slow internet connection can entirely cripple a massive apache server
The attack uses the ‘Range’ header, requesting 1300 different segments of the file, causing the web server to create many separate memory allocations. The existing attack script defaults to running 50 concurrent threads of this attack, which will quickly exhaust all of the ram on the server and drive the server load very high.
Apache 1.3 is past it’s End Of Life and will not receive an official patch
A different aspect of this bug (using it to exhaust bandwidth) was pointed out by a Google security engineer over 4 years ago

PHP 5.3.7 contains a critical vulnerability in crypt()

Official Bug Report
The crypt() function used for hashing password received much attention in this latest version of php, and a bug was inadvertently introduced where when you hash a password with MD5, only the salt is returned. This means that when validating a login attempt, when the hash of the attempt is compared to the stored hash, only the salt will match, resulting in a failed login attempt. However if the user changes their password, or a new user registers, the stored hash will only be the salt, and in that case, any attempted password will result in a successful login attempt.
PHP 5.3.7’s headline bug fix was an issue with the way blowfish crypt() was implemented on linux (it worked correctly on BSD). Some passwords that contained invalid UTF-8 would result in very weak hashes
It seems that this error was caught by the PHP unit testing framework, so the fact that it made it in to a production release means that the unit testing was likely not properly completed before the release was made.
5.3.7 was released on August 18th. The release was pulled on August 22nd, and 5.3.8 was released on August 23rd

Researches have developed a new attack against AES

Researchers from a Belgian (Katholieke Universiteit Leuven) and a French (Ecole Normale Suprieure) University, working with Microsoft research have developed a new attack against AES that allows an encryption key to be recovered 3 to 5 times faster than all previous attacks
The attack would still take billions of years of CPU time with currently existing hardware
Full Paper with Details
Comments by Bruce Schneier
Additional Article

Feedback

Q: (DreamsVoid) I have a server setup, and I am wondering what it would take to setup a backup server, that would automatically take over if the first server were to go down. What are some of the ways I could accomplish this?

A: This is a rather lengthy answer, so I will actually break it apart, and give one possible answer each week, for the next few weeks. This weeks solution is to use DNS Failover. For this feature, I personally use a 3rd party DNS Service called DNS Made Easy . Once you are hosting your DNS with them, you can enable Monitoring and DNS Failover. This allows you to enter the IPs of more than one server for the DNS entry such as www.mysite.com. Only one IP will be used at a time, so it is not the same as a ‘Round Robin’ setup. This simplifies problems with sessions and other data that would need to be shared between all of the servers if they were used at the same time. DNSMadeEasy will monitor the website every minute from locations all over the world, and if the site is unreachable, it will automatically update your DNS record to point traffic to the next server on your list. It will successively fail over to each server on the list until it finds one that is up. When the primary server comes back, it can automatically switch back. We use this for the front page of ScaleEngine.com, if the site were ever down, it would fail over to a backup server we have at a different hosting provider. This backup copy of the site is still reliant of a connection to our centralized CMS (which also uses DNS Failover), and if that were down too, it fails over to a flat-HTML copy of our website that is updated once per day. This way, our website remains online even if both our primary and secondard hosting are offline, or if all 3 fail over servers for the CMS are down as well.

Q: (Al Reid) Nagios seems to be a very good open source and widely used network monitoring software solution, is it possible that you guys could discuss the topic of network monitoring for services, hosts, router, switches and other uses?

A: Nagios is an open source network monitoring system that can be used to monitor a number of different aspects of both the hosts (physical and virtual servers, routers) and the services of those hosts (programs like apache, mysql, etc). The most basic monitoring is just pinging the host, and entering an alert state if the host does not response, or if the latency or packet loss exceed a specific threshold. However the real power of a network monitoring system comes not only from alerting you (via email, text message, audible alarm) when something is down, but actually monitoring and graphing performance over time. For example, with my MySQL servers, nagios monitors not only that they are accessible, but graphs the number of queries per second, and the number of concurrent connections. This way, if I notice higher than expected load on one of the servers, I can pull of the graph and see that, yes, a few hours ago the number of queries per second jumped by 30%, and that is obviously what is causing the additional load. A huge number of things can be monitored using a combination of the nagios tools and the SNMP (Simple Network Management Protocol) interfaces exposed by many devices. For example, we monitor power utilization from our PDUs and traffic through each of our switch ports. Some of the main metrics we monitor on each server are: CPU load, load averages, CPU temperature, free memory, swap usage, number of running processes, uptime (alerts us when a device reboots unexpectedly), free disk space, etc. We also monitor our web servers closely, monitoring the number of connections, requests per second, number of requests waiting on read or write, etc. Nagios monitoring can be taken even further, more advanced SNMP daemons on servers can list the packages that are installed, and a nagios tool could be setup to alert you when a known vulnerable package is detected, prompting you to upgrade that package. Nagios can also monitor your SSL certificates and Domain Names, and alert you when they are nearing their expiration dates (Chris should have this so he doesn’t forget to renew JupiterBroadcasting.com every year). Nagios supports two different methods of monitoring. The first is ‘active’, which is the most commonly used, nagios connects to the server/service and checks that it is running, and gets the performance data, if any. However nagios can also support ‘passive’ data collection, where the server or service pushes performance data to nagios, and nagios can trigger an alert if an update is not received within a specific time frame, this can help solve a common issue we have discussed before, where the monitoring server is a weak point in the security of the network, a single host that is able to connect to even the most secure hosts in your network. With passive monitoring, you can have secure hosts or unroutable LAN hosts push their monitoring and performance data to nagios from behind the firewall, even when nagios cannot connec to that host. Other alternative to nagios are Zabbix, SpiceWorks or Cacti, but I have never used them.

Random SQL Injection Comic