The macosxhints Forums

The macosxhints Forums (http://hintsforums.macworld.com/index.php)
-   UNIX - Newcomers (http://hintsforums.macworld.com/forumdisplay.php?f=15)
-   -   worrying Apache logs (http://hintsforums.macworld.com/showthread.php?t=17462)

darndog 11-14-2003 08:41 PM

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 299
200.214.190.60 - - [03/Nov/2003:11:14:08 +0000] "CONNECT 1.3.3.7:1337 HTTP/1.0" 405 299
203.250.72.26 - - [10/Nov/2003:03:44:33 +0000] "CONNECT 1.3.3.7:1337 HTTP/1.0" 200 19784

Googleing the net suggests this is a PC virus, although the 200 and 19784 on the last entry has unsettled me, could somebody put my mind at ease or give me some pointers for securing this please... dD

Info:
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)

hayne 11-15-2003 01:41 AM

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>

darndog 11-15-2003 12:52 PM

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

nkuvu 11-15-2003 12:59 PM

Do you have your firewall turned on?

mervTormel 11-15-2003 01:02 PM

1.3.3.7:1337

l.E.E.T:lEET


4nn0y1ng 5cr1p7 k1dd135

darndog 11-15-2003 01:26 PM

Quote:

Originally posted by mervTormel
4nn0y1ng 5cr1p7 k1dd135
Yep, noticed that, question is of course why did the last CONNECT return 200? my understanding is that Apache on OS X should be returning 405's, any ideas where I can look for clues, already checked 'last' (Only me!) & httpd error_log dD

darndog 11-15-2003 01:29 PM

Quote:

Originally posted by nkuvu
Do you have your firewall turned on?
Yes its turned on, :D of course it has holes in it for Apache, printer sharing, iChat, pop mail, smtp & iTunes. dD

hayne 11-15-2003 02:10 PM

Quote:

Originally posted by darndog
more info on where to put the <Limit CONNECT> would be handy though if you have a mo.
I think you could put it anywhere in /etc/http/http.conf
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.

darndog 11-15-2003 10:00 PM

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: restart
Nov 10 08:55:45 G4Mac netinfod local[308]: notify's udp binder connection to
--edited--.-by dD-.com[255.255.255.255]/local failed during opening (UDP) -
socket_open failed

the netinfod gets called every single hour, going to search for file mods during missing period,
If 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

stetner 11-16-2003 12:07 AM

Quote:

Originally posted by darndog
mod_proxy is totally commented out in httpd.conf so I don't think that's it.
Yeah, but if you have been cracked, it could have been turned on then off...

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
$ touch -t 20031110085545 /xxx
# set the above date time <CCYYMMDDhhmmss> to the last time you felt safe
$ find / -newer /xxx
$ find / -newercm /xxx

You might have a whole bunch of files to look through though....

nkuvu 11-16-2003 01:14 AM

Quote:

Originally posted by hayne
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.
My knowledge of networks could fit into a small thimble -- but aren't these connections going out on port 1337? My thought is to disable that port via the firewall if it is not already disabled. Yes, they're coming in on port 80, but it's the going out that is the problem, yes?

Please tell me if I'm misinterpreting the log entries -- I want to learn this stuff, but haven't really had a chance.

darndog 11-16-2003 05:49 PM

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

stetner 11-16-2003 06:24 PM

D'oh, just re-read your post, never mind....

darndog 11-16-2003 06:54 PM

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

stetner 11-16-2003 08:46 PM

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/atrun
So I always see stuff in my system.log
Code:

Nov 17 03:15:04 strider syslogd: restart
Nov 17 03:20:00 strider CRON[11603]: (stetner) CMD (/Users/stetner/bin/verifyIP)
Nov 17 03:20:00 strider CRON[11602]: (root) CMD (/usr/libexec/atrun)
Nov 17 03:30:00 strider CRON[11701]: (stetner) CMD (/Users/stetner/bin/mailqs)
Nov 17 03:30:00 strider CRON[11700]: (root) CMD (/usr/libexec/atrun)
Nov 17 03:40:00 strider CRON[11771]: (root) CMD (/usr/libexec/atrun)
Nov 17 03:50:00 strider CRON[11836]: (root) CMD (/usr/libexec/atrun)

As for the CONNECT with a 200 code, I am not sure if that is the *only* way you could get a CONNECT log, I don't know enough about apache, but it sure sounds logical that that would be the only way...

Check 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/daily
lrwxr-xr-x  1 root  wheel  24 29 Oct 13:51 /etc/daily@ -> periodic/daily/500.daily

to increase the number of logs you keep, but I prefer to have a backup of them in any case.

If I were you, I would be watching my system like a hawk occasionaly (or regularly) do some
Code:

$ netstat -a | egrep 'LISTEN|ESTA'
To see what connections are active at any given time, and as a last resort, if I could not get that warm fuzzy feeling of security back again, I might do a clean install, being very careful about what I restored.

darndog 11-17-2003 07:52 PM

Quote:

Originally posted by stetner
As for the CONNECT with a 200 code, I am not sure if that is the *only* way you could get a CONNECT log, I don't know enough about apache, but it sure sounds logical that that would be the only way...

Check 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/

If I were you, I would be watching my system like a hawk occasionaly (or regularly) do some
Code:

$ netstat -a | egrep 'LISTEN|ESTA'
To see what connections are active at any given time, and as a last resort, if I could not get that warm fuzzy feeling of security back again, I might do a clean install, being very careful about what I restored.
Thanks, I'm going to find a decent Apache Forum to post some further questions about this issue.

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                *.*                    LISTEN
tcp4      0      0  *.9000                *.*                    LISTEN
tcp4      0      0  *.svrloc              *.*                    LISTEN
tcp4      0      0  localhost.1033        localhost.1004        ESTABLISHED
tcp4      0      0  localhost.1004        localhost.1033        ESTABLISHED
tcp4      0      0  localhost.1033        localhost.1019        ESTABLISHED
tcp4      0      0  localhost.1019        localhost.1033        ESTABLISHED
tcp4      0      0  *.ipp                  *.*                    LISTEN
tcp4      0      0  *.3306                *.*                    LISTEN
tcp4      0      0  localhost.1033        *.*                    LISTEN

9000 is Rendezvous, I guess http is Apache the localhosts seem like looped local connections, the 3306 is for mySQL, no idea what .ipp or .svrloc are? all looks legit yes?

About 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

stetner 11-17-2003 08:34 PM

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....

darndog 11-17-2003 09:26 PM

I have a Virtual host set up on 9000, Its advertised through Rendezvous:
Code:

<VirtualHost *:9000>   
    DocumentRoot /Library/WebServer/Documents
#    ServerName darndog.no-ip.com
#    ErrorLog logs/darndog.forum.error_log
    DirectoryIndex index.php
</VirtualHost> 

<IfModule mod_rendezvous_apple.c>
#RegisterUserSite all-users
RegisterDefaultSite
RegisterResource "Darndog Forum" / 9000
</IfModule>

Could you forgive my ignorance and tell me what *.* means? dD

stetner 11-17-2003 10:53 PM

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
    addresses, send and receive queue sizes (in bytes), protocol, and the
    internal state of the protocol.  Address formats are of the form
    ``host.port'' or ``network.port'' if a socket's address specifies a net-
    work but no specific host address.  If known, the host and network
    addresses are displayed symbolically according to the databases
    /etc/hosts and /etc/networks, respectively.  If a symbolic name for an
    address is unknown, or if the -n option is specified, the address is
    printed numerically, according to the address family.  For more informa-
    tion regarding the Internet ``dot format'', refer to inet(3)).  Unspeci-
    fied, or ``wildcard'', addresses and ports appear as ``*''.


breen 11-18-2003 11:04 AM

Quote:

Originally posted by stetner

ipp - IP printing (?)

Yep. Internet Printing Protocol, to be exact.

That's your CUPS daemon. The OS X firewall should prevent connections from other hosts.

Breen

daedlus 12-09-2004 08:22 PM

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.

darndog 12-14-2004 06:14 AM

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.