• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Lots of access request from server ip

LucaMago

New Pleskian
Hi, I have found on 4 of my domains a lot of access request (of images) from the same ip of my server, how can i find who makes all those request to block them? There isn't even any user agents, all requests are like this (ex. server ip 1.2.3.4):

1.2.3.4 - - [04/Nov/2021:00:58:12 +0100] "GET /images/2021/09/golferenzo-780x520.jpg HTTP/1.1" 200 62848 "-" "-"

I'm using Cloudflare with mod_cloudflare already installed and working, as i could see in the log files other real ip from the other requests.

Thanks!
 
Website preview maybe?
No it's really too strange, because requestes are all through the entire image directory (splitted in years/months, wordpress cms). I tried to disable the entire site for 5 minutes (no cache) to look if those comes from some plugins but requestes kept coming, no malware detected in any of the interested sites, no open script to the external like some feeds or anything....what is strange is that mod_cloudflare send these requestes as it comes by my server ip address (that i couldn't obviously deny all access!).

In these 4 days of November traffic is already at 60GB for a site that doesn't make much traffic (110k users this month), there must be something like an attack but i don't know how to block it if it comes from server ip itself. I activated also Fail2Ban on Plesk but server ip is signed as trusted by default so nothing to do there.... probably someone is hiding their external request behind my server ip?
 
And this traffic really goes through the interface, not just loopback? What do iptraf or tcpdump say about this?
 
And this traffic really goes through the interface, not just loopback? What do iptraf or tcpdump say about this?
Yeah it goes directly to the resource (an image in this case), status 200. I never used iptraf or tcpdump, i saw that we have tcpdump command available through ssh, how can i use it to check this problem? Thanks!
 
I meant, does this traffic show up on the network, or is it just local (within the server)?
If you ssh into the server, pick a time with little legitimate traffic and do something like
tcpdump -i eth0 port not ssh
replace eth0 with your interface if necessary.
port not ssh is important because otherwise the packets of your ssh connection get dumped too, and the packets of that dump too, creating a feedback loop ...
 
Doing that tcpdump i can see that ip on the request, i used this command (sorry i'm not an expert!):

tcpdump -c 200 -n -i eth0 port not ssh

And saw a lots of something like this:

19:38:04.137665 IP 1.2.3.4.http > 5.6.7.8.25338: Flags [.], seq 20441:23361, ack 0, win 237, length 2920: HTTP
19:38:04.137660 IP 1.2.3.4.http > 5.6.7.8.25338: Flags [.], seq 17521:20441, ack 0, win 237, length 2920: HTTP
19:38:04.137669 IP 1.2.3.4.http > 5.6.7.8.25338: Flags [.], seq 23361:26281, ack 0, win 237, length 2920: HTTP

I just exampled 1.2.3.4 as the ip of my server and 5.6.7.8 the cloudflare ip. What does that means?
 
Could it be requests coming from Nginx and sent to Apache? That would be a normal behavior.
 
And saw a lots of something like this:

19:38:04.137665 IP 1.2.3.4.http > 5.6.7.8.25338: Flags [.], seq 20441:23361, ack 0, win 237, length 2920: HTTP
19:38:04.137660 IP 1.2.3.4.http > 5.6.7.8.25338: Flags [.], seq 17521:20441, ack 0, win 237, length 2920: HTTP
19:38:04.137669 IP 1.2.3.4.http > 5.6.7.8.25338: Flags [.], seq 23361:26281, ack 0, win 237, length 2920: HTTP

I just exampled 1.2.3.4 as the ip of my server and 5.6.7.8 the cloudflare ip. What does that means?
Well, when cloudflare talks to your server, tcpdump shows the request and the reply. This is the latter. These three all belong to the same reply, as you can tell from the sequence: First one at 19:38:04.137660 has seq 17521:20441, 19:38:04.137665 continuing seq 20441:23361, then 19:38:04.137669 seq 23361:2628, all with the same payload length as the reply is bigger than what fits in one reply packet and has to be split in to chunks of the maximum possible size.
 
Back
Top