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.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm running Slackware with Apache 1.3 and have been checking through my logs for the past week or so and have seen 1000's of username/password guesses, obviously from a word list or similar. what I did initially was to use the IP address and add it to the DENY from feature in the httpd.conf file, but only this morning, I have seen the same thing happen again, this time it would seem that the IP addresses are completely random and as such forged, how would you go about combating such attempts to gain access to restricted areas?
Could you post an example from your apache logs? If you think about it, using packet spoofing isn't going to do someone much good for brute-forcing passwords. They would send the initial connection attempt with a forged address, to which your system would reply with the authentication challenge (but it would go to the forged address not to evil.hacker!!), they would then send random username/password combos, but since any sucess/failure replies would go to the forged address, they would never know if they guessed correctly or not. On top of that, there is also an underlying issue of TCP sequence numbering that adds a second layer of difficulty in doing that (the TCP protocol uses a very rudimentary form of spoofing protection through the numbering of packets).
If you are seeing a truckload of packets, it's possible that you are seeing a mixture of spoofed and live packets. The logic being that if you mix in enough fake packets, you can hide legitimate ones in the noise.
this time it would seem that the IP addresses are completely random and as such forged, how would you go about combating such attempts to gain access to restricted areas?
Depends on who needs access to it and what it's worth protecting. First thing I think is just like with other vulnerable services like for instance FTP would be to make sure you never use system authentication databases as underlying auth db. Use separate ones even if it puts a burden managing it (depends on what restriction is worth of course). If your userbase is distinct and small, additional TCP wrappers plus firewall access restrictions could work. If your userbase is like world, then you could try rate limit access: check iplimit from Iptable's POM and check if mod_throttle or mod_dosevasive does provide rate limiting.
Nice IP listing BTW. At least half of them are open proxies.
The dictionary I do question, because the names don't seem that generic to me. Are you by any chance running a shell server?