ssh break-in attemps. Should I worry?
Frank Dreyfus
Lately there have been lots of login attempts from people that have no
right to be there. Here's an example from auth.log:
Aug 15 08:06:07 main sshd[10793]: Failed password for root from
::ffff:203.186.157.37 port 52442 ssh2
Aug 15 08:06:10 main sshd(pam_unix)[10795]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=203186157037.ctinets.com
user=root
Most of these appear to be coming from Asia. Some, I'm pretty sure are
from schools.
My concern is that hackers may be trying to crack a password. AFAICS,
they haven't found a valid p/w yet. But I guess it could just be a
matter of time.
Should I be concerned? Is there anything I can do to foil these
attempts? My first thought was to block access from these domains. In
the above example, I thought I could probably block 203.186.*.* but after
reading man sshd, I don't see any way to do this. You can block users
and/or groups but not ip's.
I'm reluctant to use public/private key authentication (I use passwords)
because I have to be able to log in from remote sites and from other
user's computers so I don't or can't always have a key with me.
What can/should I do?
Thanks, Frank
Mahler
people trying to get in, mostly from China. As does another friend who
runs Slackware. I think perhaps ipchains will block a slew of ip
addresses. Calling ipchains gurus.......
Tom
> Hi,
Hi,
> My concern is that hackers may be trying to crack a password. AFAICS,
> they haven't found a valid p/w yet. But I guess it could just be a
> matter of time.
> Should I be concerned? Is there anything I can do to foil these
> attempts?
First of all, you should deny, if it is not already the case, root logging
in sshd. If most attempts to login as root...
> My first thought was to block access from these domains. In
> the above example, I thought I could probably block 203.186.*.* but after
> reading man sshd, I don't see any way to do this. You can block users
> and/or groups but not ip's.
As said by Mahler you can set up iptables to achieve that.
> I'm reluctant to use public/private key authentication (I use passwords)
> because I have to be able to log in from remote sites and from other
> user's computers so I don't or can't always have a key with me.
It's a pity because it would have solved almost all your problems...
> Thanks, Frank
--
nospam = free / cwz=fr
Bit Twister
> Hi,
>
> Lately there have been lots of login attempts from people that have no
> right to be there.
>
> from schools.
Can be from zombied boxes everywhere.
> My concern is that hackers may be trying to crack a password. AFAICS,
> they haven't found a valid p/w yet. But I guess it could just be a
> matter of time.
Zombie master asks several zombies to try your box, time would get smaller.
> Should I be concerned?
ssh daemon all patched up to current level. Will crackers get to your
box before a known exploit is not patched on your box by a Zero Day Exploit.
> Is there anything I can do to foil these
> attempts? My first thought was to block access from these domains. In
> the above example, I thought I could probably block 203.186.*.* but after
> reading man sshd, I don't see any way to do this.
maybe using the fiewall with something like 172.16.0.0/12
>
> I'm reluctant to use public/private key authentication (I use passwords)
> because I have to be able to log in from remote sites and from other
> user's computers so I don't or can't always have a key with me.
Hmmmm, wallet full?? carry something like
I don't or can't always have a key with me.
and the key phrase is _e th ey a ve ys nt r nt i_"
P.T. Breuer
> My concern is that hackers may be trying to crack a password. AFAICS,
> they haven't found a valid p/w yet. But I guess it could just be a
> matter of time.
Well, until the universe grows cold ... you don't have a passwrd made
of dictionary words? Even two of them together? Or a word plus numbers?
Run "john" on your password to see if it is secure.
>
> Should I be concerned?
See above.
> Is there anything I can do to foil these
> attempts?
Blacklist them; contact the admin of their site.
> My first thought was to block access from these domains. In
> the above example, I thought I could probably block 203.186.*.* but after
> reading man sshd, I don't see any way to do this.
Eh? You can block any IP you like!
# DenyHosts lowsecurity.theirs.com *.evil.org evil.org
> You can block users
> and/or groups but not ip's.
False.
> I'm reluctant to use public/private key authentication (I use passwords)
But that IS ssh, no? Oh - I see, you mean you don't use RSA as the only
auth, like you said :). RSA is always used for the key exchange,
whatever it is.
> because I have to be able to log in from remote sites and from other
> user's computers so I don't or can't always have a key with me.
It doesn't matter. If you don't have the key available for the
exchange, the password will be asked for.
> What can/should I do?
See above.
Peter
Frank Dreyfus
news:9jdrfc...@news.it.uc3m.es:
> Frank Dreyfus <fdre...@nyw.com> wrote:
> Run "john" on your password to see if it is secure.
Thanks, I'll try that.
>
> Eh? You can block any IP you like!
>
> # DenyHosts lowsecurity.theirs.com *.evil.org evil.org
You say I can do that but your example is based on host names rather than
ip's. In most cases, I don't know the attacker's host name.
> It doesn't matter. If you don't have the key available for the
> exchange, the password will be asked for.
My idea was to disable login via passwords. If I don't, then it really
doesn't matter if I use RSA or plain passwords since the attackers can
still user p/w's.
Thanks for your help,
Frank
P.S. It turned out that one of the ip's (168.16.147.50) was registered
to University System of Georgia. I sent a report to NIC-...@usg.edu so
we'll see what happens - if anything. As for the Asian domains, I don't
usually know who to send the report to, whether they'll understand
English and if they really care.
Frank
Frank Dreyfus
> I think perhaps ipchains will block a slew of ip
> addresses.
Yes. Thanks. I really knew that but it didn't occur to me at the time.
Thanks,
Frank
P.T. Breuer
> p...@oboe.it.uc3m.es (P.T. Breuer) wrote in news:9jdrfc...@news.it.uc3m.es:
> >
> > # DenyHosts lowsecurity.theirs.com *.evil.org evil.org
>
> You say I can do that but your example is based on host names rather than
The example is not _based_ on host names - it shows host names as an
example. Use IP addresses if you prefer. It'll do a gethostbyname(3)
call, which works on ip addresses ...
The gethostbyname() function returns a structure of type hostent for
the given host name. Here name is either a host name, or an IPv4
address in standard dot notation, or an IPv6 address in colon (and
possibly dot) notation.
> ip's. In most cases, I don't know the attacker's host name.
You can look it up, if you really want to know! DNS works in such cases
:).
> > It doesn't matter. If you don't have the key available for the
> > exchange, the password will be asked for.
>
> My idea was to disable login via passwords. If I don't, then it really
Oh, I see.
> doesn't matter if I use RSA or plain passwords since the attackers can
> still user p/w's.
>
> Thanks for your help,
>
> Frank
>
> P.S. It turned out that one of the ip's (168.16.147.50) was registered
> to University System of Georgia. I sent a report to NIC-...@usg.edu so
> we'll see what happens - if anything. As for the Asian domains, I don't
> usually know who to send the report to, whether they'll understand
> English and if they really care.
Worth a try.
Peter
James McIninch
If you have a good root password, it will take some time to crack, but it
won't be impossible. If you do nothing, you know that EVENTUALY you will be
compromised.
Incidentally, if you are still recording attacks, you probably are not
compromised. Once compromised, the attacks should appear to stop.
Regardless, you'd do well to simply require a specific certificat to login
and diable certificateless logins. A USB key is a great way to store such a
certificate for use when you are out and about.
In the interim, however, you probably just want to put in place a firewall
rule that rejects logins from the implicated networks.
Frank Dreyfus wrote:
--
remove .nospam from e-mail address to reply
Matt_left_coast
I would suggest port knocking. If you have ssh open to the world, then then
people the world over can try to get at it. With port knocking you can have
your port CLOSED TO EVERYONE until needed then you can open it with a
combination that can be changed every time you use it. You could also set
it so ssh would open ONLY to the address desired.
P.T. Breuer
> If you have a good root password, it will take some time to crack, but it
> won't be impossible. If you do nothing, you know that EVENTUALY you will be
> compromised.
No you don't, no you won't. Check your numeracy. Calculate how long it
takes to make say one million guesses, and what fraction of the space
of possibilities that is.
Peter
Michel Klijmij
in <Xns9547A7BE01EEAad...@130.133.1.4>:
> Should I be concerned? Is there anything I can do to foil these
> attempts? My first thought was to block access from these domains. In
> the above example, I thought I could probably block 203.186.*.* but after
> reading man sshd, I don't see any way to do this. You can block users
> and/or groups but not ip's.
Step 1: disable root login via sshd . That will make it a lot safer
already.
Step 2: if you know from which IP of ranges you will login, use
/etc/hosts.allow and /etc/hosts.deny to limit the IP addresses that may
connect.
For example:
/etc/hosts.allow:
sshd: .mydomain.com, 10.0.0., 192.168.0.
/etc/hosts.deny:
sshd: ALL
--
Kind regards,
Michel Klijmij
ICQ/MSN in headers http://michel.klijmij.net/
Frank Dreyfus
news:vodUc.26602$TI1.7312@attbi_s52:
> Regardless, you'd do well to simply require a specific certificat to
> login and diable certificateless logins. A USB key is a great way to
> store such a certificate for use when you are out and about.
>
> In the interim, however, you probably just want to put in place a
> firewall rule that rejects logins from the implicated networks.
>
Thanks for the help. I have switched to a rsa login and disabled password
logins. I'm going to see about the USB key idea, it sounds like an
excellent solution.
Thanks, Frank
Robert M. Riches Jr.
> Frank Dreyfus <fdre...@nyw.com> wrote:
>> ...
>> Is there anything I can do to foil these
>> attempts?
>
>
> Blacklist them; contact the admin of their site.
I would never argue with P.T. Breuer, per Bit Twister's
advice. However, there is one caution about reporting abuse
to site admins:
If the site is run _by_ a spammer or cracker, reporting to
the site admin is the _last_ thing you want to do. When
with a former ISP, I made the mistake of reporting spam to
the abuse reporting addresses reported by 'whois', only to
see my incoming spam rate skyrocket. Asian sites appear to
be more likely to be run _by_ spammers. If the site is run
by a cracker, reporting to the site admin, would just get
the cracker mad at you.
Good luck.
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)
Frank Dreyfus
I reported one of the attacks to the State of Georgia/Board of Regents.
The responded: "The compromised server/system (168.16.147.50 ) you reported
in your E-mail below has been secured as of 8/16/2004."
So, it appears that they think a trojan "slaved" the machine and was
hunting for vulnerabilities by trying to ssh into machines with no
passwords for users like root, test, guest, etc.
Is there such a trojan? I had not heard of one.
Thanks, Frank
Eric
iptables works wonders
add this rule and be done with them (run this command):
iptables -A INPUT -p all -s 203.186.0.0/16 -j DROP
That will drop any traffic from their network - when they try to connect it
will just time out with no response.
Its easy to add an exception too if you know the IP in that network you want
to allow (do this instead if you wanted to allow 203.186.10.10 and block
all the others:
iptables -A INPUT -p all -s 203.186.10.10 -j ACCEPT
iptables -A INPUT -p all -s 203.186.0.0/16 -j DROP
Read up on iptables it will really help you out.
Eric
wbarwell
> p...@oboe.it.uc3m.es (P.T. Breuer) wrote in
> news:9jdrfc...@news.it.uc3m.es:
>
>> Frank Dreyfus <fdre...@nyw.com> wrote:
>
>> Run "john" on your password to see if it is secure.
>
> Thanks, I'll try that.
>
>>
>> Eh? You can block any IP you like!
>>
>> # DenyHosts lowsecurity.theirs.com *.evil.org evil.org
>
> You say I can do that but your example is based on host names rather than
> ip's. In most cases, I don't know the attacker's host name.
>
>
Linux Firewalls
Second Edition
Robert L. Zeiglar
This has a script for adding a block ip system.
But refers me to the man block-ip page which neither of
my Mandrake systems has.
This sets up a file /etc/rc.d/rc.firewall.blocked
(Use touch if that file does not exist).
And a rule, iptables -I INPUT -i $external_interface -s $1 -j DROP.
The rule is appended to /etc/rc.d/rc.firewall.blocked,
echo iptables -I INPUT -i $external_interface -s $1 -j DROP >>
/etc/rc.d/rc.firewall.blocked.
Apparently this allows you to have a list of isps that get
globally blocked, if set up in the /etc/rc.d/rc.firewall.blocked file
with correct syntax.
All which means it can be done, its a matter of taking these clues
and looking up man block-ip on google and getting it set up.
The first rule should be near the top of iptable rules.
So yes, it can be done. Not that I am an expert, but the book gives
us a clue to follow up on.
I am not sure of the syntax for etc/rc.d/rc.firewall.block, if it
blocks ISP by name, or DNS numbers, or either, which I suspect it would
which if it uses DNS number it should also allow blocking a range
of numbers. For schnooks operating out of a crooked ISP or stupid ISP
with a block of DNS numbers they can use.
Or you might try something quick and dirty just for giggles.
iptables -I INPUT -i <despised_DNS_number> -s -j DROP.
--
Senator Waxman's searchable database of iraq war lies.
www.house.gov/reform/min/features/iraq_on_the_record/
A good portal to more lies and Bush stupidity is to be found at
www.failureisimpossible.com - Go to the index and go to
"L" for lies. All you need to know about Bush when you
step into the voting booth. Bush is a liar and surrounds
himself with fellow liars.
Cheerful Charlie