Re: Detecting hacking attempts - what should browsers *not* request?
From: Keg (rhugga_at_yahoo.com)
Date: 06/07/04
- Next message: Krishna Tyner: "Debugging and Profiling Your Code Webinar June 15th"
- Previous message: Keg: "Any Syslog-NG Type Packages Out There"
- Maybe in reply to: Colin McKinnon: "Re: Detecting hacking attempts - what should browsers *not* request?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Jun 2004 06:13:15 -0700
see_my_signature_for_my_real_address@hotmail.com (Dr. David Kirkby) wrote in message news:<c99d2c79.0405301242.483ec2ff@posting.google.com>...
> I have a Sun workstation running Solaris 9 with an Apache 1.3.27 web
> server (with Sun pathces applied). The web server only serves static
> pages - there is no dynamic content at all. No php, javascript etc.
>
> Looking at the error log (/var/log/apache/error_log) I can see some
> obvious attempts to hack the machine. People looking for cmd.exe,
> root.exe, and various dll's. I'd like to dymamically block the IP's of
> such attempts in the firewall, so any attempt to hack will result in
> the IP being closed within a second or two. Clearly I need to
> determine what is a hacking attempt from what is a mis-configured
> browser or similar.
>
> Although the Solaris installation of Apache installed a 'scripts'
> directory, I don't want anything to run from there, so have made the
> permissions such that nothing can be read.
>
> # ls -ld /var/apache/htdocs/scripts
> d--------- 4 root bin 512 Dec 16 13:43
> /var/apache/htdocs/scripts
>
>
> Attempts to access a 'scripts' directory, as in the entries below, are
> often recorded in the error_log. Given all the web pages are static,
> can I assume *any* record of 'scripts' in the error_log is a sign of
> some sort of undesirable behaviour?
>
> [Sun May 23 09:07:01 2004] [crit] [client 64.210.196.197]
> (13)Permission denied: /var/apache/htdocs/scripts/.htaccess
> pcfg_openfile: unable to check htaccess file, ensure it is readable
> [Tue May 25 06:49:14 2004] [crit] [client 63.148.99.237]
> (13)Permission denied: /var/apache/htdocs/scripts/.htaccess
> pcfg_openfile: unable to check htaccess file, ensure it is readable
>
> So far the firewall is configured to immediatly block any IP that
> produces any of the following lines in the Apache error_log file.
>
> root.exe
> URI
> cmd.exe
> dll
> asp
> default.ida
> _mem_bin
> _vti_bin
> msadc
> x01
> %5c
> NULL.printer
> winnt
> MSOffice
>
> These seem to be the ones I notice. Any comments on this list ??
>
> I am of course running on Solaris, not Windoze, but I guess if someone
> wants to try hacking Windoze boxes, I'd like to block them anyway.
>
> I'm sure someone is going to say my method of dynamically adding
> firwall rules to block IP's can be used as a DOS attack. I appreciate
> this might be so, but I feel its a risk worth taking.
These are merely infected Windoze hosts out there somewhere scanning
for more hops. These entries are now common place in web server log
files. The underlying server is irrelevant, any IP listener that
responds to HTTP 1.0/1.1 requests will be susceptible to these probs.
Just look at it for what it really is, an invalid URL. You have no
control over what URL's people request from your server, so why even
worry about it.
The virus http request might have we have been someone manually typing
in http://sunsolve.sun.com/cmd.exe?somearg=XXXXXXX, it will get an
error 404 and you have no worries. (I would only worry about if start
seeing thousands and thousands of requests)
In short, there is nothing you can do anyway except start collecting
the source IP's from each instance in the log and doing something with
that. (block at firewall, block with a router ACL, block with apache
itself, etc... You have to remember that the admin at the source site
might not even know one or more of his machines are infected. (you
know, he is running windoze remember?)
As long as your web server is not running as root you will be fine. If
you are only serving up static content, make all files under your
document root owned by a user OTHER than the same user/group apache is
running as. Basically if apache is running under the user/group of
apache/apache, make sure that there are no files under document_root
writable by apache/apache. (and likewise, any files you don't want
public make sure that apache/apache cannot even read those files)
Also, I would not try and of these newer 3rd party servers until they
have prooven the test of time, as apache surely has.
-CC
- Next message: Krishna Tyner: "Debugging and Profiling Your Code Webinar June 15th"
- Previous message: Keg: "Any Syslog-NG Type Packages Out There"
- Maybe in reply to: Colin McKinnon: "Re: Detecting hacking attempts - what should browsers *not* request?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
