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.
That may be a query from a DNS survey, as seen in packet #5 here:
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?
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 "OPTIONS" one here in the Request-URI section:
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
"Logcheck" 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:
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 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
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.