How to completely stop mod_proxy and probing on nginx?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to completely stop mod_proxy and probing on nginx?
In my nginx.conf.
I have set this lines.
Code:
if ($request ~* ^[A-Z]+\ http ) {
return 404;
}
The problem I still a lot of this. The mod_proxy attempts still are being shown and also the probing on the server. How to completely to stop this attempts?
Code:
Connection attempts using mod_proxy:
95.213.177.123 -> check.proxyradar.com:80: 1 Time(s)
95.213.177.125 -> check.proxyradar.com:80: 1 Time(s)
95.213.177.126 -> check.proxyradar.com:80: 1 Time(s)
A total of 2 sites probed the server
182.138.214.75
5.188.210.101
I’m pretty sure the only way to stop probing attempts is to disconnect from the internet...
As long as the attempts are resulting in a “not found” (404) response, you’re doing all you can do, IMO
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,814
Rep:
Quote:
Originally Posted by newbie14
<snip>
The problem I still a lot of this. The mod_proxy attempts still are being shown and also the probing on the server. How to completely to stop this attempts?
Code:
Connection attempts using mod_proxy:
95.213.177.123 -> check.proxyradar.com:80: 1 Time(s)
95.213.177.125 -> check.proxyradar.com:80: 1 Time(s)
95.213.177.126 -> check.proxyradar.com:80: 1 Time(s)
A total of 2 sites probed the server
182.138.214.75
5.188.210.101
You should be able to deal with this with iptables---either on the nginx server or on a dedicated firewall system between the nginx server and the internet. You could drop any packets from those IP addresses on the floor and nginx would never see them.
You should be able to deal with this with iptables---either on the nginx server or on a dedicated firewall system between the nginx server and the internet. You could drop any packets from those IP addresses on the floor and nginx would never see them.
Hi rnturn,
Basically I am not centos 7 with firewalld and fail2ban enable. Is there anything I can further tweak on firewalld? Thank you.
I know where the logs and here are what I have extracted accordingly.
This is for the mod_proxy mostly the error code is 400?
[snip]
For the probes the error code is 404.
There you go. 400 is "Bad Request" and 404 is "Not Found" In the first case, the visitor is sending something in a form not acceptable to the server -- these are probably what's reported as "probes". Not Found just means a request for something that doesn't exist on the server.
No harm done.
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,814
Rep:
Quote:
Originally Posted by scasey
Not Found just means a request for something that doesn't exist on the server.
No harm done.
I tend to interpret those probes as something not benign. If a request comes into an nginx instance on a Linux system that's looking to access some Windows directory -- especially if it's repeatedly -- I'd consider it a break-in attempt looking to do some harm and drop the packets.
I tend to interpret those probes as something not benign. If a request comes into an nginx instance on a Linux system that's looking to access some Windows directory -- especially if it's repeatedly -- I'd consider it a break-in attempt looking to do some harm and drop the packets.
But, maybe that's just me.
I agree that those are break-in attempts, and that the intent is not benign. I will certainly put a permanent drop on IP addresses that do that kind of banging on the web server even if all those requests fail. I tend to block entire netblocks if there's a significant amount of abuse.
fail2ban can do that automatically, of course.
I am just saying to the OP that as long as the probes are failing, they're OK. But your point is certainly valid.
Hi Scasey,
So to double confirm between the logwatch I guess I should cross compare the logs like with what is reported on the logwatch summary. If those are 400 or 404 then just ignore them? I know we cant completely stop them but I just want to be sure no harm is done.
You should be able to deal with this with iptables---either on the nginx server or on a dedicated firewall system between the nginx server and the internet. You could drop any packets from those IP addresses on the floor and nginx would never see them.
Quote:
Originally Posted by scasey
I agree that those are break-in attempts, and that the intent is not benign. I will certainly put a permanent drop on IP addresses that do that kind of banging on the web server even if all those requests fail. I tend to block entire netblocks if there's a significant amount of abuse.
fail2ban can do that automatically, of course.
I am just saying to the OP that as long as the probes are failing, they're OK. But your point is certainly valid.
Hi Scasey,
Do I need to further perform some tweak to fail2ban to become more reactive and robust. When you say permanent drop on IP it will be on the firewalld ?
Hi Scasey,
Do I need to further perform some tweak to fail2ban to become more reactive and robust. When you say permanent drop on IP it will be on the firewalld ?
Perhaps, if it's not blocking those attempts. Although if one IP tries only one time per day, fail2ban is probably not going to catch it.
Here's a script I use when an IP or netblock catches my attention:
Code:
#!/bin/bash
if [[ ! $1 ]]
then
echo "usage is b1ip.sh <ip>"
exit
fi
IP=$1
echo "Blocking $IP"
firewall-cmd --add-rich-rule="rule family='ipv4' source address='$IP' reject"
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='$IP' reject"
## now list the rules
firewall-cmd --list-rich-rules | tail -5
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
