26 Jan
2011
26 Jan
'11
12:59 p.m.
I setup a new VPS a month or so ago, but in the last week things have
got a little wild in the apache access and error logs.
I'm using firehol, denyhosts and fail2ban to try and stop the constant
traffic, and I guess it's my lack of regex knowledge that isn't
helping there. Those packages should help prevent stuff like:
203.186.54.50 - - [26/Jan/2011:12:42:12 +0000] "CONNECT
80.176.162.50:25 HTTP/1.0" 200 10417 "-" "-"
178.162.131.33 - - [26/Jan/2011:12:42:53 +0000] "GET
http://vastdata.net/ HTTP/1.1" 200 10312 "-" "-"
123.165.11.194 - - [26/Jan/2011:12:38:18 +0000] "GET
http://proxyjudge2.proxyfire.net/fastenv HTTP/1.1" 404 537 "-"
"Mozill
a/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
[Wed Jan 26 05:01:05 2011] [error] [client 76.253.161.24] File does
not exist: /var/www/vch/data
[Wed Jan 26 05:03:21 2011] [error] [client 112.194.97.133] script
'/var/www/vch/proxycheck.php' not found or unable to stat
[Wed Jan 26 05:07:57 2011] [error] [client 116.248.134.82] script
'/var/www/vch/proxygrade.php' not found or unable to stat, referer:
http://www.proxygrade.com/proxygrade.php?hash=C59C2E3FD31372BAD
D1004781F90050A953698723D3E
Comments, advice and regex guidance are always welcome.
Cie
26 Jan
26 Jan
1:28 p.m.
Hi Ciemon,
On Wed, Jan 26, 2011 at 12:59:38PM +0000, Ciemon Dunville wrote:
I setup a new VPS a month or so ago, but in the last
week things have
got a little wild in the apache access and error logs.
Unfortunately a continual background noise of exploit attempts is
the norm.
I'm using firehol, denyhosts and fail2ban to try
and stop the constant
traffic, and I guess it's my lack of regex knowledge that isn't
helping there. Those packages should help prevent stuff like:
203.186.54.50 - - [26/Jan/2011:12:42:12 +0000] "CONNECT
80.176.162.50:25 HTTP/1.0" 200 10417 "-" "-"
178.162.131.33 - - [26/Jan/2011:12:42:53 +0000] "GET
http://vastdata.net/ HTTP/1.1" 200 10312 "-" "-"
123.165.11.194 - - [26/Jan/2011:12:38:18 +0000] "GET
http://proxyjudge2.proxyfire.net/fastenv HTTP/1.1" 404 537 "-"
"Mozill
a/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
I suppose fail2ban etc. could help if you configure them to look for
this kind of stuff. But it's only going to stop the same IPs fro
returning. Before you go that way, what are your goals?
Is this causing you an actual problem?
Is it just the worry that these exploit scanners will actually find
something?
If it's not causing a problem I would be tempted to just split your
vhost accesses into separate logs and forget about it. The crap that
is scanning for exploits/open proxies will just end up in the
default vhost's logs.
I recommend something like Fail2Ban for protecting SSH because your
typical SSH scanner connects and tries thousands of
username/password combinations. You block them and then they move
on. So there's value in blocking them.
Something looking for a web app with an exploit, or seeing if you
are misconfigured into a proxy, will just connect once and try it
and them move on however. You might not see that IP again for ages.
It seems to me that there's a lot less value in firewalling them.
So unless there's some other issue then all I can think is to
protect your apps, keep them up to date and find ways to filter the
noise.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
2:34 p.m.
On 2011 January 26 Wednesday, Andy Smith wrote:
I recommend something like Fail2Ban for protecting SSH
because your
typical SSH scanner connects and tries thousands of
username/password combinations. You block them and then they move
on. So there's value in blocking them.
On the subject of stopping these annoying ssh scans, in case it's useful to
you here's the firewall rules I use:
iptables -A DropChain \
-p tcp --dport 22 \
-m state --state NEW \
-m recent --set --name SSH_PROBES
iptables -A DropChain \
-p tcp --dport 22 \
-m state --state NEW \
-m recent --update --hitcount 7 --seconds 60 --name SSH_PROBES \
-j DROP
Then I add DropChain to INPUT chain early on.
iptables -A INPUT -j DropChain
The first rule tags any new ssh connection with the name SSH_PROBES. The
second drops any new SSH_PROBES connection that is the seventh within 60
seconds. You can change the 7 and 60 to suit your own circumstances.
This pretty much eliminated the malicious ssh probes on my system. Leaving me
with a few attempts on the root account, rather than page after page of brute
force attempts.
Andy
--
Dr Andy Parkins
andyparkins(a)gmail.com
3:29 p.m.
On 26/01/11 14:34, Andy Parkins wrote:
On 2011 January 26 Wednesday, Andy Smith wrote:
Doesn't this also deny you access to your server if someone's probing it?
I recommend something like Fail2Ban for
protecting SSH because your
typical SSH scanner connects and tries thousands of
username/password combinations. You block them and then they move
on. So there's value in blocking them.
On the subject of stopping these
annoying ssh scans, in case it's useful to
you here's the firewall rules I use:
iptables -A DropChain \
-p tcp --dport 22 \
-m state --state NEW \
-m recent --set --name SSH_PROBES
iptables -A DropChain \
-p tcp --dport 22 \
-m state --state NEW \
-m recent --update --hitcount 7 --seconds 60 --name SSH_PROBES \
-j DROP
Then I add DropChain to INPUT chain early on.
iptables -A INPUT -j DropChain
The first rule tags any new ssh connection with the name SSH_PROBES. The
second drops any new SSH_PROBES connection that is the seventh within 60
seconds. You can change the 7 and 60 to suit your own circumstances.
This pretty much eliminated the malicious ssh probes on my system. Leaving me
with a few attempts on the root account, rather than page after page of brute
force attempts. 
8:14 p.m.
On 26 Jan 2011, at 15:29, Martin Meredith wrote:
[snip stuff about -m recent]
Doesn't this also deny you access to your server
if someone's probing it?
No, recent is based on the source IP, I think you're thinking of -m limit which is
global.
David
PS: Semi-related SSH advice: https://dgl.cx/2011/01/ssh-and-selective-password-auth
8:31 p.m.
I found the post provisioning section here quite useful for hardening my
VPS: https://tools.bitfolk.com/wiki/VPS_Setup_Guide
<https://tools.bitfolk.com/wiki/VPS_Setup_Guide>Daniel
4842
days inactive
4842
days old
5 comments
6 participants
participants (6)
-
Andy Parkins -
Andy Smith -
Ciemon Dunville -
Daniel Case -
David Leadbeater -
Martin Meredith