PDA

View Full Version : Subject: Newbie with ssh-server running... Hacking attempts againstme...



Santa Claus
05-10-08, 06:07 PM
Dear NG,

Subject: Newbie with ssh-server running... Hacking attempts against
me... I hope this question is appropriate - My log says:


----
May 10 22:21:20 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:20 Apple sshd[1112]: Failed password for invalid user root
from 140.134.28.184 port 56234 ssh2
May 10 22:21:23 Apple sshd[1122]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:23 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:23 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:24 Apple sshd[1122]: Failed password for invalid user root
from 140.134.28.184 port 56582 ssh2
May 10 22:21:27 Apple sshd[1128]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:27 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:27 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:27 Apple sshd[1128]: Failed password for invalid user root
from 140.134.28.184 port 56729 ssh2
May 10 22:21:30 Apple sshd[1131]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:33 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:33 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:33 Apple sshd[1131]: Failed password for invalid user root
from 140.134.28.184 port 56853 ssh2
May 10 22:21:36 Apple sshd[1134]: User root from 140.134.28.184 not
allowed because not listed in AllowUsers
May 10 22:21:44 Apple com.apple.SecurityServer: authinternal failed to
authenticate user root.
May 10 22:21:44 Apple com.apple.SecurityServer: Failed to authorize
right system.login.tty by process /usr/sbin/sshd for authorization
created by /usr/sbin/sshd.
May 10 22:21:44 Apple sshd[1134]: Failed password for invalid user root
from 140.134.28.184 port 57155 ssh2
----

I have a perl-program called "grok" which I use to run a little
python-script, everytime anyone tries to login with a wrong password (it
keeps looking in the log-file for a pattern saying invalid password)...

I find it very entertaining to be able to watch when somebody tries to
hack me. This guy: 140.134.28.184 seem to be very aggressive. I guess it
must be some brute-force thing he's using because now I just saw a lot
of warning-dialogue-boxes popup.

Newbie question: Any chance I can see which passwords he's trying to use?

Newbie question: Why is the hacking attempts originating from different
ports? Starting from 56234 and ending around 56853 according to the log...



I already disabled root login.

Newbie question: Are all hackers so stupid they always try to login my
root account so they never try to guess a username?

Once I'm done entertaining myself, I'm going to make it more secure by
using a non-standard ssh-port.

I think I have something called PAM running.


Newbie question: Is that the thing that makes it slower and slower to
login with wrong passwords with ssh?

Anything else a newbie server admin should be aware of? I believe trying
to hack me is a crime, but I guess nobody tries to report such things to
the local police?



** Posted from http://www.teranews.com **

JD
05-10-08, 08:13 PM
> Newbie question: Are all hackers so stupid they always try to login my
> root account so they never try to guess a username?

Look at it from the other side of the fence. The cracker wants to gain
root as quickly as possible so that he can clear his tracks before anyone
notices his intrusion.

If he goes after a user account first, unless the admin was careless, the
user accounts will be restricted. The cracker still has to find an exploit
to escalate his privileges from there. More time spent, and more chance of
being discovered.

DevilsPGD
05-10-08, 08:53 PM
In message <d6306$48262ab5$28881@news.teranews.com> Santa Claus
<free_presents@greenland> wrote:

>Newbie question: Why is the hacking attempts originating from different
>ports? Starting from 56234 and ending around 56853 according to the log...

Without intending to be rude, the answer is because "that's how TCP/IP
works" -- I'll try to explain, although I may glaze over a few technical
details to make the explanation more understandable.

Every TCP connection needs a unique combination of
srcIP&dstIP&srcPORT&dstPORT, otherwise it's not possible to determine
which packet is associated with a given connection.

With most OSes, srcPORTs are not reused at all until a previous
connection has ended (plus a wait period)

In this particular case, since the srcIP&dstIP&dstPORT are fixed,
srcPORT must be rotated.

This all happens behind the scenes -- Try opening two SSH connections
from another machine into the server and take a look at the source
ports.

>I already disabled root login.
>
>Newbie question: Are all hackers so stupid they always try to login my
>root account so they never try to guess a username?

Virtually all *nix boxes have a "root" account, and it also happens to
have the permissions that the attacker wants. In other words, they're
picking low hanging fruit.

>Once I'm done entertaining myself, I'm going to make it more secure by
>using a non-standard ssh-port.

Security by obscurity. Fun.

That isn't to say that changing the port is a bad idea, but it just
makes you marginally less likely to get hit by a script kiddy.

>Anything else a newbie server admin should be aware of? I believe trying
>to hack me is a crime, but I guess nobody tries to report such things to
>the local police?

You could report it. On a good day, you won't even get laughed at,
although filing the report will be the extent of the activity launched.

In other words, don't bother.

darkog
05-10-08, 09:53 PM
There is an iptables trick you can use to easily address these
attacks. Google it. These attacks are very common. Anyone that is
running an Internet facing SSH server on port 22 will see these
regularly.


On May 10, 7:07 pm, Santa Claus <free_presents@greenland> wrote:
> Dear NG,
>
> Subject: Newbie with ssh-server running... Hacking attempts against
> me... I hope this question is appropriate - My log says:
>
> ----
> May 10 22:21:20 Apple com.apple.SecurityServer: Failed to authorize
> right system.login.tty by process /usr/sbin/sshd for authorization
> created by /usr/sbin/sshd.
> May 10 22:21:20 Apple sshd[1112]: Failed password for invalid user root
> from 140.134.28.184 port 56234 ssh2
> May 10 22:21:23 Apple sshd[1122]: User root from 140.134.28.184 not
> allowed because not listed in AllowUsers
> May 10 22:21:23 Apple com.apple.SecurityServer: authinternal failed to
> authenticate user root.
> May 10 22:21:23 Apple com.apple.SecurityServer: Failed to authorize
> right system.login.tty by process /usr/sbin/sshd for authorization
> created by /usr/sbin/sshd.
> May 10 22:21:24 Apple sshd[1122]: Failed password for invalid user root
> from 140.134.28.184 port 56582 ssh2
> May 10 22:21:27 Apple sshd[1128]: User root from 140.134.28.184 not
> allowed because not listed in AllowUsers
> May 10 22:21:27 Apple com.apple.SecurityServer: authinternal failed to
> authenticate user root.
> May 10 22:21:27 Apple com.apple.SecurityServer: Failed to authorize
> right system.login.tty by process /usr/sbin/sshd for authorization
> created by /usr/sbin/sshd.
> May 10 22:21:27 Apple sshd[1128]: Failed password for invalid user root
> from 140.134.28.184 port 56729 ssh2
> May 10 22:21:30 Apple sshd[1131]: User root from 140.134.28.184 not
> allowed because not listed in AllowUsers
> May 10 22:21:33 Apple com.apple.SecurityServer: authinternal failed to
> authenticate user root.
> May 10 22:21:33 Apple com.apple.SecurityServer: Failed to authorize
> right system.login.tty by process /usr/sbin/sshd for authorization
> created by /usr/sbin/sshd.
> May 10 22:21:33 Apple sshd[1131]: Failed password for invalid user root
> from 140.134.28.184 port 56853 ssh2
> May 10 22:21:36 Apple sshd[1134]: User root from 140.134.28.184 not
> allowed because not listed in AllowUsers
> May 10 22:21:44 Apple com.apple.SecurityServer: authinternal failed to
> authenticate user root.
> May 10 22:21:44 Apple com.apple.SecurityServer: Failed to authorize
> right system.login.tty by process /usr/sbin/sshd for authorization
> created by /usr/sbin/sshd.
> May 10 22:21:44 Apple sshd[1134]: Failed password for invalid user root
> from 140.134.28.184 port 57155 ssh2
> ----
>
> I have a perl-program called "grok" which I use to run a little
> python-script, everytime anyone tries to login with a wrong password (it
> keeps looking in the log-file for a pattern saying invalid password)...
>
> I find it very entertaining to be able to watch when somebody tries to
> hack me. This guy: 140.134.28.184 seem to be very aggressive. I guess it
> must be some brute-force thing he's using because now I just saw a lot
> of warning-dialogue-boxes popup.
>
> Newbie question: Any chance I can see which passwords he's trying to use?
>
> Newbie question: Why is the hacking attempts originating from different
> ports? Starting from 56234 and ending around 56853 according to the log...
>
> I already disabled root login.
>
> Newbie question: Are all hackers so stupid they always try to login my
> root account so they never try to guess a username?
>
> Once I'm done entertaining myself, I'm going to make it more secure by
> using a non-standard ssh-port.
>
> I think I have something called PAM running.
>
> Newbie question: Is that the thing that makes it slower and slower to
> login with wrong passwords with ssh?
>
> Anything else a newbie server admin should be aware of? I believe trying
> to hack me is a crime, but I guess nobody tries to report such things to
> the local police?
>
> ** Posted fromhttp://www.teranews.com**

Wolfgang Kueter
05-11-08, 03:30 AM
Santa Claus wrote:

> I find it very entertaining to be able to watch when somebody tries to
> hack me. This guy: 140.134.28.184 seem to be very aggressive.

'This guy' is a computer that runs - either deliberately or unwillingly - a
program which scans for ssh servers and tries to log into generally
existing accounts using a password list.

> I guess it
> must be some brute-force thing he's using because now I just saw a lot
> of warning-dialogue-boxes popup.

It is automated, originating either from scipt kiddie activity or from a
hacked box.

> Newbie question: Any chance I can see which passwords he's trying to use?

'He' does not exist. 'It' (= the program) would be correct.

> Newbie question: Are all hackers so stupid they always try to login my
> root account so they never try to guess a username?

In this case we are talking about a computer program, not about a human
beeing.

> Anything else a newbie server admin should be aware of? I believe trying
> to hack me is a crime, but I guess nobody tries to report such things to
> the local police?

wolfgang@zaphod:~> host 140.134.28.184
184.28.134.140.in-addr.arpa domain name pointer eacm.ee.fcu.edu.tw.

The box seems to be located at a university in Taiwan, so the local police
can do nothing about it. As I said the box is either hacked or some student
is playing around. You can try to contact the abuse department at Feng Chia
University in Taiwan but probably not much will happen, ssh scans are usual
network noise these days.

Wolfgang

Santa Claus
05-11-08, 06:33 AM
darkog wrote:
> There is an iptables trick you can use to easily address these
> attacks. Google it. These attacks are very common. Anyone that is
> running an Internet facing SSH server on port 22 will see these
> regularly.


Something like this:
http://www.newartisans.com/blog_files/tricks.with.iptables.php

?
** Posted from http://www.teranews.com **

Santa Claus
05-11-08, 06:38 AM
Wolfgang Kueter wrote:
> Santa Claus wrote:
>
>> I find it very entertaining to be able to watch when somebody tries to
>> hack me. This guy: 140.134.28.184 seem to be very aggressive.
>
> 'This guy' is a computer that runs - either deliberately or unwillingly - a
> program which scans for ssh servers and tries to log into generally
> existing accounts using a password list.

The computer is not doing it "by itself", you know. I know that a
computer is doing something, but there's a man behind the scenes, you
know... This man wants to know how to get into my computer, you know...
It's not like the computer tries to hack me "for fun" or anything...

>> I guess it
>> must be some brute-force thing he's using because now I just saw a lot
>> of warning-dialogue-boxes popup.
>
> It is automated, originating either from scipt kiddie activity or from a
> hacked box.

Ofcourse it is automated.

>> Newbie question: Any chance I can see which passwords he's trying to use?
>
> 'He' does not exist. 'It' (= the program) would be correct.

I'm asking about if there's any way I can see which passwords are used?!?

Again, it's not like the computer is doing this because "it feels like
doing so". There's a man behind the hacking attempts.

>> Newbie question: Are all hackers so stupid they always try to login my
>> root account so they never try to guess a username?
>
> In this case we are talking about a computer program, not about a human
> beeing.

SIGH! But other people wrote that they're just going for dumb server
admins, because root login is disabled here - like I guess it is many
other places.

>> Anything else a newbie server admin should be aware of? I believe trying
>> to hack me is a crime, but I guess nobody tries to report such things to
>> the local police?
>
> wolfgang@zaphod:~> host 140.134.28.184
> 184.28.134.140.in-addr.arpa domain name pointer eacm.ee.fcu.edu.tw.
>
> The box seems to be located at a university in Taiwan, so the local police
> can do nothing about it. As I said the box is either hacked or some student
> is playing around. You can try to contact the abuse department at Feng Chia
> University in Taiwan but probably not much will happen, ssh scans are usual
> network noise these days.

You're right...
** Posted from http://www.teranews.com **

Santa Claus
05-11-08, 06:40 AM
JD wrote:
>> Newbie question: Are all hackers so stupid they always try to login my
>> root account so they never try to guess a username?
>
> Look at it from the other side of the fence. The cracker wants to gain
> root as quickly as possible so that he can clear his tracks before anyone
> notices his intrusion.

It's just impossible for him to login with root here, so I'm laughing a
bit over it...

Let's say he got in: How would he clear his tracks?

1) Delete the log file?
2) Edit the log file manually?
3) Something else clever?

> If he goes after a user account first, unless the admin was careless, the
> user accounts will be restricted. The cracker still has to find an exploit
> to escalate his privileges from there. More time spent, and more chance of
> being discovered.

He'll get nowhere with my server, trying to hack root...
** Posted from http://www.teranews.com **

Nico Kadel-Garcia
05-11-08, 06:56 AM
Santa Claus wrote:
> JD wrote:
>>> Newbie question: Are all hackers so stupid they always try to login
>>> my root account so they never try to guess a username?
>>
>> Look at it from the other side of the fence. The cracker wants to gain
>> root as quickly as possible so that he can clear his tracks before anyone
>> notices his intrusion.
>
> It's just impossible for him to login with root here, so I'm laughing a
> bit over it...


> Let's say he got in: How would he clear his tracks?
>
> 1) Delete the log file?
> 2) Edit the log file manually?
> 3) Something else clever?

Even if he's not completely successful, the time wasted tracking him back and
time offline while you repair what he damaged can be extremely expensive.

dd if=/dev/zero of=/dev/hda &
dd if=/dev/zero of=/dev/sda &
find /var -type f -exec dd if=/dev/zero of=$name &

Etc.

Can you log in as root, remotely? Can he steal your passwords or passkeys? Are
you *SURE* your sshd or httpd or SNMP are all really securfe?

>
>> If he goes after a user account first, unless the admin was careless, the
>> user accounts will be restricted. The cracker still has to find an
>> exploit
>> to escalate his privileges from there. More time spent, and more
>> chance of
>> being discovered.
>
> He'll get nowhere with my server, trying to hack root...
> ** Posted from http://www.teranews.com **

Have you ever read up on 'zero-day' exploits, and cracking kits?

Santa Claus
05-11-08, 07:35 AM
Nico Kadel-Garcia wrote:
> Santa Claus wrote:
-snip-

>> It's just impossible for him to login with root here, so I'm laughing
>> a bit over it...
>
>
>> Let's say he got in: How would he clear his tracks?
>>
>> 1) Delete the log file?
>> 2) Edit the log file manually?
>> 3) Something else clever?
>
> Even if he's not completely successful, the time wasted tracking him
> back and time offline while you repair what he damaged can be extremely
> expensive.

It's just a home computer server. I don't have company secrets or so on
it, so I'm just "practicing" and listening to advice from experts...

> dd if=/dev/zero of=/dev/hda &
> dd if=/dev/zero of=/dev/sda &
> find /var -type f -exec dd if=/dev/zero of=$name &

I think the last line would be the best. I would reinstall my OS on the
computer, if anyone did something like this. But I thought a hacker
would be more clever than you propose:

I would definately figure out that somebody had been on my system if all
files in /var were missing suddenly. And then the hacker couldn't come
back - I thought he would clear his tracks and keep a backdoor open -
how could/would he do something like that?

> Etc.

Thank you.

> Can you log in as root, remotely? Can he steal your passwords or
> passkeys? Are you *SURE* your sshd or httpd or SNMP are all really securfe?

1) Root login is impossible because I disabled it in sshd_config. But I
guess people can login with user accounts and sudo (they would have to
guess two passwords). Only 1 user account is allowed to login
(AllowedUsers) - and this is myself. Everytime my username logs in, a
python-script is ran that popups a warning on my desktop. So when I'm
sitting in front of my pc I can see hacking attempts in real-time.

When I'm away, I don't see them before I get home (I'm home every
evening at least).


2) I don't know if he can steal my passwords/passkeys. Even if he looked
in my garbage he wouldn't see such things. I don't know if he could
sniff it somehow...


3) I don't have httpd running - only have 1 ssh-server running now (to
practice, and learning how to protect myself - once I'm good at that, I
could perhaps run something more)... I disabled X11-forwarding.


4) SNMP? Never heard of it. Do I have to worry?


>>> If he goes after a user account first, unless the admin was careless,
>>> the
>>> user accounts will be restricted. The cracker still has to find an
>>> exploit
>>> to escalate his privileges from there. More time spent, and more
>>> chance of
>>> being discovered.
>>
>> He'll get nowhere with my server, trying to hack root...
>> ** Posted from http://www.teranews.com **
>
> Have you ever read up on 'zero-day' exploits, and cracking kits?

Not really. I'm using:

# telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.7
^C^C
Connection closed by foreign host.


So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006


Do I have to worry or upgrade? I just saw on openssh.com that there's a
new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.


I believe(d) that SSH even though it is from 2006, should be pretty
secure? Else I can upgrade in the coming days...
** Posted from http://www.teranews.com **

Wolfgang Kueter
05-11-08, 07:42 AM
Santa Claus wrote:

> Wolfgang Kueter wrote:

>> 'This guy' is a computer that runs - either deliberately or unwillingly -
>> a program which scans for ssh servers and tries to log into generally
>> existing accounts using a password list.
>
> The computer is not doing it "by itself", you know.

Yes, I know.

> I know that a
> computer is doing something, but there's a man behind the scenes, you
> know...

Yes, somewhere there probably is. But he might control the box, from which
the scans come, from another box, that is also remotely controlled and/or
hacked and so on. The box 'attcking' you might be a member of a botnet or
running some insecure web application or whatever.

> This man wants to know how to get into my computer, you know...

This is _not_ directed deliberately towards you or your computer. it is an
automated scan that lookes for an sshd, which is accessible from the
public. Any box running sshd accessible from the public will see these
login attempts these days.

> It's not like the computer tries to hack me "for fun" or anything...

The script searches huge netblocks for listening ssh servers and tries to
log in, Besides root the usual system accounts like webmaster, wwwrun, news
etc. are normally probed by those scripts.

> Again, it's not like the computer is doing this because "it feels like
> doing so". There's a man behind the hacking attempts.

Correct but there is hardly any use in knowing that.

The way to deal with is:

- Disable sshd if you don't need it
- allow ssh only from certain IP-adresses
- Disable root login via ssh
- use strong passwords for all other accounts
- better allow ssh logins only with keys

and forget about tracking down script kiddies. While watching logs can be
quite some fun, on a well secured system paying much attention to those
scans is mostly a waste of time.

Wolfgang

Santa Claus
05-11-08, 07:58 AM
Wolfgang Kueter wrote:
> The way to deal with is:
>
> - Disable sshd if you don't need it
> - allow ssh only from certain IP-adresses
> - Disable root login via ssh
> - use strong passwords for all other accounts
> - better allow ssh logins only with keys
>
> and forget about tracking down script kiddies. While watching logs can be
> quite some fun, on a well secured system paying much attention to those
> scans is mostly a waste of time.

I appreciate all your talk about something else, but:

I'm asking about if there's any way I can see which passwords are
used?!? For educational purposes for myself...
** Posted from http://www.teranews.com **

Bit Twister
05-11-08, 08:27 AM
On Sun, 11 May 2008 14:35:01 +0200, Santa Claus wrote:

> It's just impossible for him to login with root

Does not have to be password crack, can be an overflow exploit in
kernel or ssh, or any other service......

> It's just a home computer server. I don't have company secrets or so on

Big Freaking Deal. Any account/passwords stolen might be worth some money.
Can be worth much more when system gets cracked.

Let's say it get used to launder stolen credit cards.
Or used in a DDOS attack of your government's web site.
Or used as a transfer point for child porn.
Or used to attack the electrical grid control system.

I'll give you three guess as to who goes downtown for free room and board
at the barbed wire hotel.

Nico Kadel-Garcia
05-11-08, 08:53 AM
Santa Claus wrote:
> Nico Kadel-Garcia wrote:
>> Santa Claus wrote:
> -snip-
>
>>> It's just impossible for him to login with root here, so I'm laughing
>>> a bit over it...
>>
>>
>>> Let's say he got in: How would he clear his tracks?
>>>
>>> 1) Delete the log file?
>>> 2) Edit the log file manually?
>>> 3) Something else clever?
>>
>> Even if he's not completely successful, the time wasted tracking him
>> back and time offline while you repair what he damaged can be
>> extremely expensive.
>
> It's just a home computer server. I don't have company secrets or so on
> it, so I'm just "practicing" and listening to advice from experts...
>
>> dd if=/dev/zero of=/dev/hda &
>> dd if=/dev/zero of=/dev/sda &
>> find /var -type f -exec dd if=/dev/zero of=$name &
>
> I think the last line would be the best. I would reinstall my OS on the
> computer, if anyone did something like this. But I thought a hacker
> would be more clever than you propose:
>
> I would definately figure out that somebody had been on my system if all
> files in /var were missing suddenly. And then the hacker couldn't come
> back - I thought he would clear his tracks and keep a backdoor open -
> how could/would he do something like that?

Oh, one could look in /etc/mtab for the list of mounted partitions, and do
'fdisk -l' to look for ones that aren't mounted. But you get the hint. Not all
crackers want to be pleasant and graceful, some of them are quite destructive.
Take a look at the histories of Kevin Mitnick and Robert Morris for the kinds
of damage they did, incidentally, to systems they hacked.

>> Etc.
>
> Thank you.
>
>> Can you log in as root, remotely? Can he steal your passwords or
>> passkeys? Are you *SURE* your sshd or httpd or SNMP are all really
>> securfe?
>
> 1) Root login is impossible because I disabled it in sshd_config. But I
> guess people can login with user accounts and sudo (they would have to
> guess two passwords). Only 1 user account is allowed to login
> (AllowedUsers) - and this is myself. Everytime my username logs in, a
> python-script is ran that popups a warning on my desktop. So when I'm
> sitting in front of my pc I can see hacking attempts in real-time.

Then you can log in as root, remotely. A cracker might steal or crack user
access, gain local account access this way, and run a local crack. I'm not
saying this is likely against you, you might be cautious: but simply blocking
root in sshd_config isn't enough.

OpenSSH has also had a number of remote exploits over the years: it's a vast
improvement over rsh or telnet, but that doesn't make it complete.

> When I'm away, I don't see them before I get home (I'm home every
> evening at least).

By which point, your disk might be zeroed.

> 2) I don't know if he can steal my passwords/passkeys. Even if he looked
> in my garbage he wouldn't see such things. I don't know if he could
> sniff it somehow...

This is where experience and security training helps. Default command-line
Subversion tools, for example, keep passwords in clear-text. So do Japper
servers, and if you're using standard FTP or unencrypted HTTP to provide
account access, well, they can be sniffed.

> 3) I don't have httpd running - only have 1 ssh-server running now (to
> practice, and learning how to protect myself - once I'm good at that, I
> could perhaps run something more)... I disabled X11-forwarding.

If you want to learn additional protection techniques, take a look at port
knocking running on a non-standard port, the use of various RSA based security
keys, and other more robust techniques.

> 4) SNMP? Never heard of it. Do I have to worry?

Probably not: SNMP is primarily a monitoring technology, used to monitor
network and disk and other system characteristics. Some people use "SNMP
traps" to trigger actions on a server, and that can be fun to configure properly.

>
>>>> If he goes after a user account first, unless the admin was
>>>> careless, the
>>>> user accounts will be restricted. The cracker still has to find an
>>>> exploit
>>>> to escalate his privileges from there. More time spent, and more
>>>> chance of
>>>> being discovered.
>>>
>>> He'll get nowhere with my server, trying to hack root...
>>> ** Posted from http://www.teranews.com **
>>
>> Have you ever read up on 'zero-day' exploits, and cracking kits?
>
> Not really. I'm using:
>
> # telnet localhost 22
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> SSH-2.0-OpenSSH_4.7
> ^C^C
> Connection closed by foreign host.
>
>
> So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
>
>
> Do I have to worry or upgrade? I just saw on openssh.com that there's a
> new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.

You need to stay up to date with patches, not necessarily the primary version.
They started adding the capability for a chroot cage at about 4.7, after years
of people like me lobbying and publishing patches to provide one.

> I believe(d) that SSH even though it is from 2006, should be pretty
> secure? Else I can upgrade in the coming days...
> ** Posted from http://www.teranews.com **

Well, it depends on what you want to do. If you've got people accessing your
site versus 'sftp', or scp with tools like 'WinSCP', you might want to update
to version 5.0 and set up a real chroot cage to keep them away from the rest
of your system.

Jens Hoffmann
05-11-08, 08:57 AM
> I'm asking about if there's any way I can see which passwords are
> used?!? For educational purposes for myself...

play around with netcat.

Cheers,
Jens

JD
05-11-08, 09:07 AM
On Sun, 11 May 2008 13:40:50 +0200, Santa Claus wrote:

> It's just impossible for him to login with root here, so I'm laughing a
> bit over it...

One should not be overconfident. 100% security and usable machine is a bit
of an oxymoron. Nothing is impossible. A better description would be "it
is extremely difficult for him to login in as root". Even an idiot
scriptkiddie may find a crack in your armor if he runs enough scripts for
a long enough time. The weakness he finds may not be your password. It
could be a zero-day exploit in some other program that gives him root.

>
> Let's say he got in: How would he clear his tracks?
>
> 1) Delete the log file?
> 2) Edit the log file manually?
> 3) Something else clever?

Any or all of the above. Once he gains root, *nothing* on your server can
be trusted. At that point, if you suspected the intrusion, you can't use
any tools on that machine to verify that an intrusion happened. Any or all
executables may have been altered or replaced with his own modified and
backdoored copies.

>
> He'll get nowhere with my server, trying to hack root...

See above note about overconfidence. :)

Sebastian G.
05-11-08, 10:14 AM
JD wrote:

> On Sun, 11 May 2008 13:40:50 +0200, Santa Claus wrote:
>
>> It's just impossible for him to login with root here, so I'm laughing a
>> bit over it...
>
> One should not be overconfident. 100% security and usable machine is a bit
> of an oxymoron.


It actually isn't, since both can work hand-in-hand.

> Nothing is impossible.


Unlike in the real work, computers do have strict notions of decisions.
There is no way to bypass an

if (entered_password equals system_password)
return AUTHENTICATION_SUCCESSFUL
else
return ACCESS_DENIED

by pushing it with hammer, while the possibility of resorting to throwing a
nuclear bomb at it. There is no equivalent of "if brute force doesn't solve
to problem, use more brute force", and the space of possible inputs,
outputs, functions and states is enumerable - I gave you a very trivial
example above.

Modern operating system or modern hardware can strictly and fully enforce
every possible policy you implement against programs.

> Even an idiot

> scriptkiddie may find a crack in your armor if he runs enough scripts for
> a long enough time.


Assuming that there is a crack (not so likely for a relative small SSH
server), that the exploit is applicable (if he'd be required to get an
unprivileged logon first and can't get it, the attacks stops instantly),
that unknown parameters can be guessed with sufficient accuracy...

> The weakness he finds may not be your password. It
> could be a zero-day exploit in some other program that gives him root.


And how should he get the exploit executed on the machine in first place, if
no logon is ever granted to him? This would at least require user
interaction and totally unrelated internet-facing application.

> Any or all of the above. Once he gains root, *nothing* on your server can
> be trusted.


Not true, please take a look on OpenBSD's global security levels. Once
raised, global restrictions apply even to root, and can't be lowered any
more in any way (albeit an attack by the user based upon physical access,
like booting a Live CD to bypass the security restrictions). Most likely
such a configuration could be applied to Windows Vista as well (which makes
great preservations on locking out even the administrator from doing
legitimate things), though this OS has its very own implementation problems
that already make it unsuitable in any security context.

JD
05-11-08, 11:06 AM
On Sun, 11 May 2008 17:14:45 +0200, Sebastian G. wrote:

> JD wrote:
>
>> On Sun, 11 May 2008 13:40:50 +0200, Santa Claus wrote:
>>
>>>
>>
>> One should not be overconfident. 100% security and usable machine is a bit
>> of an oxymoron.
>
>
> It actually isn't, since both can work hand-in-hand.

I was looking at it in terms of MS and the NT C2 security certification.
If no one can access the server, then it is 100% secured. The more ways
there are to access it, the greater the potential for unauthorised access.
Higher security usually translates to less user friendly.


> > Even an idiot
>
>> scriptkiddie may find a crack in your armor if he runs enough scripts for
>> a long enough time.
>
>
> Assuming that there is a crack (not so likely for a relative small SSH
> server), that the exploit is applicable (if he'd be required to get an
> unprivileged logon first and can't get it, the attacks stops instantly),
> that unknown parameters can be guessed with sufficient accuracy...

Correct, which is why I stated /may/ find a crack in the armor.
>
>> The weakness he finds may not be your password. It
>> could be a zero-day exploit in some other program that gives him root.
>
>
> And how should he get the exploit executed on the machine in first place, if
> no logon is ever granted to him? This would at least require user
> interaction and totally unrelated internet-facing application.

How do exploits get executed then? Otherwise they wouldn't be exploits.

>
>> Any or all of the above. Once he gains root, *nothing* on your server can
>> be trusted.
>
>
> Not true, please take a look on OpenBSD's global security levels. Once
> raised, global restrictions apply even to root, and can't be lowered any
> more in any way (albeit an attack by the user based upon physical access,
> like booting a Live CD to bypass the security restrictions). Most likely
> such a configuration could be applied to Windows Vista as well (which makes
> great preservations on locking out even the administrator from doing
> legitimate things), though this OS has its very own implementation problems
> that already make it unsuitable in any security context.

You trust things more than I would if I suspected a successful compromise.

Santa Claus
05-11-08, 11:37 AM
Nico Kadel-Garcia wrote:
>>> Have you ever read up on 'zero-day' exploits, and cracking kits?
>>
>> Not really. I'm using:
>>
>> # telnet localhost 22
>> Trying 127.0.0.1...
>> Connected to localhost.
>> Escape character is '^]'.
>> SSH-2.0-OpenSSH_4.7
>> ^C^C
>> Connection closed by foreign host.
>>
>>
>> So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
>>
>>
>> Do I have to worry or upgrade? I just saw on openssh.com that there's
>> a new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.
>
> You need to stay up to date with patches, not necessarily the primary
> version. They started adding the capability for a chroot cage at about
> 4.7, after years of people like me lobbying and publishing patches to
> provide one.
>
>> I believe(d) that SSH even though it is from 2006, should be pretty
>> secure? Else I can upgrade in the coming days...
>> ** Posted from http://www.teranews.com **
>
> Well, it depends on what you want to do. If you've got people accessing
> your site versus 'sftp', or scp with tools like 'WinSCP', you might want
> to update to version 5.0 and set up a real chroot cage to keep them away
> from the rest of your system.

Ok. Thanks - I update when I get more time.

** Posted from http://www.teranews.com **

Nico Kadel-Garcia
05-11-08, 12:44 PM
Sebastian G. wrote:
> JD wrote:
>
>> On Sun, 11 May 2008 13:40:50 +0200, Santa Claus wrote:
>>
>>> It's just impossible for him to login with root here, so I'm laughing
>>> a bit over it...
>>
>> One should not be overconfident. 100% security and usable machine is a
>> bit
>> of an oxymoron.
>
>
> It actually isn't, since both can work hand-in-hand.
>
>> Nothing is impossible.
>
>
> Unlike in the real work, computers do have strict notions of decisions.
> There is no way to bypass an
>
> if (entered_password equals system_password)
> return AUTHENTICATION_SUCCESSFUL
> else
> return ACCESS_DENIED
>
> by pushing it with hammer, while the possibility of resorting to
> throwing a nuclear bomb at it. There is no equivalent of "if brute force
> doesn't solve to problem, use more brute force", and the space of
> possible inputs, outputs, functions and states is enumerable - I gave
> you a very trivial example above.

Oh. Oh, my. You don't get out much, do you?

> Modern operating system or modern hardware can strictly and fully
> enforce every possible policy you implement against programs.

As shown above. Given the complexity of many contemporary services, and the
ease of making a security mistake in supporting complex new services, such a
claim is not founded on experience or in fact.


> > Even an idiot
>
>> scriptkiddie may find a crack in your armor if he runs enough scripts for
>> a long enough time.
>
>
> Assuming that there is a crack (not so likely for a relative small SSH
> server), that the exploit is applicable (if he'd be required to get an
> unprivileged logon first and can't get it, the attacks stops instantly),
> that unknown parameters can be guessed with sufficient accuracy...

Well, a small and lightly used SSH server, sure. But what about your
passwords? What about remote keystroke loggers on whatever machine you connect
from? What about the rare, but historically problematic, exploits of unpatched
OpenSSH?

>> The weakness he finds may not be your password. It
>> could be a zero-day exploit in some other program that gives him root.
>
>
> And how should he get the exploit executed on the machine in first
> place, if no logon is ever granted to him? This would at least require
> user interaction and totally unrelated internet-facing application.

See above.

>> Any or all of the above. Once he gains root, *nothing* on your server can
>> be trusted.
>
>
> Not true, please take a look on OpenBSD's global security levels. Once
> raised, global restrictions apply even to root, and can't be lowered any
> more in any way (albeit an attack by the user based upon physical
> access, like booting a Live CD to bypass the security restrictions).
> Most likely such a configuration could be applied to Windows Vista as
> well (which makes great preservations on locking out even the
> administrator from doing legitimate things), though this OS has its very
> own implementation problems that already make it unsuitable in any
> security context.

Similar levels of control are possible with SELinux. But have you actually
carefully gone through and done this?

If he has root, he can usually write directly to disk. This is difficult to
prevent. OpenBSD's history of high levels of internal security are good, but
their history of accepting community submitted patches is not, nor is Theo de
Raadt known to play that well with others. It leads to potential weaknesses:
if you need to run a service that is not integral to OpenBSD (such as
Subversion), you're at the mercy of the other, less security minded developers.

Nico Kadel-Garcia
05-11-08, 12:46 PM
Santa Claus wrote:
> Nico Kadel-Garcia wrote:
>>>> Have you ever read up on 'zero-day' exploits, and cracking kits?
>>>
>>> Not really. I'm using:
>>>
>>> # telnet localhost 22
>>> Trying 127.0.0.1...
>>> Connected to localhost.
>>> Escape character is '^]'.
>>> SSH-2.0-OpenSSH_4.7
>>> ^C^C
>>> Connection closed by foreign host.
>>>
>>>
>>> So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
>>>
>>>
>>> Do I have to worry or upgrade? I just saw on openssh.com that there's
>>> a new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.
>>
>> You need to stay up to date with patches, not necessarily the primary
>> version. They started adding the capability for a chroot cage at about
>> 4.7, after years of people like me lobbying and publishing patches to
>> provide one.
>>
>>> I believe(d) that SSH even though it is from 2006, should be pretty
>>> secure? Else I can upgrade in the coming days...
>>> ** Posted from http://www.teranews.com **
>>
>> Well, it depends on what you want to do. If you've got people
>> accessing your site versus 'sftp', or scp with tools like 'WinSCP',
>> you might want to update to version 5.0 and set up a real chroot cage
>> to keep them away from the rest of your system.
>
> Ok. Thanks - I update when I get more time.
>
> ** Posted from http://www.teranews.com **

No sweat. If you need to give user file-access and want an easier, more
managable 'chroot' configuration, seriously consider WebDAV over HTTPS. It
handles symlinks, which SCP and sftp do not, and has much better resolution
over upload, download, and filesystem access.

Sebastian G.
05-11-08, 01:08 PM
JD wrote:


> I was looking at it in terms of MS and the NT C2 security certification.
> If no one can access the server, then it is 100% secured. The more ways
> there are to access it, the greater the potential for unauthorised access.
> Higher security usually translates to less user friendly.


Higher security in terms of discretionary access control only translates to
higher isolation of user contexts. Within a user context, any application is
free to do whatever unprivileged action it requires to do its job.

>> And how should he get the exploit executed on the machine in first place, if
>> no logon is ever granted to him? This would at least require user
>> interaction and totally unrelated internet-facing application.
>
> How do exploits get executed then? Otherwise they wouldn't be exploits.


This would limit the attack vector to all protocol action performed before
login. Unless you're too stupid to implement CRC32 correctly, I'd say this
is a non-issue.


> You trust things more than I would if I suspected a successful compromise.


The kernel is always the ultimate authority in the system. If it decides
that root isn't the ueber-privileged user any more, it can enforce various
limitations. One is that the kernel's logging facility is completely
isolated, and all privileges that root could use to get access to kernel
memory or compromising the kernel are removed. That is, root might still
overwrite the privileges of any user, can change the system time, can debug
other processes, can read disks in raw mode etc. but he can't load any
drivers, do any kernel debugging, change the RTC time, write to the disk in
raw mode, or bypass access checks on the kernel's files and objects.

JD
05-11-08, 02:09 PM
On Sun, 11 May 2008 20:08:35 +0200, Sebastian G. wrote:

> JD wrote:
>
>> You trust things more than I would if I suspected a successful compromise.
>
>
> The kernel is always the ultimate authority in the system. If it decides
> that root isn't the ueber-privileged user any more, it can enforce various
> limitations. One is that the kernel's logging facility is completely
> isolated, and all privileges that root could use to get access to kernel
> memory or compromising the kernel are removed. That is, root might still
> overwrite the privileges of any user, can change the system time, can debug
> other processes, can read disks in raw mode etc. but he can't load any
> drivers, do any kernel debugging, change the RTC time, write to the disk in
> raw mode, or bypass access checks on the kernel's files and objects.

I understand what you mean now. We just differ on our definitions.

goarilla
05-11-08, 03:15 PM
Nico Kadel-Garcia wrote:
> Santa Claus wrote:
>> Nico Kadel-Garcia wrote:
>>>>> Have you ever read up on 'zero-day' exploits, and cracking kits?
>>>>
>>>> Not really. I'm using:
>>>>
>>>> # telnet localhost 22
>>>> Trying 127.0.0.1...
>>>> Connected to localhost.
>>>> Escape character is '^]'.
>>>> SSH-2.0-OpenSSH_4.7
>>>> ^C^C
>>>> Connection closed by foreign host.
>>>>
>>>>
>>>> So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
>>>>
>>>>
>>>> Do I have to worry or upgrade? I just saw on openssh.com that
>>>> there's a new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.
>>>
>>> You need to stay up to date with patches, not necessarily the primary
>>> version. They started adding the capability for a chroot cage at
>>> about 4.7, after years of people like me lobbying and publishing
>>> patches to provide one.
>>>
>>>> I believe(d) that SSH even though it is from 2006, should be pretty
>>>> secure? Else I can upgrade in the coming days...
>>>> ** Posted from http://www.teranews.com **
>>>
>>> Well, it depends on what you want to do. If you've got people
>>> accessing your site versus 'sftp', or scp with tools like 'WinSCP',
>>> you might want to update to version 5.0 and set up a real chroot cage
>>> to keep them away from the rest of your system.
>>
>> Ok. Thanks - I update when I get more time.
>>
>> ** Posted from http://www.teranews.com **
>
> No sweat. If you need to give user file-access and want an easier, more
> managable 'chroot' configuration, seriously consider WebDAV over HTTPS.
> It handles symlinks, which SCP and sftp do not, and has much better
> resolution over upload, download, and filesystem access.
any good pointers on how to set it up i tried it once (few months back)
but couldn't even get a directory listen altough basic authentication
did work (without https)

Nico Kadel-Garcia
05-11-08, 05:27 PM
goarilla <"kevin<punt>paulus|"@|skynet punt> wrote:
> Nico Kadel-Garcia wrote:
>> Santa Claus wrote:
>>> Nico Kadel-Garcia wrote:
>>>>>> Have you ever read up on 'zero-day' exploits, and cracking kits?
>>>>>
>>>>> Not really. I'm using:
>>>>>
>>>>> # telnet localhost 22
>>>>> Trying 127.0.0.1...
>>>>> Connected to localhost.
>>>>> Escape character is '^]'.
>>>>> SSH-2.0-OpenSSH_4.7
>>>>> ^C^C
>>>>> Connection closed by foreign host.
>>>>>
>>>>>
>>>>> So its: OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
>>>>>
>>>>>
>>>>> Do I have to worry or upgrade? I just saw on openssh.com that
>>>>> there's a new version: OpenSSH 5.0/5.0p1 released Apr 3, 2008.
>>>>
>>>> You need to stay up to date with patches, not necessarily the
>>>> primary version. They started adding the capability for a chroot
>>>> cage at about 4.7, after years of people like me lobbying and
>>>> publishing patches to provide one.
>>>>
>>>>> I believe(d) that SSH even though it is from 2006, should be pretty
>>>>> secure? Else I can upgrade in the coming days...
>>>>> ** Posted from http://www.teranews.com **
>>>>
>>>> Well, it depends on what you want to do. If you've got people
>>>> accessing your site versus 'sftp', or scp with tools like 'WinSCP',
>>>> you might want to update to version 5.0 and set up a real chroot
>>>> cage to keep them away from the rest of your system.
>>>
>>> Ok. Thanks - I update when I get more time.
>>>
>>> ** Posted from http://www.teranews.com **
>>
>> No sweat. If you need to give user file-access and want an easier,
>> more managable 'chroot' configuration, seriously consider WebDAV over
>> HTTPS. It handles symlinks, which SCP and sftp do not, and has much
>> better resolution over upload, download, and filesystem access.
> any good pointers on how to set it up i tried it once (few months back)
> but couldn't even get a directory listen altough basic authentication
> did work (without https)


I'm surprised it was difficult. I just read the documentation, and was careful
to use 'Directory' rather than 'Location' based settings, and it worked from
the limited documentation built into HTTPD.

Sebastian G.
05-11-08, 06:52 PM
JD wrote:

> On Sun, 11 May 2008 20:08:35 +0200, Sebastian G. wrote:
>
>> JD wrote:
>>
>>> You trust things more than I would if I suspected a successful compromise.
>>
>> The kernel is always the ultimate authority in the system. If it decides
>> that root isn't the ueber-privileged user any more, it can enforce various
>> limitations. One is that the kernel's logging facility is completely
>> isolated, and all privileges that root could use to get access to kernel
>> memory or compromising the kernel are removed. That is, root might still
>> overwrite the privileges of any user, can change the system time, can debug
>> other processes, can read disks in raw mode etc. but he can't load any
>> drivers, do any kernel debugging, change the RTC time, write to the disk in
>> raw mode, or bypass access checks on the kernel's files and objects.
>
> I understand what you mean now. We just differ on our definitions.


I didn't claim that this model or approach is perfect or even a good idea.
But it's a non-theoretical productive OS where in a certain configuration
there simply is no ultimately powerful principal, and root is merely a
normal user with some privileges to manage non-system stuff.

Digital Mercenary For Honor
05-11-08, 09:10 PM
On 2008-05-10 19:07:30 -0400, Santa Claus <free_presents@greenland> said:

> Dear NG,
>
> Subject: Newbie with ssh-server running... Hacking attempts against
> me... I hope this question is appropriate - My log says:


- Use a non-standard SSH port immediately. I haven't used tcp/22 on any
of my servers in years.

- You sounded like you can code in PERL. Write a script that changes
your SSH port each day, or according to some date calculation you
invent to a non-standard port and promulgate the port information
inside your enterprise - this is easier than you think it is to do.

- Consider rolling your hosts behind a firewall that can use knockd or
something similar implementing a "knock, knock" protocol. This way, no
ports need to be open unless you send the properly formatted packets to
the right TCP ports in the right sequence in the right amount of time,
then the port "opens up". I use my own algorithm with ICMP packets that
contain cryptographic data that verifies to a limited degree the origin
of the sender.

- Be careful what information you share with the public in NG's and
other places about your problem.

- If you're using OS/X desktops, consider installing Little Snitch on
them for some added security.

/dmfh

--
_ __ _
__| |_ __ / _| |_ 01100100 01101101
/ _` | ' \| _| ' \ 01100110 01101000
\__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx

darkog
05-12-08, 07:22 AM
On May 11, 7:33 am, Santa Claus <free_presents@greenland> wrote:
> darkog wrote:
> > There is an iptables trick you can use to easily address these
> > attacks. Google it. These attacks are very common. Anyone that is
> > running an Internet facing SSH server on port 22 will see these
> > regularly.
>
> Something like this:http://www.newartisans.com/blog_files/tricks.with.iptables.php
>
> ?
> ** Posted fromhttp://www.teranews.com**

sure. even this might help.

http://forums.theplanet.com/lofiversion/index.php/t57628.html

you have to test it to make sure it works. also make sure the "--
limit" switch is actually available to you. on some systems, i
remember i have had to recompile iptables to get it.

as has been posted, it's an automated/scripted attack. probably with
goal to gain access to box and use it to send SPAM. the logic being
that there is probably someone out there in WWW-land that is using one
of those weak username/password combos.

if you want to keep this internet facing, will you also want to keep
up to date with openssh security updates otherwise the attack vector
expands to successful use of an openssh exploit/vulrenability.

Santa Claus
05-12-08, 09:37 AM
Digital Mercenary For Honor wrote:
> On 2008-05-10 19:07:30 -0400, Santa Claus <free_presents@greenland> said:
>
>> Dear NG,
>>
>> Subject: Newbie with ssh-server running... Hacking attempts against
>> me... I hope this question is appropriate - My log says:
>
>
> - Use a non-standard SSH port immediately. I haven't used tcp/22 on any
> of my servers in years.

Yes, I read that's a really good idea...

> - You sounded like you can code in PERL. Write a script that changes

I can code i many languages - though not really in Perl - I want to
learn it however...

> your SSH port each day, or according to some date calculation you invent
> to a non-standard port and promulgate the port information inside your
> enterprise - this is easier than you think it is to do.

Great idea... This could be my first real perl-project, after having
done some tutorials... It sounds like I can do that (I think it should
be easy in perl)...

> - Consider rolling your hosts behind a firewall that can use knockd or
> something similar implementing a "knock, knock" protocol. This way, no
> ports need to be open unless you send the properly formatted packets to
> the right TCP ports in the right sequence in the right amount of time,
> then the port "opens up". I use my own algorithm with ICMP packets that
> contain cryptographic data that verifies to a limited degree the origin
> of the sender.

Wow... Great idea - exactly what I was looking for... Thanks a lot...

> - Be careful what information you share with the public in NG's and
> other places about your problem.

I know... I believe nobody should even be able to see my IP when posting
through teranews...

> - If you're using OS/X desktops, consider installing Little Snitch on
> them for some added security.

Thanks... I'll consider that...


** Posted from http://www.teranews.com **