Solutions to apache application attacks

Preface

Recently, I encountered a problem where a small application on my website was about to go offline. The results were not stopped, the load was too high, the response was slow, and the check timed out, normal user requests are about 1000 + requests per day. The pv volume is not a problem at all. I checked cookie_log and found that there were as many as 5 Gb. I checked the logs and it was an attack, so I started my attack defense journey.

I. symptom

1. A 4-core server with a high load of over 40

2. http check times out for 10 s

3. Slow page access, for example, snail bait or even 503;

Ii. Cause Analysis:

The application architecture is apache + jboss, and the system is redhat. The normal daily traffic is between 500 and ~ 1000, the daily load is maintained at around 0 based on this, the business has been included in the deprecation plan ). With such a low access volume, there will be no high load and slow response. When I read the access logs, there are as many as 5 Gbps, which is undoubtedly an attack.

Attack features: A. Scattered IP addresses; B. The request URL is A POST login request; C. The attack agent is the same: Mozilla/4.0 (compatible; Win32; WinHttp. WinHttpRequest.5)

The attack must be intercepted. Otherwise, I will not be comfortable with it. Next, I will start my interception journey.

Iii. Attack Defense:

1. the most direct and simple one is iptables. The principle is very simple. It is to find out the attack IP address, and then drop the attack IP address through Iptables. Two scripts are encapsulated, as shown below:

A. Script 1: Get the attack IP address and add it to iptables: get_hack_iplist.sh

#/bin/bash#Edit:371782968@qq.com#Date:2013-06-22#Function:get hack ip list from cookie_log,then to iptables#cookie_log pathcookie_log="/home/app/logs/cookie_logs/`date "+%w"`/cookie_log"ip_counts="/home/app/fuck_hack/log/ip_hack.txt"ip_counts_temp="/home/app/fuck_hack/log/ip_hack.txt.temp"record_black_list="/home/app/fuck_hack/log/record_black_list.txt"#get counts Ip from cookie_logfunction get_ip_counts(){        tail -n 10000 $cookie_log | awk '{print $1,$5}' | sort | uniq -c | sort -rg | head >$ip_counts        #quchong        awk '{a[$2]+=$1}END{for(i in a)print i,a[i]}' $ip_counts >$ip_counts_temp}#add ip black list to iptablesfunction add_to_iptables(){        echo "date: `date "+%Y-%m-%d %H:%M:%S"`">>$record_black_list        while read line        do                #get Ip                ip=`echo $line | awk '{print $1}'`                #232.* is beside                if [ `echo $ip | grep '^232'|wc -l` -eq 1 ];then                        continue                fi                #get times                count=`echo $line | awk '{print $2}'`                if [ $count -ge 10 ];then                        echo -e "\t$ip\t$count">>$record_black_list                        /sbin/iptables -A INPUT -s $ip -p tcp  -j DROP                fi        done<$ip_counts_temp}get_ip_countsadd_to_iptable

B. Script 2: Clear iptables. This step aims to prevent iptables performance problems caused by mistaken kill or too many ip addresses: clear_iptables.sh

#!/bin/bash#edit :371782968@qq.com#date :2013-06-22#fucntion:clear iptables linklog="/home/app/fuck_hack/log/clear_iptables.log"echo "date: `date "+%Y-%m-%d %H:%M:%S"`">>$log/sbin/iptables -X && /sbin/iptables -Fif [ $? -eq 0 ];then        echo -e "\tclear iptables link OK!">>$logfi

3. Place the two scripts under crontab and execute them regularly as follows:

Iptables

# Scan the blacklist once every 2 minutes, add the blacklist to iptables */2 ***** sh/home/app/fuck_hack/get_hack_iplist.sh>/dev/null 2> & 1 # To prevent false positives and iptables performance, clear iptables3 */1 *** sh/home/app/fuck_hack/clear_iptables.sh>/dev/null 2> & 1 at every hour

So far, iptables is the easiest way to prevent attacks.

2. If the attack fails for several days, the problem may occur. The load is high and the response is slow. I suspect that the attack ip addresses are too scattered and the attack frequency is too high. After all, the ip address intercepted by iptable is limited, this time I tried a solution introduced on the Internet, which was intercepted by the mod_evasive module of apache.

Introduction to mod_evasive

Mod_evasive is a DDOS protection module for Apachehttpd servers. For WEB servers, It is a better extension module to defend against DDOS attacks. Although it does not completely defend against DDOS attacks, under certain conditions, it still slows down the load on servers of Apachehttpd. For example, using iptables, hardware firewalls, and other firewall devices together may have better results.
Official Address of mod_evasive:Http://www.zdziarski.com

Detailed configuration I will not talk about here, I refer to the open source China inside a share, address: http://www.oschina.net/question/17_1564

The detailed configuration and parameter descriptions are available. The following is my Configuration:

LoadModule evasive20_module   /usr/ali/apache2/modules/mod_evasive20.so<IfModule mod_evasive20.c>    DOSHashTableSize    85420    DOSPageCount        5    DOSPageInterval     1    DOSSiteCount        5    DOSSiteInterval     1    DOSBlockingPeriod   3600</IfModule>

The configuration here is very small and the rules are strict. If it takes effect, a dos-ip file is generated under the/tmp directory. Each ip address is an attack ip address, and the content of each file is the number of attacks on this ip address.

3. Although the above configuration takes effect, the load is reduced, and http can also be opened normally, but the effect is not obvious and I have not analyzed it in detail. I initially suspect that the access volume may be too large, the module is performing filtering and other performance problems, and the apache version is too old, so the effect may not be realized.

The hacker is awesome, and I have to go back to the company's hacker weapons. The XXX attack defense module, after a general effort, was finally configured to go online. Suddenly, on the console, hackers were exposed, various ip addresses and various agents. Take a long breath, get up, get a cup of coffee, smile, choose, all, purpose, black hole.

So far, it has completely banned hackers and caused them to play with you for several days.

Note: I didn't take this module into consideration immediately because the business system and apache version are too old and the XXX module version in the repository is not supported, the final development force did not know how to find a version from the zookeeper. With a try attitude, the installation configuration is complete and takes effect.

This article is from the "go with the wind" blog and will not be reposted!