Threat Level: green Handler on Duty: Daniel Wesemann

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Ethics / SSH brute forcing continues

Published: 2004-09-11
Last Updated: 2004-09-11 23:36:18 UTC
by Swa Frantzen (Version: 1)
0 comment(s)
On a day like this it's not such a big effort to ponder about the
different mentality and ethics people have. Don't worry,
I won't go away from the information security scene.

Ethics

Crackers

I generally call people breaking into systems crackers, not hackers.

Why do they do it? Because they can.

Do they know they cause a lot of work? Yes:
they will often try to minimize the work by leaving the original content
in a backup copy.

In their ethical view it's right, all you need
to do as a defender is
fix the bug and reinstall the backup over their defacement.
Unfortunately
this is only true is you know 100% sure the cracker didn't do anything else,
otherwise it takes a lot more work.

Spammers

People sending unsolicited bulk email are what I call spammers.
They have noticed honeypots and don't seem to like them
very much. But their view on the ethics is very strange indeed.

Many people are quite irritated about unsolicited bulk email, many places
have laws against it.

But still the "bulkers" as they call themselves
sell tools to be more anonymous, and as a new catch form one of our
readers, to avoid honeypots.

They label honeypots as framing them.
Perhaps that's true, but if you don't steal resources, while trying
to get away with it in the first place, the honeypots woudn't get
found in the first place.

And if reporting them to their ISP does hurt them it's only because
they violated an AUP.

Programmers

I'm not a developer anymore for many years, but when I do program that odd
script the way I look
at software is quite different from the way I see developers look at software.

- I'm interested in KISS

- I'm not interested in a dozen libraries, objects, middleware, language, ...

- I'm interested in getting data clean and efficiently through the system.

- I'd think of data when coming in to the system as tainted, esp. if
it came from the web. And when it comes from one of my scripts running in the
client's environment I don't trust my own software.

SSH brute forcing continues

We keep getting reports of people getting hit seriously by brute force attempts to exploit ssh. It looks like this is going to stay with us for a while longer. Best to make sure:

- Weak passwords aren't used on your machines.

- sshd version is up to date.

- User root cannot login over the network.

- Typical usernames like guest and test aren't present on your system, or are disabled from logging in.

- Consider filtering where you accept connections from on TCP port 22.

- Consider moving ssh away from port 22 if you can't filter easily (the automated bots will have to look harder to find you)

- Report on failed login attempts, but make sure you don't aggravate the problem by sending an email per attempt.

- Consider migrating to public/private key-pairs instead of passwords.

- Some of our readers have had success with rate limiting incoming ssh connections.

--

Swa Frantzen
Keywords:
0 comment(s)
Diary Archives