![]() |
worrying Apache logs
Going through my logs the other day I noticed this sequence:
Code:
217.209.79.25 - - [01/Nov/2003:10:59:12 +0000] "CONNECT 1.3.3.7:1337 HTTP/1.0" 405 299Info: G4 400, OS 10.2.8 Apache 1.3.27, PHP 4.3.3 with Zend 1.3.0, PHPBB 2.0.6. NAT Router port forwarding (80) |
I'm far from being an expert on this, but it seems that the CONNECT entries are to do with attempts to use your server as a proxy. It would seem from the 200 code on the last one that it succeeded somehow.
Do you have mod_proxy enabled ? (http://httpd.apache.org/docs/mod/mod_proxy.html) If you aren't providing proxy services, you probably should disable it. And you might consider explicitly disallowing CONNECT messages via: <Limit CONNECT> Deny from all </Limit> |
Hi hayne,
mod_proxy is totally commented out in httpd.conf so I don't think that's it. more info on where to put the <Limit CONNECT> would be handy though if you have a mo. I've also turned on domain lookups so I'll have a better idea of where this is coming from (IP #'s seem to be dynamic). I've found reports (on www), of 1.3.3.7:1337 in logs since june, nobody seems to know for sure exactly what is being done, no info at all on the AV sites, CERT has some references to Code Red, most people are putting it down to mischievous 'leet' script kiddies. be nice to know for sure though. thanks, dD |
Do you have your firewall turned on?
|
1.3.3.7:1337
l.E.E.T:lEET 4nn0y1ng 5cr1p7 k1dd135 |
Quote:
|
Quote:
|
Quote:
I would probably put it into Section 2 of the file (search for "Section") And I don't think that the firewall is going to help here since I believe these requests are coming in on port 80 - otherwise they wouldn't be getting to Apache. |
0wn3d?
I've been sorting through the system.logs, there is a 5 hour 45mins gap in the logs at the time the last CONNECT was successful,
and yes the machine was on. Code:
Nov 10 03:15:04 G4Mac syslogd: restartIf anyone can think of anything else to check please let me know... Added Limit CONNECT deny to all to httpd.conf dD /edit: fold -mt |
Quote:
No suspicious restarts of httpd? I would also start looking into: 1) logs for Apache, printer sharing, iChat, pop mail, smtp & iTunes 2) recently edited files - (although a thorough cracker will reset them to whatever they were, this guy may not have been completely thorough if he left that entry in the httpd log) One way to do this is to: Code:
$ sudo -s |
Quote:
Please tell me if I'm misinterpreting the log entries -- I want to learn this stuff, but haven't really had a chance. |
Hmm, all my system logs have a big gap at this time, just after the daily script runs (3:15), I've looked through it (the daily), and there doesn't appear to be anything untoward.
Could somebody else check their system logs for similar periods of inactivity? from what I've learnt the only reason for sending this malformed CONNECT seems to be for spammers looking for open proxies, it also seems that Apache won't return a 200 unless mod_proxy is running, I've since modified my httpd.conf so it's difficult to tell if it's been tampered with but as far as I know mod_proxy has always been commented out. Finder searches show no files modified during the period, Find from the terminal search listed a crap load of files but nothing that stood out as unusual. No unusual httpd restarts in the logs. Port scanned the rig and 1337 is closed, its popularly used for P2P app Waste, QuickDNS and a lot of PHP Socket tutorials also use this port. Most of the (reserved IP btw), CONNECT 1.3.3.7:1337 attempts seem to have started after previous CONNECT's to port 25 stopped, so the thinking is that these are from compromised machines looking for OP's. the small number of hits worldwide suggests that perhaps just 1 scummer is behind it. Anyway Port Forwarding is disabled on the router for now. Does anyone know how I can recreate this CONNECT from another machine on the network to see what's in the 20K returned? Appreciate the help everybody, thanks dD |
D'oh, just re-read your post, never mind....
|
Stetner, I've never had cause to look through the system logs before so I don't know if this is usual behaviour, I should also add that they only go back a week whereas the first (admitably 405'ed), CONNECT was from the 1st, my gut feeling was that this is a long time for a daily, and that *something* should have left a message during this period especially with the webserver running... shouldn't the daily have left a message when complete?
If mod_proxy running is the only way Apache could have returned a 200 to the CONNECT then something is very wrong on this system. dD |
I was going to say look into your old logs in that previous post, but you obviously have... I guess that is a good reason to have /var/logs backed up (incrementally). I have a bunch of cron jobs including this one:
Code:
*/10 * * * * /usr/libexec/atrunCode:
Nov 17 03:15:04 strider syslogd: restartCheck out the 'Console' app. In Panther, if you click on the 'Logs' icon in the upper left, it easily lets you checkout a bunch of logs. 'daily' has its own log under /var/logs/ I actually have a cron job that greps stuff out of the logs for things I have holes in my router for (I don't open port 80), so for ssh, I have a cron job that greps out all ssh activity and mails it to me. Most days it is a quick scan and delete, but occasionally I get a connect attempt from somewhere which I report to abuse@wherever after checking whois to find out the service provider. I did have some continuous attempts coming from China somewhere, so I just blocked the whole range that that ISP owned on my router, I only know a few people in China, and they know how to get in touch with me if they need to. :) You can also edit /etc/daily Code:
$ ll /etc/dailyIf I were you, I would be watching my system like a hawk occasionaly (or regularly) do some Code:
$ netstat -a | egrep 'LISTEN|ESTA' |
Quote:
I did run through the daily logs, ages ago I set up the crontab to mail me them, but it got broken after an upgrade so daily.out must have over 300 entries by now... every one of them undated... I've run the netstat | grep a few times: Code:
tcp4 0 0 *.http *.* LISTENAbout time I got hold of a copy of Panther so I guess a clean install on a new disk will make me sleep easy, do you know if Apache is still version 1.3.27 in 10.3? Don't suppose you had any thoughts on how to send a CONNECT to Apache? dD |
srvloc -The Service Location Protocol is a decentralized, lightweight, scalable and extensible protocol for service discovery within a site.
Rendevous stuff??? ipp - IP printing (?) Panter: $ httpd -V Server version: Apache/1.3.28 (Darwin) No clue on sending a CONNECT.... |
I have a Virtual host set up on 9000, Its advertised through Rendezvous:
Code:
<VirtualHost *:9000> |
That just means there is no info or a wildcard there at the moment for host.port. See 'man netstat':
Code:
The default display, for active sockets, shows the local and remote |
Quote:
That's your CUPS daemon. The OS X firewall should prevent connections from other hosts. Breen |
Just a thought
Hi all.
I registered basically just to pass this info on, so I will probably only say it once, which is why I will try and cover it well. The problem you are experiencing is actually fairly common. In this day and age the average web server gets hit around 10 times daily with the new "0-dayZ IIS exploit OMG". That being said, my own servers get hit quite a lot. A little while ago, this was bugging me so I decided to look into the logs and whatnot. What do I find? The standard SEARCH testing for the popular IIS exploit, and proxy requests. Lots of them. And to be honest, I really didn't care. They were all getting bumped off. Except the last one. (Note last one, it's actually significant.) The last request got a 200. (To go to ebay.com I might add... Maybe somebody trying to 419 or whatnot?) That freaked me out a little. Ethereal poped open, so did my browser, and I did a quick system search for recently modified files. (Anything that was modified about 5 minutes before the proxy request got a 200.) I didn't catch anyone in the act with Ethereal, and as for the web, the only site with some decent information was this one. However, it was lacking something, an answer. The answer is actually very simple. If you look at what you get when you do a timestamp search, you get a long list of files, usually ending with system files. Not the kind of stuff you would want to mess with right? Wrong. If you look closely, you'll see /etc/hosts.deny is in that list. Why? Think about it... Isn't it weird that file got modified at all? Well, that got my attention, but a quick cat /etc/hosts.deny answered ALL my questions. Correlate the /etc/hosts.deny with your apache access_log and you find something very interesting. The IP that got the 200 to the proxy request is also in the hosts.deny file. Why could that be? Well, the firewall blocked his IP out, that's why. It's really that simple. Think about it for a second. When you try and access a web server that is "Forbidden", does it say "Page not found" or "You are forbidden access to this page!"? It says forbidden, obviously. Well, if you SEE the forbidden error page, then the server is telling you something. Hence a 200. Except the 200 brings you nowhere. Now, the other possibility is that the firewall simply blocked the IP using hosts.deny and is sending them 200-Ok to any and all requests, but no data on the wire. Either way, you have nothing to fear. Unless I'm wrong that is, but even if I am wrong, the IP is STILL on the deny list, so they can't even talk to your computer. Problem solved. And it solved itself like a grown-up, all by itself. I'd like to see Microsoft make it's software do this. :) BTW: IANAMU - I am not a mac user. However, I am a linux user that knows a little bit about security. I hope this helped dropped some people's blood pressure. There shouldn't be much to worry about really. HOWEVER, please ALWAYS keep an eye on your logs if you're running a server. Not only will you be doing yourself a favor, but you'll be helping the entire net get rid of these kids. And as far as I'm concerned, you probably should send a copy of your logs to your service provider, telling them about who is trying to use what exploit on you and from what IP. They would certainly appreciate being able to nail a few kiddies. (Although most of them use proxies, proxies have logs which can be inspected to trace back to the source.) Whatever option you chose, be safe, check your logs every once in a while and if something doesn't look quite right, it's probably not so check it out. PS: For anyone who even wants to start saying that macs are better or pcs are better, the fact of the matter is I don't care which is better. The OS is only as good the person behind the keyboard. If you're a moron and THINK that some OS is better than another without actually taking the time to learn how to use it well, then you DESERVE to be flamed. |
Hmm, Interesting but I would have expected Apache to send a 403 for forbidden, and if that IP is blocked by your firewall, Apache should not have even got a request, as for the get "somewhere" 200 logs I discovered this was actually default behaviour, Apache just assumes that 'ebay.com' is a domain pointed to your server so sends the default page. Explanation from the Apache docs below:
Why do I see requests for other sites appearing in my log files? A an access_log entry showing this situation could look like this: 63.251.56.142 - - [25/Jul/2002:12:48:04 -0700] "GET http://www.yahoo.com/ HTTP/1.0" 200 1456 The question is: why did a request for www.yahoo.com come to your server instead of Yahoo's server? And why does the response have a status code of 200 (success)? This is usually the result of malicious clients trying to exploit open proxy servers to access a website without revealing their true location. If you find entries like this in your log, the first thing to do is to make sure you have properly configured your server not to proxy for unknown clients. If you don't need to provide a proxy server at all, you should simply assure that the ProxyRequests directive is not set on. If you do need to run a proxy server, then you must ensure that you secure your server properly so that only authorized clients can use it. If your server is configured properly, then the attempt to proxy through your server will fail. If you see a status code of 404 (file not found) in the log, then you know that the request failed. If you see a status code of 200 (success), that does not necessarily mean that the attempt to proxy succeeded. RFC2616 section 5.1.2 mandates that Apache must accept requests with absolute URLs in the request-URI, even for non-proxy requests. Since Apache has no way to know all the different names that your server may be known under, it cannot simply reject hostnames it does not recognize. Instead, it will serve requests for unknown sites locally by stripping off the hostname and using the default server or virtual host. Therefore you can compare the size of the file (1456 in the above example) to the size of the corresponding file in your default server. If they are the same, then the proxy attempt failed, since a document from your server was delivered, not a document from www.yahoo.com. If you wish to prevent this type of request entirely, then you need to let Apache know what hostnames to accept and what hostnames to reject. You do this by configuring name-virtual hosts, where the first listed host is the default host that will catch and reject unknown hostnames. For example: NameVirtualHost * <VirtualHost *> ServerName default.only <Location /> Order allow,deny Deny from all </Location> </VirtualHost> <VirtualHost *> ServerName realhost1.example.com ServerAlias alias1.example.com alias2.example.com DocumentRoot /path/to/site1 </VirtualHost> |
| All times are GMT -5. The time now is 10:43 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.