Brute Force SYN Attach – Thousands Of Request A Second
Moderator: General Moderators
Brute Force SYN Attach – Thousands Of Request A Second
Hi All,
For the last 6 months our site has been under severe brute force, syn flood attack. They keep bombarding a single URL of the server and it is xml file. They are not attacking any other URL.
e.g. http://www.example.com/rss123/attackedfilename.xml
We have removed the xml page from our site but still they keep on sending requests, this is for the last 6 months non stop.
The IP has been changed just to see and they are sending several thousand requests per second. The requests come from different IPS and different ranges, so you can not even block the IP’s. They seem to be coming from a legitimate IP’s.
Due to this I have had to pay for an extremely expensive server which holds 8 GB of RAM and quad core processor etc, however, even with this the server server still reaches critical level, just because these requests are eating up my resources.
Our technical team has been working on all aspects of apache server security, external modules, firewall, hardware firewall from beginning but still we are not able to stop them.
We have installed following modules.
1) mod_security
2) mod_evasive
3) Firewall
We have worked with the hosting company and their technical team leader, he installed the best CISCO hardware firewall and tried to stop them, but in vain.
We have checked our server to see if anything from our site is causing the request, no extra file uploaded on to the server. For example if some file has been upload or some text has been added to the file (checked if we’ve been hacked). Even though we checked for any hacks, I am still wondering if there is something we do not know about. Can a hack lead to huge amounts of traffic?
We need some help to stop these attacks. We have searched a lot and have found that sites that get attacked like this have only one option is to shut down till it stops. I really hope that will not be the case for us. Please let us know if any one has any ideas to deal with this.
We are willing to try any small suggestion which might help from coding to scripting to modules to firewall. So please provide suggestion/solutions and way to get us out of this.
Also could it be our own part of php code which can do this? We are ready to check every php file to make sure it does not have any line of code which can be dangerous?
Thank you for your help in advance! Help!
Regards,
Sam
For the last 6 months our site has been under severe brute force, syn flood attack. They keep bombarding a single URL of the server and it is xml file. They are not attacking any other URL.
e.g. http://www.example.com/rss123/attackedfilename.xml
We have removed the xml page from our site but still they keep on sending requests, this is for the last 6 months non stop.
The IP has been changed just to see and they are sending several thousand requests per second. The requests come from different IPS and different ranges, so you can not even block the IP’s. They seem to be coming from a legitimate IP’s.
Due to this I have had to pay for an extremely expensive server which holds 8 GB of RAM and quad core processor etc, however, even with this the server server still reaches critical level, just because these requests are eating up my resources.
Our technical team has been working on all aspects of apache server security, external modules, firewall, hardware firewall from beginning but still we are not able to stop them.
We have installed following modules.
1) mod_security
2) mod_evasive
3) Firewall
We have worked with the hosting company and their technical team leader, he installed the best CISCO hardware firewall and tried to stop them, but in vain.
We have checked our server to see if anything from our site is causing the request, no extra file uploaded on to the server. For example if some file has been upload or some text has been added to the file (checked if we’ve been hacked). Even though we checked for any hacks, I am still wondering if there is something we do not know about. Can a hack lead to huge amounts of traffic?
We need some help to stop these attacks. We have searched a lot and have found that sites that get attacked like this have only one option is to shut down till it stops. I really hope that will not be the case for us. Please let us know if any one has any ideas to deal with this.
We are willing to try any small suggestion which might help from coding to scripting to modules to firewall. So please provide suggestion/solutions and way to get us out of this.
Also could it be our own part of php code which can do this? We are ready to check every php file to make sure it does not have any line of code which can be dangerous?
Thank you for your help in advance! Help!
Regards,
Sam
Re: Brute Force SYN Attach – Thousands Of Request A Second
Hope that will help:
http://en.wikipedia.org/wiki/SYN_cookies
http://www.faqs.org/docs/securing/chap5sec56.html
DDoS SYN flood attack is a nightmare
http://en.wikipedia.org/wiki/SYN_cookies
http://www.faqs.org/docs/securing/chap5sec56.html
DDoS SYN flood attack is a nightmare
There are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
Sure, but I'm having a hard time understanding how it can be connected to a URL. Does SYN packet contain actual application level data (HTTP request)?VladSun wrote:DDoS SYN flood attack is a nightmare
Re: Brute Force SYN Attach – Thousands Of Request A Second
No, it doesn'tWeirdan wrote:Sure, but I'm having a hard time understanding how it can be connected to a URL. Does SYN packet contain actual application level data (HTTP request)?VladSun wrote:DDoS SYN flood attack is a nightmare
I saw the "SYN Flood" words and replied. Should have read the OP more carefully ...
@Php Freek
What about the REFERRERs in your logs?
There are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
Hi,
Thanks for the prompt responses.
@VladSun
Yes, we are having a real nightmare right now. I will read these links in detail in will see if anything is useful. Also I will pass it to my technical team for further details.
Also, SYN packets are carrying the http request however we are not getting any REFERRER in the log file. It seems that they are using console and directly requesting the URL so there is no chance of getting their referrer.
I am seeing the issue and will keep you guys updated for same. You also, please if you find anything, let me know.
Thanks again.
Sam
Thanks for the prompt responses.
@VladSun
Yes, we are having a real nightmare right now. I will read these links in detail in will see if anything is useful. Also I will pass it to my technical team for further details.
Also, SYN packets are carrying the http request however we are not getting any REFERRER in the log file. It seems that they are using console and directly requesting the URL so there is no chance of getting their referrer.
I am seeing the issue and will keep you guys updated for same. You also, please if you find anything, let me know.
Thanks again.
Sam
Re: Brute Force SYN Attach – Thousands Of Request A Second
Why can't you just block the requests for the specific URL at the firewall? They shouldn't even get to the web server. And they definitely shouldn't require lots of resources to handle.
Re: Brute Force SYN Attach – Thousands Of Request A Second
No, SYN packets (that is - TCP) do not carry any data that is somehow related to layers above Transport Layer. It's used only in the TCP handshake flow.Also, SYN packets are carrying the http request
OK, so it's automated DDoS attack indeed. I asked because there are DDoS attacks which are performed by legitimate users without their knowledge.we are not getting any REFERRER in the log file
That could be a solution, although Layer 7 firewalls usually require a lot of resources.onion2k wrote:Why can't you just block the requests for the specific URL at the firewall? They shouldn't even get to the web server. And they definitely shouldn't require lots of resources to handle.
You could put into your WWW server firewall (Linux only) an iptables rule like this:
Code: Select all
iptables -A INPUT -p tcp --dport 80 -m string --string "attackedfilename.xml" -j DROPThere are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
Code: Select all
iptables -N WWW
iptables -A INPUT -p tcp --dport 80 -j WWW
iptables -A WWW -p tcp -m recent --name WWWDDOS --update --seconds 3600 -j DROP
iptables -A WWW -p tcp -m string --string "attackedfilename.xml" -m recent --name WWWDDOS --set -j DROPAfter that, they should keep port 80 TCP/IP "silence" for one hour in order to have any access to port 80 on this server.
It's up to you to set up such a restrictive firewall.
PS: For iptables version >= 1.3.4 look below
Last edited by VladSun on Thu Jul 16, 2009 7:42 am, edited 7 times in total.
There are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
That's great work VladSun. Nice one.
Re: Brute Force SYN Attach – Thousands Of Request A Second
Thanks, I love iptablesonion2k wrote:That's great work VladSun. Nice one.
I've edited the rule set, so it's more efficient now
One thing to mention about the "recent match" - its "external" usage and module parameters:
Each file in /proc/net/ipt_recent/ can be read from to see the current list or written two using the following commands to modify the list:
echo xx.xx.xx.xx > /proc/net/ipt_recent/DEFAULT
to Add to the DEFAULT list
echo -xx.xx.xx.xx > /proc/net/ipt_recent/DEFAULT
to Remove from the DEFAULT list
echo clear > /proc/net/ipt_recent/DEFAULT
to empty the DEFAULT list.
The module itself accepts parameters, defaults shown:
ip_list_tot=100
Number of addresses remembered per table
ip_pkt_list_tot=20
Number of packets per address remembered
ip_list_hash_size=0
Hash table size. 0 means to calculate it based on ip_list_tot, default: 512
ip_list_perms=0644
Permissions for /proc/net/ipt_recent/* files
debug=0
Set to 1 to get lots of debugging info
Last edited by VladSun on Thu Jul 16, 2009 7:39 am, edited 1 time in total.
There are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
I tried my script and it didn't work - I had to modify it a bit.
It seems that after iptables version 1.3.4 a new parameter (and it's a required one) is added to the string match - --algo.
and it works beautifully 
It seems that after iptables version 1.3.4 a new parameter (and it's a required one) is added to the string match - --algo.
So, finally we have:--algo [bm|kmp]
bm: Boyer-Moore
kmp: Knuth-Pratt-Morris
Those are the algorithm implemented at the moment.
Code: Select all
iptables -N WWW
iptables -A INPUT -p tcp --dport 80 -j WWW
iptables -A WWW -p tcp -m recent --name WWWDDOS --update --seconds 3600 -j DROP
iptables -A WWW -p tcp -m string --algo bm --string "attackedfilename.xml" -m recent --name WWWDDOS --set -j DROPThere are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
Hi,
Thanks for all the details and suggestions. I just had a long meeting with my technical team and following are the updates.
1) SYN cookies is already Enable but not making much difference.
2) I will provide the packet details soon for the request to give the extra idea for the attack.
3) Following are the details I have got from my linux admin. This will help you to trace the issue in better way.
Problem: Apache SYN_RECV
OS - RHEL5
kernels - 2.6.18-92.1.22.el5-x86_64
2.6.18-92.el5-x86_64
rpms:-
kernel-devel-2.6.18-92.el5
kernel-headers-2.6.18-92.1.22.el5
kernel-devel-2.6.18-92.1.22.el5
kernel-2.6.18-92.1.22.el5
kernel-2.6.18-92.el5
OS Type:
cat /etc/issue
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
> cat /proc/version
Linux version 2.6.18-92.1.22.el5 (mockbuild@hs20-bc2-5.build.redhat.com) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Fri Dec 5 09:28:22 EST 2008
We are providing 403 code for the URL request. Following is part of Access Log
94.70.118.139 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; FunWebProducts; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; CT2077543_4.5.188.7)"
89.216.230.148 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10"
82.81.54.226 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB5; CT2077543_4.5.191.15)"
85.229.15.86 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6; .NET CLR 2.0.50727; CT2088752_4.5.188.7)"
92.237.189.17 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10"
84.106.127.218 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; eSobiSubscriber 2.0.4.16; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088433_4.5.188.7)"
87.93.30.98 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088347_4.5.188.7)"
93.86.61.247 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.0" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; CT2077543_4.5.188.7)"
91.152.228.27 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; Creative ZENcast v2.00.13; CT2088347_4.5.188.7)"
94.69.164.32 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts; .NET CLR 1.1.4322; .NET CLR 2.0.50727; CT2088700_4.5.191.15)"
82.201.180.177 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; CT2077543_4.5.189.28)"
83.248.2.230 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SIMBAR={46BC3752-9118-483D-8E88-CD3E89FCD192}; GTB6; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; CT2088752_4.5.188.7)"
99.235.137.30 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6; .NET CLR 2.0.50727; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; CT2077543_4.5.191.15)"
216.155.136.84 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; CT2077543_4.5.188.7)"
217.123.166.205 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB5; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088433_4.5.188.7)"
86.96.227.88 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; CT2077543_4.5.188.7)"
203.115.189.77 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; CT2077543_1.5.48.2; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10"
203.82.79.102 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; CT2088347_4.5.188.7)"
88.195.52.126 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088347_4.5.189.24)"
77.81.114.171 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6; SIMBAR={B471FCBA-22ED-11DE-91A3-00196693641D}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; CT2077543_4.5.191.15)"
92.84.250.65 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; CT2077543_4.5.191.15)"
netstat:
tcp 0 0 domain.com:http 85-156-91-20.elisa-mo:55168 SYN_RECV
tcp 0 0 domain.com:http 220.255.7.227:27183 SYN_RECV
tcp 0 0 domain.com:http 5e03cbc4.bb.sky.com:51086 SYN_RECV
tcp 0 0 domain.com:http 79.126.234.198:18139 SYN_RECV
tcp 0 0 domain.com:http 78.148.175.148:11115 SYN_RECV
tcp 0 0 domain.com:http 83-154-143-68.rev.lib:61479 SYN_RECV
tcp 0 0 domain.com:http ABTS-North-Static-248:54775 SYN_RECV
tcp 0 0 domain.com:http 90-230-131-95-no130.tb:1134 SYN_RECV
tcp 0 0 domain.com:http static-host119-73-6-2:49538 SYN_RECV
tcp 0 0 domain.com:http 222.127.130.238:gtp-control SYN_RECV
tcp 0 0 domain.com:http acl1-1571bts.gw.smartbr:g5m SYN_RECV
tcp 0 0 domain.com:http athedsl-282427.home.o:60002 SYN_RECV
tcp 0 0 domain.com:http CPE-58-166-77-138.nsw:60067 SYN_RECV
tcp 0 0 domain.com:http C-59-101-99-107.syd.c:51097 SYN_RECV
tcp 0 0 domain.com:http ti0111a380-2667.bb.on:60993 SYN_RECV
tcp 0 0 domain.com:http 92.81.2.242:60451 SYN_RECV
tcp 0 0 domain.com:http 118.100.120.248:pserver SYN_RECV
tcp 0 0 domain.com:http triband-del-59.178.84:50140 SYN_RECV
tcp 0 0 domain.com:http cpc4-leds5-0-0-cust82:obrpd SYN_RECV
tcp 0 0 domain.com:http ALyon-153-1-8-78.w86-:59494 SYN_RECV
tcp 0 0 domain.com:http 120.28.199.183:3comnetman SYN_RECV
tcp 0 0 domain.com:http h248.4.16.98.dynamic.:60758 SYN_RECV
tcp 0 0 domain.com:http 89.211.205.59:64217 SYN_RECV
tcp 0 0 domain.com:http CPE-124-187-26-30.qld:ff-sm SYN_RECV
tcp 0 0 domain.com:http frw.Gloworld.com:59104 SYN_RECV
tcp 0 0 domain.com:http 220.255.7.182:winpoplanmess SYN_RECV
tcp 0 0 domain.com:http srisaionline180.excell:1232 SYN_RECV
tcp 0 0 domain.com:http CPE-60-230-16-150.vic:52611 SYN_RECV
tcp 0 0 domain.com:http 203.82.91.102:41318 SYN_RECV
tcp 0 0 domain.com:http 69.171.165.50:32454 SYN_RECV
tcp 0 0 domain.com:http dsl-TN-static-195.:corbaloc SYN_RECV
tcp 0 0 domain.com:http 210.186.66.179:49330 SYN_RECV
tcp 0 0 domain.com:http ABTS-North-D:xinuexpansion3 SYN_RECV
tcp 0 0 domain.com:http c122-106-133-46.livrp:49273 SYN_RECV
tcp 0 0 domain.com:http 173.subnet125-1:nssalertmgr SYN_RECV
tcp 0 0 domain.com:http 121.246.52.30.dynamic:63977 SYN_RECV
tcp 0 0 domain.com:http mobile-3G-dyn-BC-179-1:4464 SYN_RECV
tcp 0 0 domain.com:http crd48.neoplus.adsl.t:aminet SYN_RECV
Following we have done till now is mentioned below for the configurations.
###############
sysctl.conf
##############
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536
# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
# Enable IP spoofing protection, turn on Source Address Verification
net.ipv4.conf.all.rp_filter = 1
# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1
# 65536 seems to be the max it will take
net.ipv4.ip_conntrack_max = 1048576
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1
#############
fwsnort, bfd burnintest chkrootkit ddos faf lsm nobody_check sim apf
#############
modsecurity-apache
LoadModule evasive20_module /usr/lib64/httpd/modules/mod_evasive20.so
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 3
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 30
</IfModule>
LoadModule security_module /usr/lib64/httpd/modules/mod_security.so
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 3
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 30
</IfModule>
####################
Again,
Hope this helps you to see the issue in details. I have also put the latest configurations to keep site going on.
If it may be where server has some maleware or spyware, please let me know the solution and we can scan the pc for that too. Besides these, please let me know for any suggestion you think will be helpful.
Thanks again for your time and have a wonderful day.
Sam
Thanks for all the details and suggestions. I just had a long meeting with my technical team and following are the updates.
1) SYN cookies is already Enable but not making much difference.
2) I will provide the packet details soon for the request to give the extra idea for the attack.
3) Following are the details I have got from my linux admin. This will help you to trace the issue in better way.
Problem: Apache SYN_RECV
OS - RHEL5
kernels - 2.6.18-92.1.22.el5-x86_64
2.6.18-92.el5-x86_64
rpms:-
kernel-devel-2.6.18-92.el5
kernel-headers-2.6.18-92.1.22.el5
kernel-devel-2.6.18-92.1.22.el5
kernel-2.6.18-92.1.22.el5
kernel-2.6.18-92.el5
OS Type:
cat /etc/issue
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
> cat /proc/version
Linux version 2.6.18-92.1.22.el5 (mockbuild@hs20-bc2-5.build.redhat.com) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Fri Dec 5 09:28:22 EST 2008
We are providing 403 code for the URL request. Following is part of Access Log
94.70.118.139 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; FunWebProducts; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; CT2077543_4.5.188.7)"
89.216.230.148 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10"
82.81.54.226 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB5; CT2077543_4.5.191.15)"
85.229.15.86 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6; .NET CLR 2.0.50727; CT2088752_4.5.188.7)"
92.237.189.17 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10"
84.106.127.218 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; eSobiSubscriber 2.0.4.16; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088433_4.5.188.7)"
87.93.30.98 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088347_4.5.188.7)"
93.86.61.247 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.0" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; CT2077543_4.5.188.7)"
91.152.228.27 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; Creative ZENcast v2.00.13; CT2088347_4.5.188.7)"
94.69.164.32 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts; .NET CLR 1.1.4322; .NET CLR 2.0.50727; CT2088700_4.5.191.15)"
82.201.180.177 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; CT2077543_4.5.189.28)"
83.248.2.230 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SIMBAR={46BC3752-9118-483D-8E88-CD3E89FCD192}; GTB6; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; CT2088752_4.5.188.7)"
99.235.137.30 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6; .NET CLR 2.0.50727; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; CT2077543_4.5.191.15)"
216.155.136.84 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; CT2077543_4.5.188.7)"
217.123.166.205 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB5; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088433_4.5.188.7)"
86.96.227.88 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; CT2077543_4.5.188.7)"
203.115.189.77 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; CT2077543_1.5.48.2; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10"
203.82.79.102 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; CT2088347_4.5.188.7)"
88.195.52.126 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618; CT2088347_4.5.189.24)"
77.81.114.171 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6; SIMBAR={B471FCBA-22ED-11DE-91A3-00196693641D}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; CT2077543_4.5.191.15)"
92.84.250.65 - - [11/Jun/2009:04:46:32 -0500] "GET /rss/test.xml HTTP/1.1" 403 292 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; CT2077543_4.5.191.15)"
netstat:
tcp 0 0 domain.com:http 85-156-91-20.elisa-mo:55168 SYN_RECV
tcp 0 0 domain.com:http 220.255.7.227:27183 SYN_RECV
tcp 0 0 domain.com:http 5e03cbc4.bb.sky.com:51086 SYN_RECV
tcp 0 0 domain.com:http 79.126.234.198:18139 SYN_RECV
tcp 0 0 domain.com:http 78.148.175.148:11115 SYN_RECV
tcp 0 0 domain.com:http 83-154-143-68.rev.lib:61479 SYN_RECV
tcp 0 0 domain.com:http ABTS-North-Static-248:54775 SYN_RECV
tcp 0 0 domain.com:http 90-230-131-95-no130.tb:1134 SYN_RECV
tcp 0 0 domain.com:http static-host119-73-6-2:49538 SYN_RECV
tcp 0 0 domain.com:http 222.127.130.238:gtp-control SYN_RECV
tcp 0 0 domain.com:http acl1-1571bts.gw.smartbr:g5m SYN_RECV
tcp 0 0 domain.com:http athedsl-282427.home.o:60002 SYN_RECV
tcp 0 0 domain.com:http CPE-58-166-77-138.nsw:60067 SYN_RECV
tcp 0 0 domain.com:http C-59-101-99-107.syd.c:51097 SYN_RECV
tcp 0 0 domain.com:http ti0111a380-2667.bb.on:60993 SYN_RECV
tcp 0 0 domain.com:http 92.81.2.242:60451 SYN_RECV
tcp 0 0 domain.com:http 118.100.120.248:pserver SYN_RECV
tcp 0 0 domain.com:http triband-del-59.178.84:50140 SYN_RECV
tcp 0 0 domain.com:http cpc4-leds5-0-0-cust82:obrpd SYN_RECV
tcp 0 0 domain.com:http ALyon-153-1-8-78.w86-:59494 SYN_RECV
tcp 0 0 domain.com:http 120.28.199.183:3comnetman SYN_RECV
tcp 0 0 domain.com:http h248.4.16.98.dynamic.:60758 SYN_RECV
tcp 0 0 domain.com:http 89.211.205.59:64217 SYN_RECV
tcp 0 0 domain.com:http CPE-124-187-26-30.qld:ff-sm SYN_RECV
tcp 0 0 domain.com:http frw.Gloworld.com:59104 SYN_RECV
tcp 0 0 domain.com:http 220.255.7.182:winpoplanmess SYN_RECV
tcp 0 0 domain.com:http srisaionline180.excell:1232 SYN_RECV
tcp 0 0 domain.com:http CPE-60-230-16-150.vic:52611 SYN_RECV
tcp 0 0 domain.com:http 203.82.91.102:41318 SYN_RECV
tcp 0 0 domain.com:http 69.171.165.50:32454 SYN_RECV
tcp 0 0 domain.com:http dsl-TN-static-195.:corbaloc SYN_RECV
tcp 0 0 domain.com:http 210.186.66.179:49330 SYN_RECV
tcp 0 0 domain.com:http ABTS-North-D:xinuexpansion3 SYN_RECV
tcp 0 0 domain.com:http c122-106-133-46.livrp:49273 SYN_RECV
tcp 0 0 domain.com:http 173.subnet125-1:nssalertmgr SYN_RECV
tcp 0 0 domain.com:http 121.246.52.30.dynamic:63977 SYN_RECV
tcp 0 0 domain.com:http mobile-3G-dyn-BC-179-1:4464 SYN_RECV
tcp 0 0 domain.com:http crd48.neoplus.adsl.t:aminet SYN_RECV
Following we have done till now is mentioned below for the configurations.
###############
sysctl.conf
##############
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536
# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
# Enable IP spoofing protection, turn on Source Address Verification
net.ipv4.conf.all.rp_filter = 1
# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1
# 65536 seems to be the max it will take
net.ipv4.ip_conntrack_max = 1048576
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1
#############
fwsnort, bfd burnintest chkrootkit ddos faf lsm nobody_check sim apf
#############
modsecurity-apache
LoadModule evasive20_module /usr/lib64/httpd/modules/mod_evasive20.so
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 3
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 30
</IfModule>
LoadModule security_module /usr/lib64/httpd/modules/mod_security.so
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 3
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 30
</IfModule>
####################
Again,
Hope this helps you to see the issue in details. I have also put the latest configurations to keep site going on.
If it may be where server has some maleware or spyware, please let me know the solution and we can scan the pc for that too. Besides these, please let me know for any suggestion you think will be helpful.
Thanks again for your time and have a wonderful day.
Sam
Re: Brute Force SYN Attach – Thousands Of Request A Second
I think my iptables solution will be in help 
Take a look at the scripts in this post:
http://www.vbulletin.com/forum/showthread.php?t=126699
Take a look at the scripts in this post:
http://www.vbulletin.com/forum/showthread.php?t=126699
There are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
You logs show that it looks like /rss/test.xml is accessed by RSS readers (so, referer should be blank).
Also, it looks like HTTP requests are done by real (human) users, although they may not know it.
Are you sure your log file format includes REFERER field?
Also, it looks like HTTP requests are done by real (human) users, although they may not know it.
Are you sure your log file format includes REFERER field?
There are 10 types of people in this world, those who understand binary and those who don't
Re: Brute Force SYN Attach – Thousands Of Request A Second
Hi,
Thank you very much for all the details for firewall and important links. I will work with my other linux admins for these solutions and will try to give you update on this.
I am doubting that it may be console who sends these requests. Regarding the Referrers, I am pretty sure.
Do you think it may be some spyware, virus or my own php code? Are we hacked? Few questions just scratching my head still we need to find it.
I will provide you the update soon and please keep positing your suggestion and update. Thanks a lot.
Sam
Thank you very much for all the details for firewall and important links. I will work with my other linux admins for these solutions and will try to give you update on this.
I am doubting that it may be console who sends these requests. Regarding the Referrers, I am pretty sure.
Do you think it may be some spyware, virus or my own php code? Are we hacked? Few questions just scratching my head still we need to find it.
I will provide you the update soon and please keep positing your suggestion and update. Thanks a lot.
Sam