0

I have a server running multiple web hosts (all internally managed) which was the subject of what looked like a dos attack last night. I blocked the attacking IP in IPTABLES for both input and output chains. That seemed to solve the problem and I went home.

This morning the server died again - this time it seems from netstat that it was sending multiple SYN's to the attacking IP. Obviously they were dropped by IPTABLES OUTPUT chain, but there were so many in the stack that it failed.

I am worried that the server is sending syn's to the attacker. Presumably it's trying to establish a new outbound connection to the attacker IP on port 80, but why? Does this mean the server is compromised? How can I find what is causing this? I have tried netstat -p but it just shows the owner of the outgoing attempts as httpd.

There are some big sites in the web directory so my attempt at grep'ing for the attacker IP in all the web files would take days.

What to do?

Many thanks in advance....

  • SOLVED - I finally realised that the attacking IP was spoofed. It was the IP of the Yahoo weather API which is called from one of the virtual hosts each minute as well as other scripts running on that host. Because I had blocked that IP the box was sending SYN's that never went anywhere! There were no compromised files found and now that I have replaced the IPTABLES DROP rules with more specific ones detailing the port everything works fine again. What a pain in the neck that was. Many thanks to those of you who read and thought about this for me. – Bob Howlett Sep 03 '18 at 08:41

1 Answers1

0

Server/virtual host might be compromised, and the site might try to download additional shells/backdoors/instructions. Hard to say how to find out which virtual host is.

If you can't grep on production server, you could try to grep on backup. Same with logs.

Or just take a look at the files modified in past 24-48 day .

If httpd=Apache, you might try to grab the pid from netstat, then try to match in server-status output ( if the IP is dropped, then that server thread might run for a long time , until wget/curl/whatever times out ).

You could also try to find requests with very long response times in httpd logs ( you have to modify log format, since usually neither web server logs the request time )

Sandor Marton
  • 1,544
  • 9
  • 12