Hello having a problem with an ip getting past my htaccess ban
ban works for me whe i test it out here is what im using in my ht access

<Limit GET PUT POST>
order allow,deny
allow from all
deny from 216.248.151.111 212.234.180.3 208.237.123.185 62.253.64.5 213.96.193.175 192.139.120.93 217.80.79.68 193.251.190.3 24.1.136.88 4.54.62.98 24.131.151.56 209.88.158.178 207.168.187.83
</Limit>


here is server log today that again for 3rd day in a row shows that ip as getting in.

[Fri Nov 9 22:23:14 2001] [error] [client 216.248.151.111] File does not exist: /www/htdocs/scripts/..Á../winnt/system32/cmd.exe
[Fri Nov 9 22:23:16 2001] [error] [client 216.248.151.111] File does not exist: /www/htdocs/scripts/..À¯../winnt/system32/cmd.exe
[Fri Nov 9 22:23:19 2001] [error] [client 216.248.151.111] File does not exist: /www/htdocs/scripts/..Áœ../winnt/system32/cmd.exe
[Fri Nov 9 22:23:25 2001] [error] [client 216.248.151.111] File does not exist: /www/htdocs/scripts/..%5c../winnt/system32/cmd.exe
[Fri Nov 9 22:23:26 2001] [error] [client 216.248.151.111] File does not exist: /www/htdocs/scripts/..%2f../winnt/system32/cmd.exe

i have it in all foldres of my site and wondering how this ip is getting past it ?

any ideas ?

Looks like a Worm is scanning your server for the WinServer exploit.

It is getting past your .htaccess restriction because those directories do not exist on your server. You have to remember the order in which Apache processes HTTP requests. Before processing an .htaccess file, it is going to look to see if a file is there or not. If the file is not there, it is going to direct the requestor to an error page, which is most likely outside of the root directory for your site.

If you are running Linux, the best way to avoid the scanners is to put the IP addresses in your hosts.deny file. The hosts.deny file is processed before Apache is called, so you will no longer see those requests.

You could probably do something like this:

# /etc/hosts.deny
#
# Stop scanners
httpd: 216.248.151.111, 212.234.180.3, 208.237.123.185, 62.253.64.5, 213.96.193.175, 192.139.120.93, 217.80.79.68, 193.251.190.3, 24.1.136.88, 4.54.62.98, 24.131.151.56, 209.88.158.178, 207.168.187.83

Or, if you really don't like any of those hosts:

# /etc/hosts.deny
#
# Stop scanners
ALL: 216.248.151.111, 212.234.180.3, 208.237.123.185, 62.253.64.5, 213.96.193.175, 192.139.120.93, 217.80.79.68, 193.251.190.3,24.1.136.88, 4.54.62.98, 24.131.151.56, 209.88.158.178, 207.168.187.83

After you edit the file, don't forget to restart inetd.

Posted earlier this week in Bugtraq (http://www.securityfocus.com/archive/1/225199).


You can put this in your httpd.conf


# Flag requests for URIs containing known strings from
# Nimda-like worms (including Code Red, sadmind/IIS)
# Note that the patterns below are regexes; escape your dots!

SetEnvIf Request_URI "/winnt/system32/cmd\.exe" nimda
SetEnvIf Request_URI "/scripts/root\.exe" nimda
SetEnvIf Request_URI "/MSADC/root\.exe" nimda
SetEnvIf Request_URI "/\.\." nimda
SetEnvIf Request_URI "\.\./" nimda

# Block attackers who send the patterns above (and get a 400 or 404 response)
# via the routing table. It's more efficient to firewall (the command
# will vary depending upon the firewall in use) or use SSH to add rules to
# an upstream firewall to block the attacker. If several commands must
# be executed, it may be best to invoke a script rather than doing
# all the work from within httpd.conf.

CustomLog "|exec sh" "route -nq add -host %400,404a 127.0.0.1 -blackhole"
env=nimda



It works but I don't use it. But you can easily lock yourself out.

tnx for the info im adding that right now



actually i created a script folder and a couple others with just the htaccess in them for that pupose

Apache has nothing to do with hosts.deny when it is ran as a standalone server, which is the usual configuration. Hosts.deny only controls those things in inetd.


Better install IPchains/PMFirewall and just block all traffic from that site.

Originally posted by huck
Apache has nothing to do with hosts.deny when it is ran as a standalone server, which is the usual configuration. Hosts.deny only controls those things in inetd.


Right, but the hosts.deny file is run at the kernel level, which means it would take effect even before Apache came into the picture. So, you would be able to deny the IPs at the kernel level.

Originally posted by taz0
Posted earlier this week in Bugtraq (http://www.securityfocus.com/archive/1/225199).

Did you also ready the follow-up to that message how a malicious user can effectively block anyone he wants from accessing that web server? After I read that follow-up I didn't read that thread anymore, so I don't know if anyone countered it.

uuallan -- RTFM
http://etp1.ocs.lsu.edu/doc/tcp_wrappers-7.6

or for an intro

http://www.sans.org/infosecFAQ/unix/TCP_wrappers2.htm

To re-iterate
In general, TCP Wrappers only influence programs started from the inetd super daemon (or directly if you've replaced files with tcpd).

from the docs

Requirements are that network daemons are spawned by a super server such as the inetd; a 4.3BSD-style socket programming interface and/or System V.4-style TLI programming interface; and the availability of a syslog(3) library and of a syslogd(8) daemon. The wrappers should run without modification on any system that satisfies these requirements.


Many people misunderstand what TCP Wrappers do and do not protect. If you use inetd, then look at the conf file -- those are the only services that TCP Wrappers will protect with most major linux distributions. Sure, there are probably exceptions -- with linux there always are.

Apache, when configured as a standalone server, does not use tcpd -- it is its own daemon and makes it own port open to the outside world.

To check this go put your IP in hosts.deny -- You will notice sendmail and apache still work fine. This is because they do not use inetd by default.

You can run apache via inetd, but this is generally not the case.

:mad: Editorial Rant Below
This is another case of YDNKWYTA (you do no know what you're talking about). Please do not post incorrect information on the boards. If you not sure about something, make your uncertainty clear. I would hate to see someone get their web server hacked after they put the offending IP into hosts.deny in an effort to block the attack. Also note that this rant, which will probably get axed by the moderator, is not directed at any one individual. There is a lot of mis-information on these and other forums -- heck I've probably even contributed to it. Please follow up all suggestions/comments by RTFM.

Originally posted by allera

Did you also ready the follow-up to that message how a malicious user can effectively block anyone he wants from accessing that web server? After I read that follow-up I didn't read that thread anymore, so I don't know if anyone countered it.

That's why I don't use it. Especially when you don't have physical access to the server. I don't mind the CodeRed probes.

Originally posted by huck
uuallan -- RTFM
http://etp1.ocs.lsu.edu/doc/tcp_wrappers-7.6

or for an intro

http://www.sans.org/infosecFAQ/unix/TCP_wrappers2.htm


Thanks for the pointer, I did not realize that about TCP Wrappers. I appreciate the information.

Editorial Rant

These forums, as with most places are a tool for learning. Sometimes mis-information is shared, but almost always the intentions are good. When bad information is spotted, it is best to point it out in a nice, respectful, friendly manner. After all, there are a lot of people on this board who know a lot of things, but even the best people occasionally make a mistake.

Sorry if the RTFM comments offended. I just see a lot of misinformation on the forum and wanted to make a point that if you use these board -- Do your homework. Follow up any comments with a search to get information from a reliable source -- which is probably not me. The expertise on these boards range from newbie to gray, old wisened veteran.


To secure your box, check into firewalling -- this is a good first line of defense suitable for servers that do not have sensitive info. or are not mission critical. Use TCP wrappers for backup purposes.