Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)
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!
Last edited by c4onastick; 10-30-2006 at 11:56 AM.
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.
Quote:
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!
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)
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?
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.
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.
@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).
Just naming a book does not substantiate your claim.
W/o giving details you're spreading FUD.
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".
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.