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 have a problem that I'm not too certain about. I've googled this and come up with several different paranoid theories. I've been told that I SHOULD care about this but I'm not sure how to go about it. I'm under the assumption that iptables can block a single IP or a range of them but I was told by some people to not mess with iptables unless you know what you're doing. I was hoping I could run some commands by you guys so you could tell me if I'm going to be shooting myself in the foot by running these.
To begin with, however, here are the logs I'm worried about:
This is just a snippet, mind you. There are quite a few more attempts in the logs and I stopped researching around the 13th of April. If I should research to determine when they started, let me know - but I believe this enough information.
I'm going to go ahead and check out the man pages for iptables and come up with a command which I will post shortly. I just wanted to get this post up asap because I'm starting to get as paranoid as the people I've found on google.
Okay this is it. I'm going to enter this command as root into my ssh connection. I believe this will drop all packets coming from that specific ip. After that I'll just need to keep an eye on the logs to ensure he's not using a different ip.
Be sure to have a read through this sticky thread for more ideas on how to handle this. Dictionary attacks against an sshd server are pretty much a daily occurrence, so blocking one IP address isn't going to do much. At a bare minimum, you should make sure SSH2 is the only allowed protocol, disallow root access via ssh, and seriously consider locking down the users with the AllowUsers directive in your sshd_config file. Of course, passwords for legitimate accounts must be strong. A significant improvement could also be had by ditching passwords completely and moving to key based authentication for ssh. That renders a dictionary attack completely useless. There is a nice tutorial on doing that here.
Heck, I used to have a script that did stuff like that but the list gets long quickly and if the IP addresses are dynamic you could block real users.
Nowadays, I throttle ssh connection rates similiar to what you'll find in that sticky thread and while you'll get a scan still, they usually give up when they notice dropped packets.
Key-based authentication lessens the impact of long block lists and dynamic IPs. I use a cocktail of Denyhosts, ipfilter, and SSH key auth, as layered security is best. I've had instances of Denyhosts not running but wasn't impacted because I also used key-based SSH authentication, so even if my firewall policy wasn't secure, I'd still have port 22 locked down.
He could also add the user accounts to his SSH config file, so that only they can access the service.