LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 09-12-2010, 09:29 PM   #1
cnmoore
Member
 
Registered: Sep 2010
Location: Sunnyvale, CA
Distribution: CentOS 5.5
Posts: 89

Rep: Reputation: 0
Newbie - what to do about huge number attempted ssh logins


Lastb often shows me a huge list of attempted ssh logins.
Such as this excerpt:
Code:
admin    ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
apache   ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
master   ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
master   ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
guest    ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
guest    ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
admin    ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
root     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
test     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
test     ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
ftp      ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
webadmin ssh:notty    Sat Sep 11 23:47 - 23:47  (00:00)     184-154-37-12.Huge-DNS.COM
Is there something I should do about them?
I'd like for logwatch not to have to send me such a huge report.

I think I can put something in /etc/hosts.deny but I'm sort of lost in the man page. Can you please tell me exactly what line to put in hosts.deny for the example above? (Currently /etc/hosts.deny is empty). And am I right in thinking that would prevent them from getting logged?
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 09-12-2010, 09:41 PM   #2
AlucardZero
Senior Member
 
Registered: May 2006
Location: USA
Distribution: Debian
Posts: 4,608

Rep: Reputation: 517Reputation: 517Reputation: 517Reputation: 517Reputation: 517Reputation: 517
Code:
ALL: 174.37.172.68
will make SSHD refuse connection attempts.

You should run DenyHosts or Fail2Ban to do this automatically.
 
Old 09-12-2010, 10:00 PM   #3
gilead
Senior Member
 
Registered: Dec 2005
Location: Brisbane, Australia
Distribution: Slackware64 14.0
Posts: 4,123

Rep: Reputation: 151Reputation: 151
You can also limit the users (or groups) that can use SSH as well as forcing the use of keys instead of passwords.

If you just want to reduce the clutter in your logs, run your SSH daemon on another port. I have my external SSH on port 443 now because the proxy at one the sites I work at won't allow connections to anything except ports 80, 8080 or 443. A side effect of doing that was since most port scans only check port 22 for SSH I now get no attempts to access my SSH server. Please note, that's just convenience, not extra security
 
Old 09-13-2010, 07:08 AM   #4
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,778
Blog Entries: 1

Rep: Reputation: 412Reputation: 412Reputation: 412Reputation: 412Reputation: 412
You could also throw a few rules on your firewall to disallow an IP after a certain number of attempts during a specific time period:

Code:
iptables -N AUTOBAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j AUTOBAN
iptables -A AUTOBAN -m recent --set --name SSH
iptables -A AUTOBAN -m recent --update --seconds 120 --hitcount 4 --name SSH -j DROP
With these, any IP address that has tried to log in 4 times in the last 2 minutes gets dropped. Since I've got a low-usage server, I've found this to be less hassle than fail2ban or DenyHosts.

Interestingly, I've found that the number of attempts has dropped precipitously. There is the occasional clown who has tailored their attack so that it evades something like this, but that is rare. By the way, a big thumbs up to folks at Codero. I was getting pestered by one of these slow rollers, complained to them since it was one of their IP addresses, and they actually did something about it. Never had that happen before.

Last edited by Hangdog42; 09-13-2010 at 07:12 AM.
 
1 members found this post helpful.
Old 09-13-2010, 11:16 AM   #5
tredegar
Guru
 
Registered: May 2003
Location: London, UK
Distribution: Ubuntu 10.04, mostly
Posts: 6,007

Rep: Reputation: 366Reputation: 366Reputation: 366Reputation: 366
You could also read the sticky ( fifth thread ) on the LQ "Security Forum" which is titled "Failed SSH login attempts" and has an interesting discussion about how to prevent them becoming annoying.
 
Old 09-13-2010, 11:28 AM   #6
cnmoore
Member
 
Registered: Sep 2010
Location: Sunnyvale, CA
Distribution: CentOS 5.5
Posts: 89

Original Poster
Rep: Reputation: 0
Thanks, everyone. Hangdog42 I'm trying the iptables - seems a lot simpler than trying to install DenyHosts or Fail2Ban (extreme newbie fearful of breaking the server and having to crawl to host Support).
 
Old 09-13-2010, 11:40 AM   #7
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
Quote:
Originally Posted by cnmoore View Post
iptables - seems a lot simpler than trying to install DenyHosts or Fail2Ban
I agree you should read the sticky Failed SSH login attempts thread before deciding what to do and note using /etc/hosts is not your best option. You run a dedicated Centos-5.5 server with a forum. Overcome your fear of b0rkage by gathering knowledge and experience, enabling a backup scheme (you do make off-site backups do you?) and creating a staging server at home or work (virtualization?) to test things before moving it to your production environment. Taking the easy way out will eventually lead to the worst possible "solution".
 
2 members found this post helpful.
Old 09-13-2010, 11:58 AM   #8
cnmoore
Member
 
Registered: Sep 2010
Location: Sunnyvale, CA
Distribution: CentOS 5.5
Posts: 89

Original Poster
Rep: Reputation: 0
unSpawn this is of course good advice.

I backup the database with mysqldump and tar.gz the public_html every day. The backup files are copied to another server (shared) and also to my PC. I wrote a script to make my backups and scp to other server but so far haven't succeeded in getting it to run as cron job, so I run the script manually every 11:00 PM.

No clue how to make a staging server or how to back up anything other than user accounts (via DirectAdmin).

I had already read 'Failed SSH Login attemps' as part of extensive googling. It says "Access restriction can be done using iptables or tcp_wrappers (hosts.allow/deny)" so I figure iptables is ok for starters?

yum install doesn't find DenyHosts or Fail2Ban so I guess I would download (via rpm?) first and then run yum?

Part of my overall hesitation is because my host's techs login as root every so often and I don't want to accidentally block them. I don't know all the names. There is just one of them in /home/ at the moment.

Edit: Doing the iptables thing seems to have been remarkably successful so far - no attempts for the last two hours.

Last edited by cnmoore; 09-13-2010 at 12:08 PM.
 
Old 09-13-2010, 06:05 PM   #9
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
Quote:
Originally Posted by cnmoore View Post
I backup the database with mysqldump and tar.gz the public_html every day. The backup files are copied to another server (shared) and also to my PC.
Ahhh, good!


Quote:
Originally Posted by cnmoore View Post
I wrote a script to make my backups and scp to other server but so far haven't succeeded in getting it to run as cron job
Feel free to create a separate thread in the Programming or Newbie forum to get that issue fixed.


Quote:
Originally Posted by cnmoore View Post
No clue how to make a staging server or
Install VMware server (freely installable), Virtualbox or whatever else equivalent and you have the basis to run a "guest system" on. From there on it would just be a regular installation except for the fact that you won't be using a complete machine or disk but files on disk. The benefits of using virtualization are numerous: nearly error-free (restore a snapshot and try something again), portable between machines, quick(er) boot-up (suspend mode), relatively safe (host isolation), can run with any type of network configuration (bridge mode, host-NAT, isolated LAN), et cetera, et cetera.


Quote:
Originally Posted by cnmoore View Post
how to back up anything other than user accounts
I've addressed that in your other thread.


Quote:
Originally Posted by cnmoore View Post
(via DirectAdmin).
While web-based system management panel software can streamline operations they also force you to accept what procedures they offer, they often are opaque in how they address or change things and they often will not show the level of detail and control you get from hand-editing a set of configuration files. While some have grown accustomed to (graphical) interfaces that provide interactive clues, help, and warnings some people have come to depend on them for the wrong reasons, like allowing them to perform operations w/o having to read any documentation at all. That's why I maintain that using web-based system management panel software is no substitute for theoretical knowledge and practical experience.
(@all: any DirectAdmin experts in the house?)


Quote:
Originally Posted by cnmoore View Post
I had already read 'Failed SSH Login attemps' as part of extensive googling. It says "Access restriction can be done using iptables or tcp_wrappers (hosts.allow/deny)" so I figure iptables is ok for starters? yum install doesn't find DenyHosts or Fail2Ban so I guess I would download (via rpm?) first and then run yum?
Good. Iptables is OK as long as you know what you're doing. 'You search fail2ban' should return "fail2ban-0.8.2-3.el5.rf.noarch" if you have the RPMForge repo installed and enabled.


Quote:
Originally Posted by cnmoore View Post
Part of my overall hesitation is because my host's techs login as root every so often and I don't want to accidentally block them.
That's probably pure laziness. Nobody should need to log in as root. Log in over SSH as unprivileged user with pubkey auth then use Sudo.


Quote:
Originally Posted by cnmoore View Post
Edit: Doing the iptables thing seems to have been remarkably successful so far - no attempts for the last two hours.
Cool!


* Also it's time you know issues on LQ should be split up wrt their topic. Anything that touches on security remains here, backups, server configuration, distribution-specific issues, et cetera should be split off or see new threads created in their respective forum.
 
Old 09-13-2010, 06:18 PM   #10
cnmoore
Member
 
Registered: Sep 2010
Location: Sunnyvale, CA
Distribution: CentOS 5.5
Posts: 89

Original Poster
Rep: Reputation: 0
Thanks again, unSpawn.

I think this is a security thought:

I really don't like the way my host logs in as root.
This looks as though they log in as root over SSH from some PC.
Code:
root     pts/8        Mon Sep 13 13:11 - 13:11  (00:00)     [UNDISCLOSED_IP_ADDRESS]
Which I have read is a very bad thing to do. I no longer do it myself. What I do is SSH in as [SOME_USER] and then do SSH [ANOTHER_USER_AT_SOME_HOST], using public key arrangement.. I figure that is OK as it is within the same server, and is better than su because with su the password goes over the PuTTY connection.

Nothing I can do about my host, though.

Last edited by unSpawn; 09-14-2010 at 02:54 PM. Reason: //No need for disclosure on live server
 
Old 09-13-2010, 11:08 PM   #11
cnmoore
Member
 
Registered: Sep 2010
Location: Sunnyvale, CA
Distribution: CentOS 5.5
Posts: 89

Original Poster
Rep: Reputation: 0
My iptables blacklisted my own IP!

All straightened out with the aid of hosts's Support. I think it happened because I had four sessions running in 'screen'.

I like the iptables thing but I have temporarily removed it with 'iptables -F AUTOBAN'.
It was made with
Code:
iptables -N AUTOBAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j AUTOBAN
iptables -A AUTOBAN -m recent --set --name SSH
iptables -A AUTOBAN -m recent --update --seconds 120 --hitcount 4 --name SSH -j DROP
Before I put it back:

Is there a way to keep iptables from blacklisting me?
And, is there a way to un-blacklist an IP?
 
Old 09-14-2010, 01:29 AM   #12
cnmoore
Member
 
Registered: Sep 2010
Location: Sunnyvale, CA
Distribution: CentOS 5.5
Posts: 89

Original Poster
Rep: Reputation: 0
I have done further research. Actually I don't believe iptables blacklists? it just drops?

It was DirectAdmin that added my IP to their blacklist. I have put myself in DirectAdmin whitelist.
 
Old 09-14-2010, 07:17 AM   #13
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,778
Blog Entries: 1

Rep: Reputation: 412Reputation: 412Reputation: 412Reputation: 412Reputation: 412
Quote:
Is there a way to keep iptables from blacklisting me?
Try adding this before the AUTOBAN section and replace XXX.XXX.XXX.XXX with your actual IP address.

Code:
iptables -A INPUT - tcp -s XXX.XXX.XXX.XXX -dport 22 -j ACCEPT
Quote:
I have done further research. Actually I don't believe iptables blacklists? it just drops?
Yes, it just drops and it should stop dropping after a few minutes. As soon as you have fewer than 4 connection attempts in a 2 minute period, that rule shouldn't be enforced. I'd be surprised if screen was causing the drop because the multiple screen sessions are being run over a single SSH connection. As far as I know, iptables shouldn't even know about the screen sessions.
 
Old 09-14-2010, 04:24 PM   #14
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,987
Blog Entries: 54

Rep: Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742Reputation: 2742
Quote:
Originally Posted by cnmoore View Post
I really don't like the way my host logs in as root. This looks as though they log in as root over SSH from some PC.
Looks like it, yeah.


Quote:
Originally Posted by cnmoore View Post
I no longer do it myself. What I do is SSH in as [SOME_USER] and then do SSH [ANOTHER_USER_AT_SOME_HOST], using public key arrangement. I figure that is OK as it is within the same server, and is better than su because with su the password goes over the PuTTY connection.
SSH'ing to root requires the root account to be enabled. Bad. When you SSH in the first time the connection is encrypted already.


Quote:
Originally Posted by cnmoore View Post
Nothing I can do about my host, though.
You could ask them? If they can agree to use public key auth and a fixed set of management IP addresses or IP ranges then you could use iptables to limit access (plus port knocking?) plus set a "from=123.456.789.*,456.789.123.*,789.123.456.*" limit on the public key in authorized_keys. That's still bad but at least then you've tried to mitigate the situation.

* BTW I've cleaned up offending IP addresses and account names. There's no need to disclose that kind of information wrt a Live server.
 
Old 09-14-2010, 04:48 PM   #15
cnmoore
Member
 
Registered: Sep 2010
Location: Sunnyvale, CA
Distribution: CentOS 5.5
Posts: 89

Original Poster
Rep: Reputation: 0
Sorry, I don't know what you mean about "SSH'ing to root requires the root account to be enabled. Bad. When you SSH in the first time the connection is encrypted already. "

How would a person log in as root if root wasn't enabled? You've lost me. And are you saying that su root is better than SSH root?

Also, not a chance my host will change their ways. Support is good but not real communicative and not generally hand holders. All contact is via problem tickets.
 
  


Reply

Tags
attempted, login, ssh


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
powertop reporting a huge number of acpi interrupts gawhelan Linux - Laptop and Netbook 5 01-15-2009 02:12 AM
find the total number of pseudo terminals of all logins RajRed Linux - General 5 04-18-2006 04:30 AM
server listening on port 22 and attempted logins from an unauthorized user kevinlyfellow Linux - Networking 2 03-24-2005 10:41 PM
attempted logins and shutdowns on tty1 tw001_tw Linux - Security 7 08-03-2004 08:29 PM
Problem with huge number of pthreads Berng Programming 7 12-17-2003 07:33 AM


All times are GMT -5. The time now is 04:34 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration