LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 07-23-2019, 09:21 AM   #1
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Rep: Reputation: Disabled
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
 
Old 07-23-2019, 10:18 AM   #2
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,617

Rep: Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203
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
 
Old 07-23-2019, 12:01 PM   #3
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Original Poster
Rep: Reputation: Disabled
Hi Sean,
How to verify if this attempts are in 404 I mean the mod_proxy and probing. I am just wondering is there is anything else to further harden.
 
Old 07-23-2019, 03:43 PM   #4
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,617

Rep: Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203
That looks like logwatch output in your OP, yes?
You'll need to look into the actual web server logs to see what the actual response was.

I don't know where nginx logs are, or what their format is. Sorry.
 
Old 07-24-2019, 06:03 AM   #5
rnturn
Senior Member
 
Registered: Jan 2003
Location: Illinois (Chicago area)
Distribution: CentOS, MacOS, [Open]SuSE, Raspian, Red Hat, Slackware, Solaris, Tru64
Posts: 1,477

Rep: Reputation: 154Reputation: 154
Quote:
Originally Posted by newbie14 View Post

<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.
 
Old 07-24-2019, 11:00 AM   #6
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by scasey View Post
That looks like logwatch output in your OP, yes?
You'll need to look into the actual web server logs to see what the actual response was.

I don't know where nginx logs are, or what their format is. Sorry.
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?

Code:
95.213.177.123 - - [17/Jul/2019:18:36:37 +0800] "CONNECT check.proxyradar.com:80 HTTP/1.1" 400 150 "-" "-" "-"
95.213.177.125 - - [17/Jul/2019:09:13:49 +0800] "CONNECT check.proxyradar.com:80 HTTP/1.1" 400 150 "-" "-" "-"
95.213.177.126 - - [17/Jul/2019:23:14:32 +0800] "CONNECT check.proxyradar.com:80 HTTP/1.1" 400 150 "-" "-" "-"
For the probes the error code is 404.

Code:
182.138.214.75 - - [17/Jul/2019:16:30:56 +0800] "GET / HTTP/1.1" 403 146 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" "-"
182.138.214.75 - - [17/Jul/2019:16:30:57 +0800] "GET / HTTP/1.1" 403 146 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" "-"
182.138.214.75 - - [17/Jul/2019:16:30:57 +0800] "GET / HTTP/1.1" 403 146 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" "-"
182.138.214.75 - - [17/Jul/2019:16:30:58 +0800] "GET /currentsetting.htm HTTP/1.1" 404 146 "-" "-" "-"
182.138.214.75 - - [17/Jul/2019:16:30:59 +0800] "GET / HTTP/1.1" 403 146 "-" "-" "-"
182.138.214.75 - - [17/Jul/2019:16:31:00 +0800] "GET /winbox.png HTTP/1.1" 404 146 "-" "-" "-"
182.138.214.75 - - [17/Jul/2019:16:31:00 +0800] "GET /cgi-bin/nobody/Machine.cgi?action=get_capability HTTP/1.1" 404 146 "-" "-" "-"
182.138.214.75 - - [17/Jul/2019:16:31:06 +0800] "GET /device_description.xml HTTP/1.1" 404 146 "-" "-" "-"
182.138.214.75 - - [17/Jul/2019:16:31:07 +0800] "GET /current_config/passwd HTTP/1.1" 404 146 "-" "-" "-"
182.138.214.75 - - [17/Jul/2019:16:31:07 +0800] "GET /login/login.html HTTP/1.1" 404 146 "-" "-" "-"
Code:
5.188.210.101 - - [17/Jul/2019:16:26:32 +0800] "\x05\x01\x00" 400 150 "-" "-" "-"
5.188.210.101 - - [17/Jul/2019:16:28:59 +0800] "\x04\x01\x00P\x05\xBC\xD2e\x00" 400 150 "-" "-" "-"

Code:
5.188.210.101 - - [17/Jul/2019:16:31:37 +0800] "GET http://5.188.210.101/echo.php HTTP/1.1" 404 548 "https://www.google.com/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" "-"
 
Old 07-24-2019, 11:01 AM   #7
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rnturn View Post
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.
 
Old 07-24-2019, 11:08 AM   #8
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,617

Rep: Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203
Quote:
Originally Posted by newbie14 View Post
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.

Last edited by scasey; 07-24-2019 at 11:10 AM.
 
Old 07-24-2019, 11:34 AM   #9
rnturn
Senior Member
 
Registered: Jan 2003
Location: Illinois (Chicago area)
Distribution: CentOS, MacOS, [Open]SuSE, Raspian, Red Hat, Slackware, Solaris, Tru64
Posts: 1,477

Rep: Reputation: 154Reputation: 154
Quote:
Originally Posted by scasey View Post
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.

But, maybe that's just me.
 
1 members found this post helpful.
Old 07-24-2019, 11:47 AM   #10
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,617

Rep: Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203
Quote:
Originally Posted by rnturn View Post
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.
 
Old 07-24-2019, 11:49 AM   #11
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Original Poster
Rep: Reputation: Disabled
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.
 
Old 07-24-2019, 11:51 AM   #12
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Original Poster
Rep: Reputation: Disabled
Hi rnturn,
When does is becomes harm and how do you describe it as packet drop? Meaning they keep trying.
 
Old 07-24-2019, 11:52 AM   #13
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rnturn View Post
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 View Post
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 ?
 
Old 07-24-2019, 12:03 PM   #14
scasey
Senior Member
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.6
Posts: 3,617

Rep: Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203Reputation: 1203
Quote:
Originally Posted by newbie14 View Post
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
$1 can be a single IP address or cidr netblock.
 
Old 07-24-2019, 12:08 PM   #15
newbie14
Member
 
Registered: Sep 2011
Posts: 614

Original Poster
Rep: Reputation: Disabled
Hi Sean,
Where should I run it via a cron job it will need to read from nginx access or error log to find which ip right?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[nginx] stop nginx from buffering uptream hilou Linux - Software 0 11-08-2016 07:45 AM
nginx + php-fpm and nginx modules fantasygoat Linux - Server 0 06-09-2011 12:21 PM
Equivalent of NGINX proxy_intercept_errors with Apache mod_proxy samarudge Linux - Server 2 04-05-2011 11:53 PM
Is there any way to stop the kernel probing a specific USB controller? gzunk Linux - Hardware 9 11-22-2009 05:45 AM
How do I stop linux from probing for HDA and HDB? rdaves@earthlink.net Linux - General 5 10-21-2001 04:48 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 09:37 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration