LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
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 04-23-2007, 02:53 PM   #1
mcupples
Member
 
Registered: Jun 2006
Location: Orlando
Distribution: FC3, FC5, CentOS4, Ubuntu 6.06
Posts: 57

Rep: Reputation: 15
Possible Intrusion Attempt


Hey guys,

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:

Code:
Apr 22 06:03:13 db2 sshd(pam_unix)[26039]: check pass; user unknown
Apr 22 06:03:13 db2 sshd(pam_unix)[26039]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:16 db2 sshd(pam_unix)[26041]: check pass; user unknown
Apr 22 06:03:16 db2 sshd(pam_unix)[26041]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:18 db2 sshd(pam_unix)[26043]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=news
Apr 22 06:03:21 db2 sshd(pam_unix)[26045]: check pass; user unknown
Apr 22 06:03:21 db2 sshd(pam_unix)[26045]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:24 db2 sshd(pam_unix)[26050]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=games
Apr 22 06:03:28 db2 sshd(pam_unix)[26053]: check pass; user unknown
Apr 22 06:03:28 db2 sshd(pam_unix)[26053]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212
Apr 22 06:03:31 db2 sshd(pam_unix)[26057]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=mail
Apr 22 06:03:33 db2 sshd(pam_unix)[26059]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=200.91.87.212  user=adm
Apr 22 06:03:36 db2 sshd(pam_unix)[26061]: check pass; user unknown
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.

Thanks,
Matt
 
Old 04-23-2007, 03:08 PM   #2
mcupples
Member
 
Registered: Jun 2006
Location: Orlando
Distribution: FC3, FC5, CentOS4, Ubuntu 6.06
Posts: 57

Original Poster
Rep: Reputation: 15
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.

Code:
iptables -I INPUT -s 200.91.87.212 -j DROP
Right?
 
Old 04-23-2007, 04:00 PM   #3
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,791
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
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.
 
Old 04-23-2007, 04:01 PM   #4
Emerson
Senior Member
 
Registered: Nov 2004
Location: Saint Amant, Acadiana
Distribution: Gentoo ~
Posts: 3,177

Rep: Reputation: Disabled
Don't bother. If your box is exposed to the internet you will get portscans and breakin attempts on 24x7 basis. Read the sticky in this forum.

1 min late.
 
Old 04-23-2007, 05:15 PM   #5
pAn1k
Member
 
Registered: Jun 2004
Location: Cala city
Distribution: Suse 10.0; Debian 5.0 (Lenny) Fluxbox
Posts: 240

Rep: Reputation: 30
Try using denyhost it throws an ip into hosts.deny after a specified number of failed attempts. Works great, and is easy to set up.
 
Old 04-24-2007, 12:50 AM   #6
stormpunk
LQ Newbie
 
Registered: Mar 2004
Distribution: windows 7
Posts: 21

Rep: Reputation: 2
Quote:
Originally Posted by pAn1k
Try using denyhost it throws an ip into hosts.deny after a specified number of failed attempts. Works great, and is easy to set up.
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.
 
Old 04-24-2007, 10:31 AM   #7
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
Quote:
Originally Posted by stormpunk
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.

There are many many ways to tackle this issue.
 
  


Reply

Tags
attempt, iptables, logs, messages, 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
Intrusion Problem!! InvisibleSniper General 7 01-26-2006 10:31 AM
possible intrusion? netstat branden_burger Linux - Security 3 03-03-2005 10:54 AM
intrusion? tincat2 Linux - Security 2 01-01-2005 02:56 AM
ssh intrusion! DavidPhillips Linux - General 17 11-19-2004 07:39 AM
Intrusion Detection? matador Linux - Security 5 09-03-2003 05:44 AM


All times are GMT -5. The time now is 04:53 AM.

Main Menu
Advertisement
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