Apache.org: What didn’t work?
Further to the web incident of Apache software foundation in which the website has gone offline on Monday, a presentation has been published to clarify the cause of this incident and measures that have been taken. Providing details can help others to learn mistakes and be ready for any attack.
According to the analysis, the main cause of this attack was a vulnerability in the SSH key management. The story started when the server that hosted the apachecon.com (dv35.apachecon.com) website had been compromised which was running CentOS The attackers fully compromised this machine, including gaining root privileges, and destroyed most of the logs, making it difficult for administrators to confirm the details of everything that happened on the machine.
Once the attackers had gained shell access, they added CGI scripts to the document root folders of several Apache Software Foundation websites. A regular, scheduled rsync process copied these scripts to the production web server, eos.apache.org, where they became externally visible. The CGI scripts were used to obtain remote shells, with information sent using HTTP POST commands.
After this attack administrators created a new SSH-key with a minimum key length of at least 4096 bits , enforced the use of the from=”” and command=”” strings in the authorized keys file on the destination backup server and looking for disabling CGI support on most website systems.
Well here you can see the importance of capturing logs and how they are important to spot potential security issue, there is many types for log management for example if you have a big network with a various system you would better focus on a good correlation engine. If a small corporate with a small network infrastructure than its better to focus on the forensic capabilities so you can track down violations and recover your losses in a court of law. It’s up to you now to decide on what will be the focus.
make sure you subscribe to my RSS feed!