Cracker question

12 posts / 0 new
Last post
#1 Tue, 07/15/2008 - 13:42
velvetpixel

Cracker question

Been seeing some weirdness in my access_log.

Is this a cracker poking me: "OPTIONS * HTTP/1.1" 400 295 "-" "-"

What about these? 69.13.230.1 - - [15/Jul/2008:11:46:50 -0700] "GET http://www.google.com/ HTTP/1.0" 200 514 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 206.169.193.251 - - [15/Jul/2008:12:47:27 -0700] "GET http://www.mit.edu/ HTTP/1.1" 200 511 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)"

The 200 is the apache response code right? So what are the 514 and 511 and 295 from the top one?

Tue, 07/15/2008 - 13:46
velvetpixel

Also I saw this in my messages log yesterday:

Jul 14 07:49:10 vps named[7554]: client 38.229.0.10#52318: notify question section contains no SOA

38.229.0.10 in not an IP for any of my domains and I have no slave DNS.

Why is that message being logged?

Tue, 07/15/2008 - 16:41 (Reply to #2)
andreychek

<div class='quote'>Jul 14 07:49:10 vps named[7554]: client 38.229.0.10#52318: notify question section contains no SOA 38.229.0.10 in not an IP for any of my domains and I have no slave DNS.</div>

That may be a query from a DNS survey, as seen in packet #5 here:

http://cr.yp.to/surveys/dns1.html

The Debian folks are marking it as an &quot;ignore&quot; in Logcheck:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443869

I suspect you can do the same ;-)
-Eric

Tue, 07/15/2008 - 17:01 (Reply to #3)
velvetpixel

<div class='quote'>The Debian folks are marking it as an &quot;ignore&quot; in Logcheck:
I suspect you can do the same ;-)</div>

How do I do that?

Tue, 07/15/2008 - 17:14 (Reply to #4)
andreychek

<div class='quote'>How do I do that?</div>

Oh, I just meant that you could safely ignore it.

&quot;Logcheck&quot; is a tool that scans through server logs and emails the admin about anomalies. It at one point Logcheck raised a flag when seeing messages like the one you mentioned above, but has been configured to no longer bring attention to it.

In case you're interested, there's more info on Logcheck here:

http://logcheck.org/

Have a good one!
-Eric

Tue, 07/15/2008 - 17:21 (Reply to #5)
Joe
Joe's picture

And the similar, but unrelated (I think), tool on Red Hat based systems is logwatch.

--

Check out the forum guidelines!

Tue, 07/15/2008 - 17:23 (Reply to #6)
velvetpixel

Thanks Eric! That helps me know what's going on :)

So far the only logchecking app I have is me :D

Tue, 07/15/2008 - 17:40 (Reply to #7)
andreychek

It's awesome that you review the logs, many folks don't bother anymore.

It can be hard to grok it all though, and you might benefit from some tools that help you determine what's important and not (and only bother you when they see something important!).

As Joe mentioned, Logwatch is used by default on RHEL/CentOS. Logcheck is kept pretty up to date for Debian-based systems (though I don't know what they use by default).

I've also begun to hear some good things about Splunk: http://www.splunk.com/

Splunk is not free as in speech, it is free as in beer if you have less than 500MB of logs a day.

There's also host-based intrusion detection systems, like OSSEC and rkhunter:

http://www.ossec.net/
http://rkhunter.sourceforge.net/

I guess where I'm going with all this is that it's really hard to keep up with the logs, know what's a hack attempt versus a legitimate connection, or just have time at all to browse them.

There's a number of excellent tools out there designed to help with exactly that though (the above is just a few examples!). I'd encourage you to keep trying to understand what all you're seeing. There's just too much though, you'll never be able to keep up with it, so at the same time I'd also encourage you to use automated tools to help you monitor the logs and keep the bad guys out.
-Eric

Tue, 07/15/2008 - 18:35 (Reply to #8)
velvetpixel

I will look into Logwatch and I checked out splunk which is pretty cool!

I actually like looking at the logs (although using a tool would make it easier) because it's like taking the pulse of my machine. I just got in the habit of doing it when setting up iptable rules for the first time to try my best to keep malicious people out.

Wed, 07/16/2008 - 00:11 (Reply to #9)
ronald
ronald's picture

logwatch is installed by default on a centos

you can do

logwatch --service pam_pwdb --range yesterday --detail high --print

and replace pam_pwdb with any other service running like

logwatch --service postfix --range yesterday --detail high --print

Wed, 07/16/2008 - 10:20 (Reply to #10)
velvetpixel

Thanks ronald! :)

Tue, 07/15/2008 - 17:05
andreychek

<b>velvetpixel wrote:</b>
<div class='quote'>Been seeing some weirdness in my access_log.

Is this a cracker poking me:
&quot;OPTIONS * HTTP/1.1&quot; 400 295 &quot;-&quot; &quot;-&quot;

What about these?
69.13.230.1 - - [15/Jul/2008:11:46:50 -0700] &quot;GET http://www.google.com/ HTTP/1.0&quot; 200 514 &quot;-&quot; &quot;Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)&quot;
206.169.193.251 - - [15/Jul/2008:12:47:27 -0700] &quot;GET http://www.mit.edu/ HTTP/1.1&quot; 200 511 &quot;-&quot; &quot;Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)&quot;

The 200 is the apache response code right?
So what are the 514 and 511 and 295 from the top one?</div>

If a server gets less than 100 people/bots a day trying to break into it, I might question whether it's actually on the Internet :-)

You're right, the first number you see afterwards is the Apache response code, the second is the size of the response.

So why are there get requests for google and mit? I have no idea :-) You can telnet to port 80 on your own server and manually enter those GET requests, and you should end up seeing your main page on that server for some of them, and errors for others.

You can read about the &quot;OPTIONS&quot; one here in the Request-URI section:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

Long story short though, patch your system, keep your web apps up to date, and I don't think you have the slightest thing to be concerned about from the above :-)
-Eric

Topic locked