You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Robert Douglass <r....@onlinehome.de> on 2002/04/19 10:43:04 UTC
access log
Hello, I've been hosting a tiny website from my home for the past week, as a
temporary project, and I found the following in my access log:
"GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
"GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
"GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
"GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
"GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
"GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
HTTP/1.0" 404 329
"GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
HTTP/1.0" 404 329
"GET
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/sy
stem32/cmd.exe?/c+dir HTTP/1.0" 404 345
"GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
"GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
"GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
"GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
"GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
"GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
"GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
"GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
Does anybody have an idea what someone was trying to accomplish with this,
or if these requests may have originated from my ISP? Does anybody have any
suggestions on how to implement some basic security (I've done nothing!) to
protect myself? I'm using Apache 1.3.22. Thank you,
Robert Douglass
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Steve Leach <sl...@askalix.com>.
Robert,
I am a bit tied up at the moment but will send a mail back to you when
free - in the meantime, if you are using Apache on Win32 - check out the
http://www.apache.org site regarding redirect.
You really should not be directly connected to the Internet without a
Firewall, I would also recommend that you check out:
http://www.firewall.com and
http://www.free-firewall.org/
or more from http://www.homenethelp.com/web/howto/free-firewall.asp
or you could use an old cheap PC and build one using Linux - try
http://www.linuxsecurity.com/articles/firewalls_article-4236.html or more
from
http://www.bolthole.com/solaris/firewall.html
Best Regards,
Steve Leach
Network Manager
Mi-Int Limited
Eaglescliffe Logistics Centre
Durham Lane
Egglescliffe
URL: http://www.askalix.com
TEL: 01642 356205
e-mail: sleach@askalix.com
----- Original Message -----
From: "Robert Douglass" <r....@onlinehome.de>
To: <us...@httpd.apache.org>
Sent: Friday, April 19, 2002 10:07 AM
Subject: Re: access log
> Steve,
> Thank you for the information. I'm not a trained system administrator, and
I
> have to admit, I don't know what you mean, "try some checks on the input
and
> redirect if you find any expoint attempts". I am on a Win32 system (2000
> pro).
> -R.D.
> ----- Original Message -----
> From: "Steve Leach" <sl...@askalix.com>
> To: <us...@httpd.apache.org>
> Sent: Friday, April 19, 2002 10:55 AM
> Subject: Re: access log
>
>
> > This is Code Red or something like it.
> > See the following: http://www.cert.org/advisories/CA-2001-19.html
> > Note that Apache should be fine - also that if you are running *nix you
> are
> > OK.
> > If on a Win32 system you could try some checks on the input and redirect
> if
> > you find any exploit attempts!!!
> >
> > Best Regards,
> >
> > Steve Leach
> > Network Manager
> > Mi-Int Limited
> > Eaglescliffe Logistics Centre
> > Durham Lane
> > Egglescliffe
> > URL: http://www.askalix.com
> > TEL: 01642 356205
> > e-mail: sleach@askalix.com
> >
> > ----- Original Message -----
> > From: "Robert Douglass" <r....@onlinehome.de>
> > To: <us...@httpd.apache.org>
> > Sent: Friday, April 19, 2002 9:43 AM
> > Subject: access log
> >
> >
> > > Hello, I've been hosting a tiny website from my home for the past
week,
> as
> > a
> > > temporary project, and I found the following in my access log:
> > >
> > > "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> > > "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> > > "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > > "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > > "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
312
> > > "GET
> /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > > HTTP/1.0" 404 329
> > > "GET
> /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > > HTTP/1.0" 404 329
> > > "GET
> > >
> >
>
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/sy
> > > stem32/cmd.exe?/c+dir HTTP/1.0" 404 345
> > > "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
311
> > > "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
311
> > > "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
311
> > > "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
311
> > > "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400
> 295
> > > "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400
295
> > > "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0"
404
> > 312
> > > "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
312
> > >
> > > Does anybody have an idea what someone was trying to accomplish with
> this,
> > > or if these requests may have originated from my ISP? Does anybody
have
> > any
> > > suggestions on how to implement some basic security (I've done
nothing!)
> > to
> > > protect myself? I'm using Apache 1.3.22. Thank you,
> > >
> > > Robert Douglass
> > >
> > >
> > > ---------------------------------------------------------------------
> > > The official User-To-User support forum of the Apache HTTP Server
> Project.
> > > See <URL:http://httpd.apache.org/userslist.html> for more info.
> > > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> > > For additional commands, e-mail: users-help@httpd.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > The official User-To-User support forum of the Apache HTTP Server
Project.
> > See <URL:http://httpd.apache.org/userslist.html> for more info.
> > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> > For additional commands, e-mail: users-help@httpd.apache.org
> >
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Robert Douglass <r....@onlinehome.de>.
Steve,
Thank you for the information. I'm not a trained system administrator, and I
have to admit, I don't know what you mean, "try some checks on the input and
redirect if you find any expoint attempts". I am on a Win32 system (2000
pro).
-R.D.
----- Original Message -----
From: "Steve Leach" <sl...@askalix.com>
To: <us...@httpd.apache.org>
Sent: Friday, April 19, 2002 10:55 AM
Subject: Re: access log
> This is Code Red or something like it.
> See the following: http://www.cert.org/advisories/CA-2001-19.html
> Note that Apache should be fine - also that if you are running *nix you
are
> OK.
> If on a Win32 system you could try some checks on the input and redirect
if
> you find any exploit attempts!!!
>
> Best Regards,
>
> Steve Leach
> Network Manager
> Mi-Int Limited
> Eaglescliffe Logistics Centre
> Durham Lane
> Egglescliffe
> URL: http://www.askalix.com
> TEL: 01642 356205
> e-mail: sleach@askalix.com
>
> ----- Original Message -----
> From: "Robert Douglass" <r....@onlinehome.de>
> To: <us...@httpd.apache.org>
> Sent: Friday, April 19, 2002 9:43 AM
> Subject: access log
>
>
> > Hello, I've been hosting a tiny website from my home for the past week,
as
> a
> > temporary project, and I found the following in my access log:
> >
> > "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> > "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> > "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> > "GET
/_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > HTTP/1.0" 404 329
> > "GET
/_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > HTTP/1.0" 404 329
> > "GET
> >
>
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/sy
> > stem32/cmd.exe?/c+dir HTTP/1.0" 404 345
> > "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400
295
> > "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
> > "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
> 312
> > "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> >
> > Does anybody have an idea what someone was trying to accomplish with
this,
> > or if these requests may have originated from my ISP? Does anybody have
> any
> > suggestions on how to implement some basic security (I've done nothing!)
> to
> > protect myself? I'm using Apache 1.3.22. Thank you,
> >
> > Robert Douglass
> >
> >
> > ---------------------------------------------------------------------
> > The official User-To-User support forum of the Apache HTTP Server
Project.
> > See <URL:http://httpd.apache.org/userslist.html> for more info.
> > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> > For additional commands, e-mail: users-help@httpd.apache.org
> >
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Steve Leach <sl...@askalix.com>.
This is Code Red or something like it.
See the following: http://www.cert.org/advisories/CA-2001-19.html
Note that Apache should be fine - also that if you are running *nix you are
OK.
If on a Win32 system you could try some checks on the input and redirect if
you find any exploit attempts!!!
Best Regards,
Steve Leach
Network Manager
Mi-Int Limited
Eaglescliffe Logistics Centre
Durham Lane
Egglescliffe
URL: http://www.askalix.com
TEL: 01642 356205
e-mail: sleach@askalix.com
----- Original Message -----
From: "Robert Douglass" <r....@onlinehome.de>
To: <us...@httpd.apache.org>
Sent: Friday, April 19, 2002 9:43 AM
Subject: access log
> Hello, I've been hosting a tiny website from my home for the past week, as
a
> temporary project, and I found the following in my access log:
>
> "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> HTTP/1.0" 404 329
> "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> HTTP/1.0" 404 329
> "GET
>
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/sy
> stem32/cmd.exe?/c+dir HTTP/1.0" 404 345
> "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
> "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
> "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
312
> "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
>
> Does anybody have an idea what someone was trying to accomplish with this,
> or if these requests may have originated from my ISP? Does anybody have
any
> suggestions on how to implement some basic security (I've done nothing!)
to
> protect myself? I'm using Apache 1.3.22. Thank you,
>
> Robert Douglass
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by PeterKorman <ca...@eigenvision.com>.
On Sun, Oct 20, 2002 at 02:31:48PM -0400, Lee Grey wrote:
> On the other hand, given the fact that so many users have dynamic IP
> addresses, you are really blocking a number that can't be guaranteed to
> match the machine it came from at that moment. The next day or two weeks
> later, you are probably still vulnerable to the same "attack" from the same
> infected machine, while having blocked access to your site by whatever
> innocent machine currently has that IP address.
>
> Just a thought.
>
> Best wishes,
> Lee Grey
> Grey Matter
> http://www.URLinOne.com
that is the most compelling argument I've heard yet to age out the IP
attack addresses after 30 to 60 days. Thanks.
JPK
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by PeterKorman <ca...@eigenvision.com>.
On Sun, Oct 20, 2002 at 09:48:37PM +0200, Anders Widman wrote:
> Aren't ISPs interested in saving bandwidth? Why do they not simply
> offer their customers a free tool to check for nimda and other
> "famous" viruses?
>
> Btw. This tool that checks the logs for nimda. Do you have it
> available?
Itz pretty brain-dead brute force. But it works. Sort of.
Script started on Sun Oct 20 16:22:50 2002
+|/root# crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.19006 installed on Fri Oct 4 23:14:32 2002)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
xx yy * * * /usr/sbin/updateipashols.sh
+|/root# cat /usr/sbin/updateipashols.sh
#!/bin/bash
set +x
/bin/cp /etc/ipashols /tmp/$$ipashols$$
\cd /var/log/httpd
/bin/cat access_log* |\
/bin/grep -f /etc/ipattacksigs |\
/usr/bin/perl -n -e's/^([^\-]+) -.+$/\1/ && print' >> /tmp/$$ipashols$$
/bin/sort -u -n --field-separator='.' +0 +1 +2 +3 /tmp/$$ipashols$$ > /tmp/$$ipashols$$.new
/usr/bin/cmp /tmp/$$ipashols$$.new /etc/ipashols
rc=$?
if [ 0 -ne $rc ]
then
## found new attack sigs.
/bin/cp /tmp/$$ipashols$$.new /etc/ipashols
\cd /etc
timestamp=$(/bin/date +%Y%m%d.%H%M%S)
/usr/bin/ci -zLT -l -m"$timestamp" ipashols
/bin/date >> /var/log/httpd/iptruleupdate 2>&1
/usr/sbin/iptables.rules.sh >> /var/log/httpd/iptruleupdate 2>&1
/bin/date >> /var/log/httpd/iptruleupdate 2>&1
\cd /etc/sysconfig
/usr/bin/ci -zLT -l -m"$timestamp" iptables
WHEN=$(/bin/date +%Y.%m.%d.%H.%M.%S)
SUBJECT="[06] $WHEN IP Moron Update"
/bin/cat /etc/ipashols | /usr/bin/mutt me@myhost -s "$SUBJECT" -F /etc/tripwire.mailrc
fi
+|/root# cat /etc/ipashols
4.65.100.124
4.65.108.185
12.224.255.72
12.239.243.251
12.239.69.140
12.246.226.89
12.248.50.70
12.255.181.57
24.116.37.42
24.240.223.230
24.28.255.64
24.49.61.79
24.61.173.159
32.103.134.240
61.136.180.94
61.136.92.163
61.144.48.229
61.144.67.126
61.151.237.187
61.167.128.111
61.167.254.157
61.171.120.113
61.174.149.101
61.177.208.185
61.179.116.72
61.182.141.7
61.182.248.36
61.218.189.99
61.218.65.123
61.222.168.4
61.222.57.187
61.222.92.229
61.232.202.154
61.241.158.210
61.33.254.99
61.53.38.159
62.131.66.137
62.20.108.204
62.241.180.244
62.5.171.189
63.137.51.45
63.142.188.229
63.197.240.137
64.0.131.131
64.0.158.111
64.0.227.4
64.0.245.42
64.0.247.79
64.0.39.158
64.10.95.189
64.101.203.214
64.104.207.127
64.104.224.69
64.105.223.18
64.105.225.98
64.105.250.10
64.105.8.20
64.109.12.21
64.109.223.107
64.110.147.185
64.110.82.252
64.110.93.43
64.110.95.59
64.115.124.148
64.119.109.165
64.123.121.90
64.123.127.108
64.126.85.67
64.129.115.49
64.129.119.213
64.129.120.77
64.129.131.53
64.129.136.225
64.129.164.185
64.129.172.89
64.129.175.245
64.129.175.61
64.129.176.29
64.129.203.197
64.129.205.97
64.129.206.57
64.129.214.125
64.129.230.69
64.129.231.113
64.129.42.121
64.129.67.33
64.129.96.177
64.129.98.137
64.129.99.45
64.130.196.9
64.133.139.98
64.133.153.74
64.133.187.47
64.133.198.157
64.133.226.52
64.133.227.26
64.146.79.10
64.147.5.162
64.154.41.5
64.156.150.59
64.157.11.79
64.157.48.214
64.157.66.217
64.161.148.19
64.161.41.202
64.161.51.9
64.161.86.60
64.162.116.215
64.163.131.7
64.164.134.61
64.167.138.106
64.170.214.60
64.171.60.199
64.172.195.18
64.172.53.35
64.172.66.162
64.172.74.172
64.178.19.18
64.180.103.121
64.180.139.87
64.180.249.86
64.192.41.81
64.199.185.154
64.2.251.222
64.204.114.248
64.205.137.164
64.208.190.228
64.211.116.89
64.211.82.99
64.212.187.12
64.212.21.250
64.213.211.24
64.213.211.43
64.215.158.125
64.215.38.6
64.217.225.137
64.217.239.140
64.220.6.200
64.220.95.131
64.221.26.133
64.225.153.26
64.228.150.155
64.228.244.70
64.229.222.49
64.23.231.163
64.230.74.194
64.230.76.91
64.231.205.148
64.231.49.114
64.232.51.181
64.233.228.94
64.233.250.32
64.238.118.242
64.24.88.63
64.251.146.217
64.252.176.151
64.253.108.232
64.26.151.254
64.29.65.52
64.3.15.155
64.3.49.7
64.30.173.16
64.34.181.89
64.42.13.178
64.45.216.65
64.48.184.36
64.5.224.52
64.51.149.242
64.53.184.123
64.56.143.2
64.60.44.231
64.60.63.34
64.63.50.65
64.65.198.13
64.65.199.33
64.65.91.115
64.66.91.3
64.7.9.110
64.71.226.2
64.77.20.149
64.8.225.100
64.8.8.3
64.83.19.240
64.84.45.47
64.86.155.88
64.86.182.50
64.94.187.195
65.101.206.235
65.103.193.121
65.194.15.204
65.222.145.132
65.29.213.194
65.36.73.50
65.64.200.85
65.92.54.128
65.93.185.213
65.94.191.199
66.12.119.190
66.123.55.121
66.124.38.213
66.13.243.110
66.134.156.59
66.156.87.190
66.178.7.26
66.200.15.130
66.218.32.143
66.224.17.204
66.38.219.100
66.42.12.21
66.60.160.160
66.72.104.245
66.82.100.16
66.88.62.194
66.89.125.111
67.112.106.202
67.114.77.226
67.250.82.17
68.15.64.49
68.154.164.139
80.116.51.34
80.132.199.201
80.133.239.143
80.134.233.44
80.14.78.152
80.140.44.65
80.200.85.210
80.208.114.16
80.66.39.29
80.8.74.209
81.25.167.194
128.12.154.35
128.134.131.177
128.138.210.109
129.116.230.44
129.219.26.51
129.33.175.176
131.175.168.67
134.126.232.85
138.88.134.115
138.88.93.63
144.134.62.114
148.204.4.1
148.213.5.228
148.223.16.20
148.226.187.80
148.235.89.5
151.30.244.158
152.39.4.1
153.91.169.159
161.116.67.14
161.53.96.197
163.17.202.99
164.100.194.8
166.114.52.5
172.142.27.95
172.171.32.176
172.184.150.134
192.118.76.130
193.128.16.130
193.194.83.10
193.246.250.106
193.251.33.57
193.253.190.7
193.74.115.138
193.95.202.30
194.252.196.233
194.84.83.70
195.1.135.22
195.127.65.71
195.14.138.24
195.167.123.201
195.174.111.162
195.210.132.101
195.246.48.248
195.39.66.2
200.161.209.3
200.164.83.66
200.165.23.183
200.189.72.90
200.249.208.2
200.28.84.84
200.48.166.39
200.60.27.112
200.67.156.246
202.107.37.118
202.110.192.100
202.141.136.66
202.152.21.51
202.71.144.155
202.74.167.10
203.200.89.54
203.220.221.228
203.223.35.7
203.231.19.3
203.249.147.242
204.151.73.78
204.183.117.167
205.200.75.37
205.201.16.61
205.241.34.62
206.159.25.2
206.29.152.18
207.247.124.14
208.42.19.106
208.63.237.203
209.102.197.104
209.178.191.176
209.179.141.64
209.192.98.29
209.215.181.154
209.226.65.82
209.242.21.36
209.26.30.200
209.7.14.131
210.100.152.21
210.12.162.136
210.124.173.73
210.183.139.101
210.233.25.229
210.248.162.37
210.34.96.13
210.52.240.6
210.58.170.55
210.96.110.234
211.105.137.163
211.147.97.33
211.154.103.125
211.48.1.80
211.75.234.178
211.97.240.55
212.0.210.29
212.137.62.100
212.137.62.122
212.165.132.254
212.17.82.187
212.175.38.57
212.194.94.77
212.34.63.74
212.44.239.3
212.47.246.5
212.76.227.100
213.120.115.244
213.155.75.6
213.171.168.20
213.194.137.254
213.217.83.46
213.23.46.3
213.46.15.9
213.81.173.170
213.82.61.226
216.109.23.64
216.112.75.61
216.181.220.226
216.183.11.98
216.209.32.126
216.25.146.201
216.63.169.89
216.69.9.201
217.0.74.12
217.128.165.74
217.13.23.124
217.136.79.34
217.167.199.1
217.195.71.114
217.223.35.226
217.225.71.161
217.227.67.27
217.229.246.84
217.230.51.22
217.233.150.48
217.237.164.66
217.35.51.67
217.39.106.81
217.39.173.6
217.56.226.130
217.81.38.63
217.84.51.246
218.108.109.136
218.14.109.116
218.14.109.23
218.14.110.185
218.14.124.150
218.14.124.238
218.17.234.176
218.19.16.140
218.22.116.6
218.22.180.106
218.5.252.199
218.62.9.201
218.63.92.14
218.70.158.14
+|/root#
+|/root# cat /etc/ipattacksigs
/scripts/root.exe
/MSADC/root.exe
/system32/cmd.exe
"GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
+|/root#
+|/root#
+|/root# cat /usr/sbin/iptables.rules.sh
#!/bin/bash
#
# Load appropriate modules.
set -x
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
## ===========================================================
## Some definitions:
cd /etc/sysconfig/network-scripts
./ifdown eth1
cd /etc/init.d
export IPTABLES=/sbin/iptables
export ExtInterface="eth1"
export ExtIPAddress="64.129.234.29"
export ExtBroadcastAdr="64.129.234.31"
export IntInterface="eth0"
export IntIPAddress="192.168.X.Y."
export IntNetwork="192.168.0.0/24"
export NAMESERVER_1="216.227.56.20"
export NAMESERVER_2="216.227.112.50"
export NAMESERVER_3="192.168.X.Y."
export NAMESERVER_4="64.129.234.29"
export LOOPBACK="127.0.0.0/8"
export ANY="0.0.0.0/0"
export CLASS_A="10.0.0.0/8"
export CLASS_B="172.16.0.0/12"
export CLASS_C="192.168.0.0/16"
export CLASS_D_MULTICAST="224.0.0.0/4"
export CLASS_E_RESERVED_NET="240.0.0.0/5"
export P_PORTS="0:1023"
export UP_PORTS="1024:65535"
export TR_SRC_PORTS="32769:65535"
export TR_DEST_PORTS="33434:33523"
export NAMESERVER_1=$ANY
export p_dns=53
export p_http=80
export p_htps=443
export p_smtp=25
export p_ssh=22
export p_telnet=23
export p_ftpsyn=20
export p_ftp=21
export p_imap=143
export p_pop3=110
export p_imaps=993
export p_pop3s=995
export p_ldaps=636
export p_ldap=389
# These lines are here in case rules are already in place and the script is ever rerun on the fly.
# We want to remove all rules and pre-exisiting user defined chains and zero the counters
# before we implement new rules.
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
# Set up a default DROP policy for the built-in chains.
# If we modify and re-run the script mid-session then (because we have a default DROP
# policy), what happens is that there is a small time period when packets are denied until
# the new rules are back in place. There is no period, however small, when packets we
# don't want are allowed.
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP
## ============================================================
## Kernel flags
# To dynamically change kernel parameters and variables on the fly you need
# CONFIG_SYSCTL defined in your kernel. I would advise the following:
# Disable response to ping.
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
# Disable response to broadcasts.
# You don't want yourself becoming a Smurf amplifier.
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Don't accept source routed packets. Attackers can use source routing to generate
# traffic pretending to be from inside your network, but which is routed back along
# the path from which it came, namely outside, so attackers can compromise your
# network. Source routing is rarely used for legitimate purposes.
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
# Disable ICMP redirect acceptance. ICMP redirects can be used to alter your routing
# tables, possibly to a bad end.
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
# Enable bad error message protection.
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Turn on reverse path filtering. This helps make sure that packets use
# legitimate source addresses, by automatically rejecting incoming packets
# if the routing table entry for their source address doesn't match the network
# interface they're arriving on. This has security advantages because it prevents
# so-called IP spoofing, however it can pose problems if you use asymmetric routing
# (packets from you to a host take a different path than packets from that host to you)
# or if you operate a non-routing host which has several IP addresses on different
# interfaces. (Note - If you turn on IP forwarding, you will also get this).
for interface in /proc/sys/net/ipv4/conf/*/rp_filter
do
/bin/echo "1" > ${interface}
done
# Log spoofed packets, source routed packets, redirect packets.
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
# Make sure that IP forwarding is turned off. We only want this for a multi-homed host.
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward
# Note: With connection tracking, all fragments are reassembled before being
# passed to the packet-filtering code so there is no ip_always_defrag switch as there
# was in the 2.2 kernel.
## ============================================================
# RULES
# block ashols
for i in $(cat /etc/ipashols)
do
$IPTABLES -A OUTPUT -d $i -o $ExtInterface -j DROP
$IPTABLES -A INPUT -s $i -i $ExtInterface -j DROP
done
# Allow unlimited traffic on the trusted interfaces
$IPTABLES -A OUTPUT -o $IntInterface -d $IntNetwork -j ACCEPT
$IPTABLES -A INPUT -i $IntInterface -s $IntNetwork -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $ExtInterface -d ! $IntNetwork -j SNAT --to $ExtIPAddress
$IPTABLES -A FORWARD -s $IntNetwork -j ACCEPT
$IPTABLES -A FORWARD -d $IntNetwork -j ACCEPT
#$IPTABLES -A INPUT -i $ExtInterface -s 141.158.242.23 -j ACCEPT
#$IPTABLES -A OUTPUT -o $ExtInterface -d 141.158.242.23 -j ACCEPT
## LOOPBACK
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
## SYN-FLOODING PROTECTION
# This rule maximises the rate of incoming connections. In order to do this we divert tcp
# packets with the SYN bit set off to a user-defined chain. Up to limit-burst connections
# can arrive in 1/limit seconds ..... in this case 4 connections in one second. After this, one
# of the burst is regained every second and connections are allowed again. The default limit
# is 3/hour. The default limit burst is 5.
#
$IPTABLES -N syn-flood
$IPTABLES -A INPUT -i $ExtInterface -p tcp --syn -j syn-flood
$IPTABLES -A syn-flood -m limit --limit 9/s --limit-burst 35 -j RETURN
$IPTABLES -A syn-flood -j DROP
## AUTH server
# Reject ident probes with a tcp reset.
# I need to do this for a broken mailhost that won't accept my mail if I just drop its ident probe.
$IPTABLES -A INPUT -i $ExtInterface -p tcp --dport 113 -j REJECT --reject-with tcp-reset
## TRACEROUTE
# Outgoing traceroute anywhere.
# The reply to a traceroute is an icmp time-exceeded which is dealt with by the next rule.
$IPTABLES -A OUTPUT -o $ExtInterface -p udp --sport $TR_SRC_PORTS --dport $TR_DEST_PORTS \
-m state --state NEW -j ACCEPT
# ICMP
# We accept icmp in if it is "related" to other connections (e.g a time exceeded (11)
# from a traceroute) or it is part of an "established" connection (e.g. an echo reply (0)
# from an echo-request (8)).
$IPTABLES -A INPUT -i $ExtInterface -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
# We always allow icmp out.
$IPTABLES -A OUTPUT -o $ExtInterface -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
## FRAGMENTS
# I have to say that fragments scare me more than anything.
# Sending lots of non-first fragments was what allowed Jolt2 to effectively "drown"
# Firewall-1. Fragments can be overlapped, and the subsequent interpretation of such
# fragments is very OS-dependent (see this paper for details).
# I am not going to trust any fragments.
# Log fragments just to see if we get any, and deny them too.
$IPTABLES -A INPUT -i $ExtInterface -f -j LOG --log-prefix "$IPTABLES FRAGMENTS: "
$IPTABLES -A INPUT -i $ExtInterface -f -j DROP
## SPOOFING
# Most of this anti-spoofing stuff is theoretically not really necessary with the flags we
# have set in the kernel above ........... but you never know there isn't a bug somewhere in
# your IP stack.
#
# Refuse spoofed packets pretending to be from your IP address.
$IPTABLES -A INPUT -i $ExtInterface -s $ExtIPAddress -j DROP
# Refuse packets claiming to be from a Class A private network.
$IPTABLES -A INPUT -i $ExtInterface -s $CLASS_A -j DROP
# Refuse packets claiming to be from a Class B private network.
$IPTABLES -A INPUT -i $ExtInterface -s $CLASS_B -j DROP
# Refuse packets claiming to be from a Class C private network.
$IPTABLES -A INPUT -i $ExtInterface -s $CLASS_C -j DROP
# Refuse Class D multicast addresses. Multicast is illegal as a source address.
$IPTABLES -A INPUT -i $ExtInterface -s $CLASS_D_MULTICAST -j DROP
# Refuse Class E reserved IP addresses.
$IPTABLES -A INPUT -i $ExtInterface -s $CLASS_E_RESERVED_NET -j DROP
# Refuse packets claiming to be to the loopback interface.
# Refusing packets claiming to be to the loopback interface protects against
# source quench, whereby a machine can be told to slow itself down by an icmp source
# quench to the loopback.
$IPTABLES -A INPUT -i $ExtInterface -d $LOOPBACK -j DROP
# Refuse broadcast address packets.
$IPTABLES -A INPUT -i $ExtInterface -d $ExtBroadcastAdr -j DROP
## DNS
# NOTE: DNS uses tcp for zone transfers, for transfers greater than 512 bytes (possible, but unusual), and on certain
# platforms like AIX (I am told), so you might have to add a copy of this rule for tcp if you need it
# Allow UDP packets in for DNS client from nameservers.
$IPTABLES -A INPUT -i $ExtInterface -p udp -s $NAMESERVER_1 --sport 53 -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -A INPUT -i $ExtInterface -p tcp -s $NAMESERVER_1 --sport 53 -m state --state ESTABLISHED -j ACCEPT
# Allow UDP packets to DNS servers from client.
$IPTABLES -A OUTPUT -o $ExtInterface -p udp -d $NAMESERVER_1 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -o $ExtInterface -p tcp -d $NAMESERVER_1 --dport 53 -m state --state NEW,ESTABLISHED -j ACCEPT
################################################################################################
# ACCEPTED CLIENT PROTOCOLS #
################################################################################################
for client_protocol_port in $p_http $p_htps $p_smtp $p_telnet $p_ftp $p_ftpsyn $p_imap $p_pop3 $p_imaps $p_pop3s
do
$IPTABLES -A INPUT -i $ExtInterface -p tcp --sport $client_protocol_port -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -o $ExtInterface -p tcp --dport $client_protocol_port -m state --state NEW,ESTABLISHED -j ACCEPT
done
$IPTABLES -A INPUT -p tcp --sport $p_ssh -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport $p_ssh -j ACCEPT
################################################################################################
# PASSIVE MODE FTP #
################################################################################################
# 2) Passive ftp.
# This involves a connection outbound from a port >1023 on the local machine, to a port >1023
# on the remote machine previously passed over the ftp channel via a PORT command. The
# ip_conntrack_ftp module recognizes the connection as RELATED to the original outgoing
# connection to port 21 so we don't need NEW as a state match.
$IPTABLES -A INPUT -i $ExtInterface -p tcp --sport $UP_PORTS --dport $UP_PORTS -m state --state ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -o $ExtInterface -p tcp --sport $UP_PORTS --dport $UP_PORTS -m state --state ESTABLISHED,RELATED -j ACCEPT
# Disallow INVALID incoming or forwarded packets from ppp0.
$IPTABLES -A INPUT -i $ExtInterface -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -i $ExtInterface -m state --state INVALID -j DROP
################################################################################################
# ACCEPTED SERVER PROTOCOLS #
################################################################################################
for server_protocol_port in $p_http $p_htps $p_smtp $p_dns $p_ssh
do
$IPTABLES -A INPUT -i $ExtInterface -p tcp -d $ExtIPAddress --dport $server_protocol_port -j ACCEPT
$IPTABLES -A INPUT -i $ExtInterface -p udp -d $ExtIPAddress --dport $server_protocol_port -j ACCEPT
$IPTABLES -A OUTPUT -o $ExtInterface -p tcp -s $ExtIPAddress --sport $server_protocol_port -j ACCEPT
$IPTABLES -A OUTPUT -o $ExtInterface -p udp -s $ExtIPAddress --sport $server_protocol_port -j ACCEPT
done
################################################################################################
# REJECTED SERVER PROTOCOLS #
################################################################################################
for server_protocol_port in $p_ldap $p_ldaps $p_imap $p_imaps $p_pop3 $p_pop3s
do
$IPTABLES -A INPUT -i $ExtInterface -p tcp -d $ExtIPAddress --dport $server_protocol_port -j REJECT
$IPTABLES -A INPUT -i $ExtInterface -p udp -d $ExtIPAddress --dport $server_protocol_port -j REJECT
$IPTABLES -A OUTPUT -o $ExtInterface -p tcp -s $ExtIPAddress --sport $server_protocol_port -j REJECT
$IPTABLES -A OUTPUT -o $ExtInterface -p udp -s $ExtIPAddress --sport $server_protocol_port -j REJECT
done
## Make sure NEW tcp connections are SYN packets unless they are on the above ports
$IPTABLES -A INPUT -i $ExtInterface -p tcp ! --syn -m state --state NEW -j DROP
## LOGGING
# You don't have to split up your logging like I do below, but I prefer to do it this way
# because I can then grep for things in the logs more easily. One thing you probably want
# to do is rate-limit the logging. I didn't do that here because it is probably best not too
# when you first set things up ................. you actually really want to see everything going to
# the logs to work out what isn't working and why. You cam implement logging with
# "-m limit --limit 6/h --limit-burst 5" (or similar) before the -j LOG in each case.
#
# Any udp not already allowed is logged and then dropped.
$IPTABLES -A INPUT -i $ExtInterface -p udp -j LOG --log-prefix "IPTABLES UDP-IN: "
$IPTABLES -A INPUT -i $ExtInterface -p udp -j DROP
$IPTABLES -A OUTPUT -o $ExtInterface -p udp -j LOG --log-prefix "IPTABLES UDP-OUT: "
$IPTABLES -A OUTPUT -o $ExtInterface -p udp -j DROP
# Any icmp not already allowed is logged and then dropped.
$IPTABLES -A INPUT -i $ExtInterface -p icmp -j LOG --log-prefix "IPTABLES ICMP-IN: "
$IPTABLES -A INPUT -i $ExtInterface -p icmp -j DROP
$IPTABLES -A OUTPUT -o $ExtInterface -p icmp -j LOG --log-prefix "IPTABLES ICMP-OUT: "
$IPTABLES -A OUTPUT -o $ExtInterface -p icmp -j DROP
# Any tcp not already allowed is logged and then dropped.
$IPTABLES -A INPUT -i $ExtInterface -p tcp -j LOG --log-prefix "IPTABLES TCP-IN: "
$IPTABLES -A INPUT -i $ExtInterface -p tcp -j DROP
$IPTABLES -A OUTPUT -o $ExtInterface -p tcp -j LOG --log-prefix "IPTABLES TCP-OUT: "
$IPTABLES -A OUTPUT -o $ExtInterface -p tcp -j DROP
# Anything else not already allowed is logged and then dropped.
# It will be dropped by the default policy anyway ........ but let's be paranoid.
$IPTABLES -A INPUT -i $ExtInterface -j LOG --log-prefix "IPTABLES PROTOCOL-X-IN: "
$IPTABLES -A INPUT -i $ExtInterface -j DROP
$IPTABLES -A OUTPUT -o $ExtInterface -j LOG --log-prefix "IPTABLES PROTOCOL-X-OUT: "
$IPTABLES -A OUTPUT -o $ExtInterface -j DROP
# Disallow NEW and INVALID incoming or forwarded packets from ppp0.
$IPTABLES -A INPUT -i $ExtInterface -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -i $ExtInterface -m state --state NEW,INVALID -j DROP
$IPTABLES -A OUTPUT -j REJECT
$IPTABLES -A FORWARD -j REJECT
# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
sh /etc/rc.d/init.d/iptables save
cd /etc/sysconfig/network-scripts
./ifup eth1
# THE END
# ==================================================================
+|/root#
+|/root#
+|/root#
Script done on Sun Oct 20 16:27:01 2002
>It can be used to just record all the hits to a logfile.
> Sending this to the ISP once a month is easy enough =)
Yea. I'd like to automate it though. And only include access
log entries associeted with that particular ISP. I
think my laundry is pretty clean but I prefer a dryer to
a clothes line ;-)
JPK
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by Anders Widman <an...@tnonline.net>.
Aren't ISPs interested in saving bandwidth? Why do they not simply
offer their customers a free tool to check for nimda and other
"famous" viruses?
Btw. This tool that checks the logs for nimda. Do you have it
available. It can be used to just record all the hits to a logfile.
Sending this to the ISP once a month is easy enough =)
- Anders
> actually, if you check the agreement with your isp, you will find a line
> that requires you to clean viruses out of your system, report the
> offending ip to their isp, they will have to clean it out.
> (I send 10 mb of access log to my isp, since a lot of their clients had
> both codered and nimda, they thanked me and the number of these hits has
> dropped drastically)
> Lee Grey wrote:
>> On the other hand, given the fact that so many users have dynamic IP
>> addresses, you are really blocking a number that can't be guaranteed to
>> match the machine it came from at that moment. The next day or two weeks
>> later, you are probably still vulnerable to the same "attack" from the same
>> infected machine, while having blocked access to your site by whatever
>> innocent machine currently has that IP address.
>>
>> Just a thought.
>>
>> Best wishes,
>> Lee Grey
>> Grey Matter
>> http://www.URLinOne.com
>>
>> -----Original Message-----
>> From: Jeff Beard [mailto:jeff@cyberxape.com]
>> Sent: Sunday, October 20, 2002 2:24 PM
>> To: users@httpd.apache.org
>> Subject: Re: [users@httpd] Re: access log -- GET
>> /scripts/..%%35%63../winnt/system32
>>
>>
>>
>>
>> PeterKorman wrote:
>> [...]
>>
>>
>>>So my question is this: It this sledgehammer I'm using likely to hurt me?
>>
>>
>> No but neither is the worm.
>>
>> --Jeff
>>
>>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by PeterKorman <ca...@eigenvision.com>.
On Sun, Oct 20, 2002 at 06:59:11PM -0700, J. Greenlees wrote:
> PeterKorman wrote:
> >On Sun, Oct 20, 2002 at 12:43:02PM -0700, J. Greenlees wrote:
> >
> >>actually, if you check the agreement with your isp, you will find a line
> >>that requires you to clean viruses out of your system, report the
> >>offending ip to their isp, they will have to clean it out.
> >>(I send 10 mb of access log to my isp, since a lot of their clients had
> >>both codered and nimda, they thanked me and the number of these hits has
> >>dropped drastically)
> >
> >
> >There is more than 1 ISP involved. A lot more. I'm up over 300 addresses
> >I'm blocking.
> >
> >Is there an easy way to determine the ISP contact to whom I must mail
> >the logs?
> >
> >host x.y.z.w
> >
> >will give me dns info but that means tracking down the responsible vendor.
> >I guess it makes sense to do it for the bandwidth emancipation and the
> >ISP coersion that might result. Thanks.
> >
> >JPK
> >
> actually, sending it to your isp should be enough, they should pass on
> the info to other isp's.
> if not, then just send the logs to the isp in question's tech support /
> help addy.
> most isp's actually appreciate having people with the skills and
> knowledge let them know, as I'm sure you can imagine, monitoring
> hundreds or thousands of ip's is a big job, where some things can
> easily be missed.
>
> they really enjoy getting the info when it is a hacking attempt, since
> they can do something to stop it before they become legally liable.
Cool.
Re: [users@httpd] Re: access log -- GET
/scripts/..%%35%63../winnt/system32
Posted by "J. Greenlees" <ja...@shaw.ca>.
PeterKorman wrote:
> On Sun, Oct 20, 2002 at 12:43:02PM -0700, J. Greenlees wrote:
>
>>actually, if you check the agreement with your isp, you will find a line
>>that requires you to clean viruses out of your system, report the
>>offending ip to their isp, they will have to clean it out.
>>(I send 10 mb of access log to my isp, since a lot of their clients had
>>both codered and nimda, they thanked me and the number of these hits has
>>dropped drastically)
>
>
> There is more than 1 ISP involved. A lot more. I'm up over 300 addresses
> I'm blocking.
>
> Is there an easy way to determine the ISP contact to whom I must mail
> the logs?
>
> host x.y.z.w
>
> will give me dns info but that means tracking down the responsible vendor.
> I guess it makes sense to do it for the bandwidth emancipation and the
> ISP coersion that might result. Thanks.
>
> JPK
>
actually, sending it to your isp should be enough, they should pass on
the info to other isp's.
if not, then just send the logs to the isp in question's tech support /
help addy.
most isp's actually appreciate having people with the skills and
knowledge let them know, as I'm sure you can imagine, monitoring
hundreds or thousands of ip's is a big job, where some things can
easily be missed.
they really enjoy getting the info when it is a hacking attempt, since
they can do something to stop it before they become legally liable.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by PeterKorman <ca...@eigenvision.com>.
On Sun, Oct 20, 2002 at 12:43:02PM -0700, J. Greenlees wrote:
> actually, if you check the agreement with your isp, you will find a line
> that requires you to clean viruses out of your system, report the
> offending ip to their isp, they will have to clean it out.
> (I send 10 mb of access log to my isp, since a lot of their clients had
> both codered and nimda, they thanked me and the number of these hits has
> dropped drastically)
There is more than 1 ISP involved. A lot more. I'm up over 300 addresses
I'm blocking.
Is there an easy way to determine the ISP contact to whom I must mail
the logs?
host x.y.z.w
will give me dns info but that means tracking down the responsible vendor.
I guess it makes sense to do it for the bandwidth emancipation and the
ISP coersion that might result. Thanks.
JPK
Re: [users@httpd] Re: access log -- GET
/scripts/..%%35%63../winnt/system32
Posted by "J. Greenlees" <ja...@shaw.ca>.
actually, if you check the agreement with your isp, you will find a line
that requires you to clean viruses out of your system, report the
offending ip to their isp, they will have to clean it out.
(I send 10 mb of access log to my isp, since a lot of their clients had
both codered and nimda, they thanked me and the number of these hits has
dropped drastically)
Lee Grey wrote:
> On the other hand, given the fact that so many users have dynamic IP
> addresses, you are really blocking a number that can't be guaranteed to
> match the machine it came from at that moment. The next day or two weeks
> later, you are probably still vulnerable to the same "attack" from the same
> infected machine, while having blocked access to your site by whatever
> innocent machine currently has that IP address.
>
> Just a thought.
>
> Best wishes,
> Lee Grey
> Grey Matter
> http://www.URLinOne.com
>
> -----Original Message-----
> From: Jeff Beard [mailto:jeff@cyberxape.com]
> Sent: Sunday, October 20, 2002 2:24 PM
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] Re: access log -- GET
> /scripts/..%%35%63../winnt/system32
>
>
>
>
> PeterKorman wrote:
> [...]
>
>
>>So my question is this: It this sledgehammer I'm using likely to hurt me?
>
>
> No but neither is the worm.
>
> --Jeff
>
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by PeterKorman <ca...@eigenvision.com>.
On Sun, Oct 20, 2002 at 09:55:02PM +0200, Chris wrote:
> rather than filtering the infected server's IP address, is it possible to
> filter its MAC address ?
>
>
> Chris.
I'm pretty sure the mac address goes away once the signature passes through
any router.
JPK
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by Anders Widman <an...@tnonline.net>.
> rather than filtering the infected server's IP address, is it possible to
> filter its MAC address ?
I would think not, as the mac-address is usually not routed onto the
net.
- Anders
> Chris.
>> -----Message d'origine-----
>> De : Lee Grey [mailto:leegrey@mindspring.com]
>> Envoye : dimanche 20 octobre 2002 20:32
>> A : users@httpd.apache.org
>> Objet : RE: [users@httpd] Re: access log -- GET
>> /scripts/..%%35%63../winnt/system32
>>
>>
>> On the other hand, given the fact that so many users have dynamic IP
>> addresses, you are really blocking a number that can't be guaranteed to
>> match the machine it came from at that moment. The next day or two weeks
>> later, you are probably still vulnerable to the same "attack"
>> from the same
>> infected machine, while having blocked access to your site by whatever
>> innocent machine currently has that IP address.
>>
>> Just a thought.
>>
>> Best wishes,
>> Lee Grey
>> Grey Matter
>> http://www.URLinOne.com
>>
>> -----Original Message-----
>> From: Jeff Beard [mailto:jeff@cyberxape.com]
>> Sent: Sunday, October 20, 2002 2:24 PM
>> To: users@httpd.apache.org
>> Subject: Re: [users@httpd] Re: access log -- GET
>> /scripts/..%%35%63../winnt/system32
>>
>>
>>
>>
>> PeterKorman wrote:
>> [...]
>>
>> > So my question is this: It this sledgehammer I'm using likely
>> to hurt me?
>>
>> No but neither is the worm.
>>
>> --Jeff
>>
>> --
>> Jeff Beard | Systems Architecture, Programming, Management
>> Contact | jeff at cyberxape dot com, 303.443.9339
>> Location | In front of the computer, Boulder, CO, USA
>>
>>
>> ---------------------------------------------------------------------
>> The official User-To-User support forum of the Apache HTTP Server Project.
>> See <URL:http://httpd.apache.org/userslist.html> for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> The official User-To-User support forum of the Apache HTTP Server Project.
>> See <URL:http://httpd.apache.org/userslist.html> for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by Chris <ap...@yoyogi.org>.
rather than filtering the infected server's IP address, is it possible to
filter its MAC address ?
Chris.
> -----Message d'origine-----
> De : Lee Grey [mailto:leegrey@mindspring.com]
> Envoye : dimanche 20 octobre 2002 20:32
> A : users@httpd.apache.org
> Objet : RE: [users@httpd] Re: access log -- GET
> /scripts/..%%35%63../winnt/system32
>
>
> On the other hand, given the fact that so many users have dynamic IP
> addresses, you are really blocking a number that can't be guaranteed to
> match the machine it came from at that moment. The next day or two weeks
> later, you are probably still vulnerable to the same "attack"
> from the same
> infected machine, while having blocked access to your site by whatever
> innocent machine currently has that IP address.
>
> Just a thought.
>
> Best wishes,
> Lee Grey
> Grey Matter
> http://www.URLinOne.com
>
> -----Original Message-----
> From: Jeff Beard [mailto:jeff@cyberxape.com]
> Sent: Sunday, October 20, 2002 2:24 PM
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] Re: access log -- GET
> /scripts/..%%35%63../winnt/system32
>
>
>
>
> PeterKorman wrote:
> [...]
>
> > So my question is this: It this sledgehammer I'm using likely
> to hurt me?
>
> No but neither is the worm.
>
> --Jeff
>
> --
> Jeff Beard | Systems Architecture, Programming, Management
> Contact | jeff at cyberxape dot com, 303.443.9339
> Location | In front of the computer, Boulder, CO, USA
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by Lee Grey <le...@mindspring.com>.
On the other hand, given the fact that so many users have dynamic IP
addresses, you are really blocking a number that can't be guaranteed to
match the machine it came from at that moment. The next day or two weeks
later, you are probably still vulnerable to the same "attack" from the same
infected machine, while having blocked access to your site by whatever
innocent machine currently has that IP address.
Just a thought.
Best wishes,
Lee Grey
Grey Matter
http://www.URLinOne.com
-----Original Message-----
From: Jeff Beard [mailto:jeff@cyberxape.com]
Sent: Sunday, October 20, 2002 2:24 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] Re: access log -- GET
/scripts/..%%35%63../winnt/system32
PeterKorman wrote:
[...]
> So my question is this: It this sledgehammer I'm using likely to hurt me?
No but neither is the worm.
--Jeff
--
Jeff Beard | Systems Architecture, Programming, Management
Contact | jeff at cyberxape dot com, 303.443.9339
Location | In front of the computer, Boulder, CO, USA
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by Jeff Beard <je...@cyberxape.com>.
PeterKorman wrote:
[...]
> So my question is this: It this sledgehammer I'm using likely to hurt me?
No but neither is the worm.
--Jeff
--
Jeff Beard | Systems Architecture, Programming, Management
Contact | jeff at cyberxape dot com, 303.443.9339
Location | In front of the computer, Boulder, CO, USA
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: access log -- GET /scripts/..%%35%63../winnt/system32
Posted by PeterKorman <ca...@eigenvision.com>.
On Fri, Apr 19, 2002 at 11:28:37AM -0400, David Kramlich wrote:
> Some firewalls and routers have routines to block the scans you see in your
> logs. Check with the manufacturer of your router or build a linux router or
> purchase a cheap cisco router w/12.1.2 IOS or higher to accomplish this.
> ----- Original Message -----
>
> > These are the telltale symptoms of someone on the internet who has the
> > NIMDA internet worm, which thankfully only affects microsoft IIS users.
> > though having countless log entries from this crap undoubtedly affects
> > all of us, unix users included.
> >
> > Odds are it is someone who uses the same ISP you do, but they either
> > have no clue it is on their systems, or have not yet run the latest
> > patches/virus scanners. Its not your problem, and its probably not
> > theirs either. I've had 170,000 log entries from NIMDA, and there are no
> > signs its even slowing down. :(
> >
> >
> > On Fri, 19 Apr 2002 10:43:04 +0200
> > "Robert Douglass" <r....@onlinehome.de> wrote:
> >
> > > Hello, I've been hosting a tiny website from my home for the past week,
> as a
> > > temporary project, and I found the following in my access log:
> > >
> > > "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> > > "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> > > "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > > "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > > "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> > > "GET
> /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > > HTTP/1.0" 404 329
> > > "GET
> /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > > HTTP/1.0" 404 329
> > > "GET
> > >
> /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/sy
> > > stem32/cmd.exe?/c+dir HTTP/1.0" 404 345
> > > "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > > "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > > "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > > "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > > "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400
> 295
> > > "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
> > > "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
> 312
> > > "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> > >
> > > Does anybody have an idea what someone was trying to accomplish with
> this,
> > > or if these requests may have originated from my ISP? Does anybody have
> any
> > > suggestions on how to implement some basic security (I've done nothing!)
> to
> > > protect myself? I'm using Apache 1.3.22. Thank you,
> > >
> > > Robert Douglass
I apologize for my late entry to this topic. Probably most of the readers have already
deleted the thread. I loaded up the raw mboxes from apache.org with the hope that
someone had discussed this. I'm glad I did.
I'm using a fairly harsh method of dealing with this. I'd like to get advice on
how advisable my approach is.
Every night I grep my log for this signature and for code red. I extract the
attacking IP address and feed that address back into IPTables. Any further
access from that machine to any ip port on my site is 'black holed'.
That is I completely deny any and all access from any site that has sent this
attack signature.
My reasoning is that if the attacking matching can be someones zombie I'd rather
not have him used as launch point for any attacks against my site.
I know the user I block is absent malice, but he is not absent carelessness.
I get attacks from somewhere between 1 and 5 ip addresses a day. Either this
signature or the code red one with all the NNNNNNNNNNNNNNNNN's in the url.
So my question is this: It this sledgehammer I'm using likely to hurt me?
Thanks.
Regards,
JPK
Re: access log
Posted by David Kramlich <da...@bellsouth.net>.
Some firewalls and routers have routines to block the scans you see in your
logs. Check with the manufacturer of your router or build a linux router or
purchase a cheap cisco router w/12.1.2 IOS or higher to accomplish this.
----- Original Message -----
From: "Mike Hodson" <mi...@mystica.cx>
To: <us...@httpd.apache.org>; <r....@onlinehome.de>
Sent: Friday, April 19, 2002 6:36 AM
Subject: Re: access log
> These are the telltale symptoms of someone on the internet who has the
> NIMDA internet worm, which thankfully only affects microsoft IIS users.
> though having countless log entries from this crap undoubtedly affects
> all of us, unix users included.
>
> Odds are it is someone who uses the same ISP you do, but they either
> have no clue it is on their systems, or have not yet run the latest
> patches/virus scanners. Its not your problem, and its probably not
> theirs either. I've had 170,000 log entries from NIMDA, and there are no
> signs its even slowing down. :(
>
>
> On Fri, 19 Apr 2002 10:43:04 +0200
> "Robert Douglass" <r....@onlinehome.de> wrote:
>
> > Hello, I've been hosting a tiny website from my home for the past week,
as a
> > temporary project, and I found the following in my access log:
> >
> > "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> > "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> > "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> > "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> > "GET
/_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > HTTP/1.0" 404 329
> > "GET
/_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> > HTTP/1.0" 404 329
> > "GET
> >
/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/sy
> > stem32/cmd.exe?/c+dir HTTP/1.0" 404 345
> > "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> > "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400
295
> > "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
> > "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
312
> > "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> >
> > Does anybody have an idea what someone was trying to accomplish with
this,
> > or if these requests may have originated from my ISP? Does anybody have
any
> > suggestions on how to implement some basic security (I've done nothing!)
to
> > protect myself? I'm using Apache 1.3.22. Thank you,
> >
> > Robert Douglass
> >
> >
> > ---------------------------------------------------------------------
> > The official User-To-User support forum of the Apache HTTP Server
Project.
> > See <URL:http://httpd.apache.org/userslist.html> for more info.
> > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> > For additional commands, e-mail: users-help@httpd.apache.org
>
> --
> Mike Hodson <mi...@mystica.cx>
> IRC: irc.mystica.cx #mystica or /msg me if im not actively talking.
> ICQ: 18145059
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Mike Hodson <mi...@mystica.cx>.
These are the telltale symptoms of someone on the internet who has the
NIMDA internet worm, which thankfully only affects microsoft IIS users.
though having countless log entries from this crap undoubtedly affects
all of us, unix users included.
Odds are it is someone who uses the same ISP you do, but they either
have no clue it is on their systems, or have not yet run the latest
patches/virus scanners. Its not your problem, and its probably not
theirs either. I've had 170,000 log entries from NIMDA, and there are no
signs its even slowing down. :(
On Fri, 19 Apr 2002 10:43:04 +0200
"Robert Douglass" <r....@onlinehome.de> wrote:
> Hello, I've been hosting a tiny website from my home for the past week, as a
> temporary project, and I found the following in my access log:
>
> "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 298
> "GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> "GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> HTTP/1.0" 404 329
> "GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir
> HTTP/1.0" 404 329
> "GET
> /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/sy
> stem32/cmd.exe?/c+dir HTTP/1.0" 404 345
> "GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 311
> "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
> "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 295
> "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
>
> Does anybody have an idea what someone was trying to accomplish with this,
> or if these requests may have originated from my ISP? Does anybody have any
> suggestions on how to implement some basic security (I've done nothing!) to
> protect myself? I'm using Apache 1.3.22. Thank you,
>
> Robert Douglass
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
--
Mike Hodson <mi...@mystica.cx>
IRC: irc.mystica.cx #mystica or /msg me if im not actively talking.
ICQ: 18145059
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Daniel Zwink <da...@zwink.de>.
Hi Robert,
> Daniel, could you recommend a firewall that is free and easy to install?
Sorry, but I don't know anything about firewalls.
Daniel
--
Als die Zeit erfüllt war, sandte Gott seinen Sohn,
geboren von einer Frau und unter das Gesetz getan,
damit er die, die unter dem Gesetz waren, erlöste,
damit wir die Kindschaft empfingen.
Galater 4,4-5
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Robert Douglass <r....@onlinehome.de>.
Daniel, could you recommend a firewall that is free and easy to install?
Right now, I've got a page with the ISP where my domain is registered, and
when someone visits it, they are redirected to my IP address, which I update
every day, since with DSL I can only be online 24 hours. Would a firewall
give me any protection but still allow these visitors access?
thanks!
-RD
----- Original Message -----
From: "Daniel Zwink" <da...@zwink.de>
To: "Apache Users" <us...@httpd.apache.org>
Sent: Friday, April 19, 2002 10:54 AM
Subject: Re: access log
> Hi Robert,
>
> > Hello, I've been hosting a tiny website from my home for the past week,
> > as a temporary project, and I found the following in my access log:
> >
> > "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> > "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> > [...]
> > "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404
312
> > "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
>
> *g* .. seems as if some viruses/worms try to connect to your server and
> watch out for exploits in IIS from Microsoft - IMHO not really dangerous
> if you run apache :-).
> Unfortunately I don't know if you can protect your server from such
> connections through a forewall.
>
>
> Daniel
> --
> Als die Zeit erfüllt war, sandte Gott seinen Sohn,
> geboren von einer Frau und unter das Gesetz getan,
> damit er die, die unter dem Gesetz waren, erlöste,
> damit wir die Kindschaft empfingen.
> Galater 4,4-5
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Daniel Zwink <da...@zwink.de>.
Hi Robert,
> Hello, I've been hosting a tiny website from my home for the past week,
> as a temporary project, and I found the following in my access log:
>
> "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
> "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 288
> [...]
> "GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
> "GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 404 312
*g* .. seems as if some viruses/worms try to connect to your server and
watch out for exploits in IIS from Microsoft - IMHO not really dangerous
if you run apache :-).
Unfortunately I don't know if you can protect your server from such
connections through a forewall.
Daniel
--
Als die Zeit erfüllt war, sandte Gott seinen Sohn,
geboren von einer Frau und unter das Gesetz getan,
damit er die, die unter dem Gesetz waren, erlöste,
damit wir die Kindschaft empfingen.
Galater 4,4-5
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: access log
Posted by Robert Douglass <r....@onlinehome.de>.
Arvid, thank you. Where do I find this default virtual entry? Is it in
httpd.conf?
-RD
----- Original Message -----
From: "Johansen Arvid S." <sn...@snille.com>
To: <us...@httpd.apache.org>
Sent: Friday, April 19, 2002 12:46 PM
Subject: SV: access log
> Robert Douglass wrote on 19. april 2002 10:43:
>
> > Hello, I've been hosting a tiny website from my home for the past
> week, as
> > a temporary project, and I found the following in my access log:
> > "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
>
> [some deleted]
>
> I also run several web sites (virtual hosts) on my home machine and I
> solved this by disabling the default entry (first virtual entry called
> test.domain.com) - the one that answers when the IP address is used.
>
> So now I get "access denied by server configuration" (or something like
> that) in the error log when I get those attacks. The only real response
> is from Code Red ("client sent malformed header") - I think Apache
> should deny those too....
>
> - Arvid
>
> (Oslo, Norway)
>
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
SV: access log
Posted by "Johansen Arvid S." <sn...@snille.com>.
Robert Douglass wrote on 19. april 2002 10:43:
> Hello, I've been hosting a tiny website from my home for the past
week, as
> a temporary project, and I found the following in my access log:
> "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 290
[some deleted]
I also run several web sites (virtual hosts) on my home machine and I
solved this by disabling the default entry (first virtual entry called
test.domain.com) - the one that answers when the IP address is used.
So now I get "access denied by server configuration" (or something like
that) in the error log when I get those attacks. The only real response
is from Code Red ("client sent malformed header") - I think Apache
should deny those too....
- Arvid
(Oslo, Norway)
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org