What to do about attempted buffer overflows
 

Hi, I have a small webserver that I run. I was checking the logs (as all good sysadmins do) and I found what looks to be an attempted buffer overflow attack on my apache webserver. I'm still new to running my own server, what do you usually do when you find this sort of thing? (And can you help me confirm that's what's happened)

tail of the log looks like this:
Note: I truncated the "SEARCH /\x90\xc9\xc9\xc9..." line, its much, much longer than that.

I'm also a little unsure how to propperly read this log file. Obviously the requesting IP is first, followed by the date and time, then the action, and then two numbers. The first of which I suspect is the server's response to the request, what is the second?

Do I email this log to my ISP's security branch? (Its comcast, so they probably wont do anything about it) I've checked for the file "/_vti_bin/_vti_aut/fp30reg.dll", I can't find it (using slocate). So I think I'm ok. (That and I think its probabaly most likely a windows binary)

More importantly, (since I'm still learning the ropes) how can I add a cron entry to tail the logs (and perhaps use some regex to filter them slightly) to give me more uptodate (consistent) checks? I also have been using chkrootkit, anyway to automate that check and email it to me also? Any advice would be great. Thanks in advance!

Result size (in bytes).

If anything, not yours. Attack source's ISP is the right one to contact. That's probably attack on that Windows problem: http://www.osvdb.org/displayvuln.php...&Lookup=Lookup

My (good guess) is that's just a bot trying an IP range. If you're not running Windows, the attack will not work for sure.

It depends. There are tools giving you stats, but beeing notified about just every such attempt is way too much - you get many similar ones every day. If you want to trace such things, Snort may be interesting for you.

Ok, Thanks! I've heard about snort. My only real security concerns are the two services I have open to the net: apache and ssh. Any tips on securing those?

I did a quick whois on that IP, it happens to be from comcast anyway, I'll give them a call. Why do you think its a bot? (I'm very interested in network security, I'd love to gain some insight into this)

http://www.securityfocus.com/infocus/1786

I would not pay much attention to the chrooting part if that would be difficult to follow. It is quite easy to break out to.

If it is all too much then the best advise I can give is that you should keep apache up-to-date.

The easiest to do that is adding the commands:

to cron (on Debian) (do "crontab -e" as root)

Looking for updates every half an our would be good:

0 9/30 * * * aptitude update
0 9/31 * * * aptitude upgrade



Logcheck is perfect if you want to check your logs.

On debian:

For chkrootkit try:

and see if you can supply your email adres then. If that doesn't work you can add this command to cron:

b.t.w see if you could use the -q switch with chkrootkit. You can read what it does when you run dpkg-reconfigure chkrootkit.

Go thru the following thread

http://www.linuxquestions.org/questi...d.php?t=340366

to secure ssh

I would not pay much attention to the chrooting part if that would be difficult to follow. It is quite easy to break out to.
Actually tried it? Care to substantiate this claim?

Excellent, thanks for the links. I was under the impression that chrooting was pretty secure. Am I wrong?

Probably should have added...

Pay only attention to how a person can modify the following:

I have not tried to break out of chroot myself, but it is explained how it can be done in this book: http://www.amazon.com/Writing-Securi...e=UTF8&s=books

According to the book it can be done on 2.4 and 2.6 kernels and the book also contains code that does it automatically for you.

If you can compile your own kernel I would look at something like Lids, Grsecurity etc. Lids has rules/settings for a whole Debian system on the lids wiki site.

http://www.lids.org

I like to add that if apache is up to date you can be pretty sure that it cannot be exploited by buffer overflows etc, until a new vulnerebility in it is found.
When a new vulnerebility is found the code of apache is adjusted so that it will be made impossible to exploit that vulnerebility.
That's why you should update apache as soon as there is an update available. (The same counts for other programs like ssh.)

If you are hacked because of such an exploit or misconfiguration of apache, then things like running apache as an unpriveleged user, etc, become important because they can limit the impact of such an attack.

Regards,

Ben

@OP: "SEARCH /\x90\xc9\xc9\xc9..."
These are not buffer overflows but search patterns meant for gathering information and finding vulnerable items.
For starters harden your machine properly using general kernel-side features like SELinux or GRSecurity, tools like Tiger, USAT (LSAT) or Bastille-Linux and check out mod_security. If you are worried about BO's then, like Mara said, look at Snort (or Prelude if you fancy something completely different).


More importantly, (since I'm still learning the ropes) how can I add a cron entry to tail the logs (and perhaps use some regex to filter them slightly) to give me more uptodate (consistent) checks?
Check out Logwatch.


@daYz: I have not tried to break out of chroot myself, but it is explained how it can be done in this book: (..) According to the book it can be done on 2.4 and 2.6 kernels and the book also contains code that does it automatically for you.
Just naming a book does not substantiate your claim.
W/o giving details you're spreading FUD.


@OP: I was under the impression that chrooting was pretty secure. Am I wrong?
In general we can say chrooting is secure as long as 1) the application that chroots drops its root account privileges without being able to regain them and 2) as long as the chroot environment does not interact with the parent environment like for instance enabling /proc, mounting FSes inside the chroot and allowing syslog.
The GRSecurity kernel patch adds specific features meant to reinforce chroots and covers all methods to break of of a chroot.


@JockVSJock: Pay only attention to how a person can modify the following
With security you will want to keep in mind single points of failure, so it really is best to use (and, not or) router features, and the local firewall and tcp_wrappers and PAM (where applicable).


@daYz: If you are hacked because of such an exploit or misconfiguration of apache, then things like running apache as an unpriveleged user, etc, become important because they can limit the impact of such an attack.
The webserver should be running as unprivileged user by default. There's no if's. Enhance limiting attack impact by running the process under SELinux or GRSecurity's RBAC.


---
In closing the Linux Security forum has a sticky: the LQ FAQ: Security references. It provides pointers to general security docs (in case you don't know a chroot from a hole in the ground), docs about system hardening and auditing (which everyone should read) and docs about securing services (like post #6).

Well ok, I have read in that book that it is possible to break out of chroot quite easily. The details are given in that book.
I can't prove that I have read that book.

I can't prove that I have read that book.
Heh. No, you don't need to. You just can not say "It is quite easy to break out to" without giving details. Maybe you can get away with that in other fora and on other topics but not here in LQ's Linux Security forum because we have to deal with facts, not phantoms. Anyone interested in information about what it takes to break out of a chroot could start by reading the GRSecurity docs and search teh intarweb for "breaking out of a chroot jail".