2

We have a shared webserver which is being monitored constantly by our ZABBIX agent. On some hours of day we have unusual TCP traffic on port 80. Lets say we have over 400 connections from IP address of 109.230.67.50 to our webserver.

We can easily block any connection from and to 109.230.67.50 from IPTABLES but we want to know which of our VIRTUAL HOSTS is receiving this connection or which of our VIRTUAL HOST scripts is making this outgoing connection to that specific IP address.

We are assuming that we have two scenarios. One for INBOUND and one for OUTBOUND

Is there any tool or way to find out exactly what website is receiving the connection or what script on our server is making outgoing connection to that IP?

It is noteworthy it is a CentOS6.5 server and we are using LITESPEED as webserver.

Best Regards

4 Answers 4

2

You could try doing this.

Write a cron job that inserts a log entry at a certain start of the window. Monitor the file through some kind of file watching script. And at that point you correlate that with the http logs. The logs are in the common log format.

http://ubuntuforums.org/showthread.php?t=866006

https://pypi.python.org/pypi/watchdog

Alternatively you could try writing a userspace netfilter hook that loads a python interpreter, so you can trigger all this on the fly. Though a kernelspace python might not be such a good idea.

Hope that helps!

0

Check the web server (HTTP) logs and filter by the IP address. That will show what resources (i.e. files, scripts, etc) are being requested.

1
  • Alas there are several scenarios where this will not work, ie: The connection is sending traffic to a backdoor that isn't logged (malicious apache module) or the connection is not receiving HTTP traffic (something like slowloris or LOIC).
    – wireghoul
    Nov 25, 2014 at 3:24
0

Blocking an IP address at the firewall typically means dropping or rejecting the initial packet of a TCP connection during connection setup. The virtual host that the client is trying to connect to isn't known until much later, once the TCP connection is established and the client starts sending the HTTP request (specifically, you're looking for the Host: header).

You might be able to handle this at the firewall level, using some fancy combination of state-tracking and packet payload inspection, but you're much better off doing this at the webserver level, using whatever access-control mechanisms it provides.

0

Running a packet sniffing tool like wireshark or tcpdump will let you clearly examine the traffic between the source IP and your web server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .