Detecting hacking attempts - what should browsers *not* request?

Stefaan A Eeckels <tengo@DELETEMEecc.lu> wrote in message news:<20040531112257.71183c0a.tengo@DELETEMEecc.lu >...
> On 30 May 2004 13:42:59 -0700
> see_my_signature_for_my_real_address@hotmail.com (Dr. David Kirkby) wrote:
>
> > 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.
>
> If that's the case, use Dan Bernstein's publicfile
> <http://cr.yp.to/publicfile.html>, which is the most
> secure HTTP/FTP server you can find to serve static
> pages.
>
> Take care,
>
> --
> Stefaan


Thanks, but later I might add some dynamic content, so I'm not keen to
swap from Apache (which I spent some time learning to configure) to
something else which I don't know. However, I do accept that something
simpler can be made more secure.

I've got /var/apache (where apache files reside) on a read-only file
system. /usr is mounted read-only too. I know it's possible to set up
Apache in a chrooted enviroment, but I've not looked at that
possibility.

I realise (although my original post was admittidily not clear on
this) that the attacks I showed were aimed at Windoze machines, not
Solaris ones. But my feeling is that if someone is trying to attack a
Windoze machine, I don't want them visiting my IP address. They might
have attacks for UNIX ones too. So I'd rather just block their IP.

I made a script that also checks for attempts to telnet to the machine
and just blocks their IP address. I don't see any good reason someone
should want to telnet to my box, although one might argue it can be
used in some circumstances as a test.

I have a hardware firewall, which is configured to block most things,
but I can't avoid leaving port 80 open obviously, and port 22 is open
from a few IP addresses only. I've now opened port 23 from the
hardware firewall to allow that through to the Sun. If anyone tries to
access port 23, their IP will be blocked on all ports, including that
to the webserver. So any attempt to telnet to the box will immediatly
put a stop to any attacks against apache.

Whether or not blocking IP addresses that appear to be doing something
you don't like is of course debatable. I'm sure if someone can spoof
their IP address, they could create a DOS attack in this way.

"Dr. David Kirkby" <see_my_signature_for_my_real_address@hotmail.co m> wrote
in message news:c99d2c79.0405311519.4b6c19c@posting.google.co m...
>
> Whether or not blocking IP addresses that appear to be doing something
> you don't like is of course debatable. I'm sure if someone can spoof
> their IP address, they could create a DOS attack in this way.

Blocking IP addresses may not be a solution to your issue.

Most individuals who would be moubnt ing attacks have 'temporary' IP
addresses, in that they are on dhcp from their provider. Therefore, the same
individual could be back next week, using the same 'robot' from a different
address. Also, you could ebd up with a very long 'deny' list, and end up
locking out people who should have access as they rotate through available
IP addresses.

If your material is very 'restricted' you may want to consider using the
'allow from' directive instead. As I see it, if you want to put the material
out there for the world to see, you run the risk being probed for
weaknesses.

You also may want to consider if it is the system you want to protect, or
the data you are serving. There would be different approaches depending on
which it is.

Stuart

"Stuart Miller" <stuart_miller@shaw.ca> wrote in message news:<5ZPuc.636250$Ig.470757@pd7tw2no>...
> "Dr. David Kirkby" <see_my_signature_for_my_real_address@hotmail.co m> wrote
> in message news:c99d2c79.0405311519.4b6c19c@posting.google.co m...
> >
> > Whether or not blocking IP addresses that appear to be doing something
> > you don't like is of course debatable. I'm sure if someone can spoof
> > their IP address, they could create a DOS attack in this way.
>
> Blocking IP addresses may not be a solution to your issue.
>
> Most individuals who would be moubnt ing attacks have 'temporary' IP
> addresses, in that they are on dhcp from their provider. Therefore, the same
> individual could be back next week, using the same 'robot' from a different
> address. Also, you could ebd up with a very long 'deny' list, and end up
> locking out people who should have access as they rotate through available
> IP addresses.
>
> If your material is very 'restricted' you may want to consider using the
> 'allow from' directive instead. As I see it, if you want to put the material
> out there for the world to see, you run the risk being probed for
> weaknesses.
>
> You also may want to consider if it is the system you want to protect, or
> the data you are serving. There would be different approaches depending on
> which it is.
>
> Stuart


To bock this kind of ULR you need to install Content inspection
firewall software. Examine incoming URL request blocks if it is not a
valid http address.

To stop the log message you can create a dummy file with that name (
root.exe, cmd.exe …etc)

-Sundaram