Depends on what the preventing is in your terms.

Practically spoken it is already prevented, as you can see your apache replies a bad request error (400), which means that the request did not succeeded, there's no better way to prevent this.

If you have a dynamic ip address, it is likely that someone before you got the ip address were using torrent, and this is a kind of heritage, which will go away with time.

If you have a dynamic ip address, it is likely that someone before you got the ip address were using torrent, and this is a kind of heritage, which will go away with time.

Thats one sigh of relief - didnt think of that one! Yes, my ISP gives dynamic IP.

1. But ... my LAN IP is static (obviously) and I was thinking if its possible for someone to sent a request to 10.12.xx.xx? Im a home user - not in a network.
Changes are less - but such a thing possible in sockets?
On a 256kbps, these are like DoS attacks - my speed has gone down.

2. Some of the requests are getting 200 from my Apache!

64.**.57.129 - - [08/Jan/2008:18:01:24 +0530] "Z" 200 -
201.**.54.97 - - [08/Jan/2008:18:02:53 +0530] "v\xca\x82\x1ea\x83\xbd\xf5p\xd7\xf3\x8c\xab\xbe\xa7\xf0\xd2\x12" 200 -

How on earth are these 2 being sent 200!
I dont have folders named v or Z.

[edited by: jdMorgan at 7:50 pm (utc) on Jan. 8, 2008]
[edit reason] Obscured IP addresses [/edit]

Nobody from the internet can send requests to your lan ip address, unless they have a lan ip address too (from the same subnet), and they are on the same physical network. For example your neighbor could do that if you use an unsecured WiFi access point.

Not sure why those two requests received a 200 status code, but in my opinion, you can safely ignore such a request, mainly because they are not standard http request¹, so there's no harm they can do. A good place to look for more details about similar problems/requests is the error log of apache, which ususaly created in the same folder as the access log.

(1) A valid http request is always like this:

<method> <URL> <http_version>(CRLF) 
<header 1>(CRLF) 
<header 2>(CRLF) 
<header n>(CRLF) 
(CRLF)

The first line is the request itself, it describes the method used (GET, POST, HEAD,...), followed by the URL (/your_path/your_file), closed by the http protocol version, which is always like this (in the case of the 1.1 version which is the latest sine long years): HTTP/1.1. The first line (request) is mandatory, it must always be included using this syntax, but the headers are optional (except the "Host" header which is also mandatory in http 1.1). The last CRLF is also mandatory, that indicates the end of the headers (or the request if there's no content).

So the "GET /asd/asd HTTP/1.1" is a valid http request, but the "/asd/asd" or the "\x13BitTorrent protocol" is not.

What I wanted to say is, when you see lines in your apache access log which does not start with GET POST or any of the other allowed methods, then you can safely ignore that line, in a way or another, but it was refused by your apache.

If you want to read more about the http protocol, I'd suggest to check the corresponding RFC [rfc-editor.org].

But quite often I do get "OPTIONS / HTTP/1.1" from a LAN IP. (This would mean that that PC is using the same ISP as mine in my neighbourhood)

10.12.#*$!.133 - - [09/Jan/2008:11:28:37 +0530] "OPTIONS / HTTP/1.1" 200 -

And most of the time its from the same IP.
Is it possible that, that IP's PC is having a bitTorrent s/w which gets a 200 response after requesting and OPTIONS and therefore flags my internet IP as a bitTorrent IP?

This would indicate a serious problem with your router configuration. Addresses in the 192.168.. 127.0.. and 10... range (as well as others) are defined as "non-routable" and cannot pass through a router unless a "hole" is opened to allow this to happen.

I suspect that you're not clear on the difference between your WAN address (assigned by your ISP) and your LAN addresses, assigned by you (or by your router if you use DHCP). You might want to consider doing a bit of network configuration research to get comfortable with how this works.

Jim