Subject: Newbie with ssh-server running... Hacking attempts against me...

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.

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.

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 regularly.

'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 hacked box.

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

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

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

Something like this:

?

** Posted from **

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 other places.

You're right...

** 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 &

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?

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

-snip-

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?

Thank you.

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 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 **

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.

Wolfgang

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 **

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.

play around with netcat.

Cheers, Jens

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 backdoored copies.

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) 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.

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.

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

** Posted from **

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 OpenSSH?

See above.

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.