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.
A n00b question: why do I still get in my logs ssh messages like "Illegal user <name> from XX.XX.XX.XX" while the hosts.deny specifies 'ALL:PARANOID' and the hosts.allow is empty?
I read the thread at the beginning of this forum regarding illegal ssh attempts, but how come they still get the chance to attempt a login? I must admit since I have these settings the attempts became more rare (2-3 once every 2-3 days) yet they bother me.
I also get messages of "refused connect from ..." so, shouldn't it be supposed to refuse ALL connections?
A n00b question: why do I still get in my logs ssh messages like "Illegal user <name> from XX.XX.XX.XX" while the hosts.deny specifies 'ALL:PARANOID' and the hosts.allow is empty?
As far as I know, PARANOID just matches spoofed connections (requests whose hostname doesn't match IP). So all your hosts.deny is doing is dropping spoofed requests to any supported service. Keep in mind that this has nothing to do with the username that someone is trying to login with and whether it is valid or not.
I read the thread at the beginning of this forum regarding illegal ssh attempts, but how come they still get the chance to attempt a login?
See above. As long as they are making valid requests (hostname and IP match) they can try as many login attempts as they like.
Maybe if you explain what you would like to do, we could help you find a reasonable solution. Though blocking all incoming requests doesn't seem to make any sense. Why even run the ssh service then?
I'm keeping ssh running just in case I need to do a remote login myself (yet I don't think I'll ever need it, just in case).
Quote:
Keep in mind that this has nothing to do with the username that someone is trying to login with and whether it is valid or not.
So I should use the Deny/Allow Groups/Users in sshd_config to prevent anybody from succesful logins except me, right? Of course, if the attacker isn't so lucky (or smart) to guess my account name/password combination.
Quote:
Maybe if you explain what you would like to do, we could help you find a reasonable solution.
My computer's purpose is just an ordinary workstation, a home computer. I'm just trying to make it as safe as possible. I've had enough unpleasant surprises when I used to run Window$ such as viruses, spyware and malware.
I'm keeping ssh running just in case I need to do a remote login myself (yet I don't think I'll ever need it, just in case).
Ok, but that's the tradeoff. You're running a public service in order to give yourself convenient access from anywhere. But that means you don't really have any way of restricting login access. Unfortunately tcp_wrappers (hosts.allow/deny) can't really do much then. If you can limit access to only a few netblocks or IPs, then you'll significantly cut down on the number of these login attempts. For example I limit ssh access from my work IP block, and home ISP IP blocks and it helps alot. Unfortunately that means I can't login from anywhere.
So I should use the Deny/Allow Groups/Users in sshd_config to prevent anybody from succesful logins except me, right?
Definitely disallow remote root logins and any users on the system that don't need ssh access. However, this will still not prevent login attempts for other users (or non-existant users) on the system.
Of course, if the attacker isn't so lucky (or smart) to guess my account name/password combination.
If you use good passwords, then this is much harder to do than most people realize. The brutessh tool that does these automated logins takes advantage of people doing really stupid/lazy things like using user/passwd combos like root/root or test/test. If your passwords are sufficiently long (>8 characters), random non-dictionary strings with numbers and symbols, then trying to guess a password or even bruteforce a password is incredible difficult (virtually impossible) using ssh. So botttom line is that if your passwords are good, then you don't need to be incredible concerned with some 12 year old script kiddie trying to login with admin/admin. Now if someone is persistantly trying logins for hours/days on end, then you should probably blacklist them with iptables.
Of course you can always switch to key-based authentication and put your keys on a usb pen drive so that you can login from anywhere or even run ssh on an alternative port. Either one of those will eliminate these types of scans.
Distribution: Ubuntu currently, also Fedora, RHEL, CentOS
Posts: 111
Rep:
I'll second the "use keys" notion. If you have cd, floppy or USb drive with some space, put your private key on that and disable password authenication, then you KNOW you can be the only one in. (keys are crackable, but extremely unlikely. better chance of being hit by lighting 3 times).
Using keys will not prevent connections attempts from outside sources.
Also, you could move your ssh server from port 22. Most of the "attack attempts" circulating the internet use port 22 and that's all. If you move to 2222 or anything else, I would bet your connection attempts would dramatically decrease.
Thank you for your replies. Ok, I've decided to stop using sshd for now. I know you can do it with '/etc/init.d/sshd stop' but how to do it pemanently? I can't remember which file sets the daemons that will be started at boot up. Remember, I'm a n00b. BTW, this won't stop me from ssh'ing into other machines, right?
And one more question: searching the net I found many posts with similar topics. Most of them showed parts of logs where the messages said the attempts consisted of trying both an account name followed by a password. In my logs I see nothing related to incorrect or failed passwords. Only 'illegal users'. Why?
Ok, I've done some more reading meanwhile and it looks like /etc/inetd.conf is what I'm supposed to be after (please correct me if I'm wrong).
Yet the file contains (uncommented) entries only for:
ident stream tcp wait identd /usr/sbin/identd identd
cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/sbin/cvs-pserver
No ssh.
Some more reading and I find out that I need to edit a /etc/rc.d/inetd file. Don't have a rc.d directory. Then I see that I must rename files in /etc/rcN.d (N=0..6,S) so they don't begin with a 'S' in order to prevent their loading at startup.
Is this the right way?
Distribution: Ubuntu currently, also Fedora, RHEL, CentOS
Posts: 111
Rep:
most of the time, sshd does not run out of inetd; it runs as its own service. I am not 100% certain if debian has chkconfig, but if it does, try chkconfig sshd off. That will prevent it from starting at boot time. You will still be able to ssh to other machines.
Renaming the startup files in /etc/rc.* is a perfectly good way to prevent startup also.
Thanks. That's what I needed to know. A bit late though...I already renamed S(K)20ssh to s(k)20ssh where necessary. Good to know for the future anyway.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.