Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
Few minutes back my web server running apache-1.3.20-16, php-4.0.6-7, mysql-3.23.41-1 and squid was hacked and some files were modified and replaced. The last message shows that I was logged in last and no one else. I am totally at loss to find that how this happened since wtmp seems to be alright. Can someone tell me that how this could have been done?.
You have quite old Apache. The current version for 1.3.x series is 1.3.26. There were many security problems between 1.3.20 and the current release.
I reccomend to disconnect your server from network, copy the whole filesystem somewhere (to look into it later) and reinstall the whole thing.
Ok, That seems to be the last resort. I am afraid to put it back. He replaced our former HOD's image with that of a pig. Only a few other files are changed. Should be one of our own students. Anyway, I am going to reinstall the server. Thanks for the suggestions.
Why you keep telling us "a few files changed" and not telling us *which ones*? And how did you check it was only a few files? Running a local integrity scanner like Tripwire or Aide, or looking in files?
Anyway, if you reinstall your stuff, don't blindly copy over an oldbackup. You'd be better off reinstalling from scratch.
Also don't save files from the current install that are *not* humanly readable. Since it's a webserver, delete *any* X11, development, sound, games, fortune stuff after all installation is done, ie remove all software that isn't specifically needed for operation.
IIRC the adagium reads "that what isn't specifically allowed is forbidden". It means you have to set limits and restrictions on every aspect of the system that is exposed to (local) users or the (public) network. Remove unnecessary user accounts. Don't let local user accounts and ftp accounts be read from the same passwd file. If you need local users, put limits and restrictions on them, don't allow them to login tru telnet or use r-services, scrub the system for suid/sgid binaries, strip or chown then so they can only be reached with sudo. Consider building a kernel that will not accept loadable modules, or take a way capabilities after boot. Also take away capabilities for users and processes to read in /dev and /proc where they're not supposed to. *Our new linuxquestions kernel patch (LQ3) or patching with Grsecurity will do nicely.
Make sure permissions of your configuration files and certificates are set to minimum acceptable chattr them (the ones that are not affected by reboots, network changes etc) and make a backup.
Make sure /proc/sys/net holds values that maximize performance but will curb effects of simple D0S attacks.
Make sure Xinetd and TCP wrappers-aware applications are fed the right allow/deny ranges. Run networked services under less privileged accounts. Make sure your Apache/php/mysql configs are tightly configured, like it doesn't allow POST's where it shouldn't.
Inspect your firewall script again. Make sure to deny IANA LAN ranges, broad/multicasts and false packets. Make sure you put limits on expected ICMP messages. If you care, run Snort. It's great for reporting network packets that fit buffer overflow, scan, worm or other anomaly signatures.
If you can, do set up remote (centralized) logging. This way you'll have logs in a place where a cracker can't (directly) reach 'em plus it's easier checking that way.
Finally chattr your system binaries and run your integrity checker (Aide, Tripwire) and save the baseline database off-site for later, regular checking.
When you've gone tru all of this, this would be a good moment to put the system back online. if you already did that before inspecting the above, slap yourself on the head :-]
Next you'll have to make sure you update your system actively, subscribe to your vendors mailinglists read the security and vulnerability warnings and act on them.
I met few of the "local hackers" and they told me how it might have been taken place. They told showed me that they could run some php scripts which contained some shell-exec that over wrote the pages in the site.
Now, we are hosting a national level conference on this site which will take place in next few months. The server is highly configured with many settings to handle this job. So my professor or the student, who maintains the site, do not want any changes now. So we are keeping the upgradation for the winter vaccations. I will surely keep all your suggestions in mind while doing that.
For the time being I am trying to see how to stop this shell-exec thing and how that might affect the normal functioning of the site.
PS: I am sorry for the "few files". I found that it was only those pages that had faculty information in it were changed. ( I just did a manual comparison. I don't have tripwire. ). So I assumed that it will be a student who did not pass a few courses offered by those faculty
Yeah, that's old PHP for ya...
Now let me get this clear, you're about to host something important, so you people put off making sure this sytem won't fail you? Isn't there a chance you can install fresh on a separate box, tighten security and then copy over and tweak the "good" parts of the site and *then* replace the box?