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
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
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.
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.
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.
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
'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.
It is automated, originating either from scipt kiddie activity or from a
'He' does not exist. 'It' (= the program) would be correct.
In this case we are talking about a computer program, not about a human
wolfgang@zaphod:~> host 22.214.171.124
126.96.36.199.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.
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...
Ofcourse it is automated.
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.
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
** Posted from
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?
He'll get nowhere with my server, trying to hack root...
** Posted from
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 &
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?
Have you ever read up on 'zero-day' exploits, and cracking kits?
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...
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?
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?
Not really. I'm using:
# telnet localhost 22
Connected to localhost.
Escape character is '^]'.
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
Yes, I 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 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.
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.
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.
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.
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.
By which point, your disk might be zeroed.
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.
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.
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.
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.
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.
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.
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
See above note about overconfidence. :)
It actually isn't, since both can work hand-in-hand.
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)
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
Modern operating system or modern hardware can strictly and fully enforce
every possible policy you implement against programs.
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...
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.
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.
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.
Correct, which is why I stated /may/ find a crack in the armor.
How do exploits get executed then? Otherwise they wouldn't be exploits.
You trust things more than I would if I suspected a successful compromise.
Oh. Oh, my. You don't get out much, do you?
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.
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
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.
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.