Re: Security problem



On 01/12/11 18:10, Rainer Weikusat wrote:
David Brown<david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
On 01/12/2011 14:34, Rainer Weikusat wrote:
David Brown<david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
On 01/12/2011 11:24, Noob wrote:
David Brown wrote:

The easiest and most effective step to limiting dictionary attacks is
simply to use a non-standard port. Put your sshd on port 222 instead of
22, and no attacker will ever find it.

Famous last words.

Meet nmap.

Worms and script kiddies go for standard ports, using common login
names and passwords, on large ranges of IP addresses.

Yes. And the solution to this problem is to use 'strong' passwords or
no passwords at all but key based authentication.

No, that is /part/ of the solution. There are many things that
contribute to increasing the security and reducing the risk of
successful attacks.

Using some non-standard port for a server contributes at best 16 bits
of entropy to the amount of information an attacker needs to guess in
order to perform successful brute-force attack and that's ludicrous.

Really sophisticated attack software demonstrating that:

[rw@sapphire]~/work/mss-dns $time sh -c 'yes | nc -v -w 1 192.168.1.100 1-65535 2>&1 | grep -B 1 ^SSH-'
(UNKNOWN) [192.168.1.100] 22 (ssh) open
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze1

real 1m5.822s
user 0m10.397s
sys 0m3.376s


With a real-world attack across the internet, it takes a /lot/ longer than that to do the scan, especially assuming the machine is set up to DROP incoming packets for other ports (and what internet-facing server is not set up like that?). A brief test against a single DROP'ed port on my server took 3 minutes - at that rate a full scan would take 4 months.

Yes, sophisticated attacks can do it faster, do things in parallel, use an army of zombies to distribute the scans, etc.

The point is that it is a big delay for any automated system (worm or script kiddie). When they don't find any response on the standard port, the normal assumption will be that that there isn't a sshd there.

There are 65536 different ports but 281,474,976,710,656 different
eight character passwords composed of the members of the base64
alphabet (6 bit of information per character), this means the 'random
port' (and it usually isn't even random) increases the 'search space'
by a whopping 0.00000002% (2E-8).


You are missing the point - it's a cheap and effective way of getting extra protection. And it fits well with other schemes such as automatically blocking any IP address that is trying a scan - if your sshd is on port 22, then they hit it first time and omit that.


[...]

Think of it as another password. It's a smaller key space than normal
passwords, but it is big enough to be useful.

Just about as useful as a piece of ahesive tape as additional security
measure on a safe door ...


No, it's as useful as a false wall covering the safe door and hiding it from view, made of a solid material that will take time to break through and providing a useful place to add additional alarms.

[...]

Of course you don't put sshd on port 222 and then put your root
password as "secret". But as part of a security strategy it is
excellent for cutting out virtually all drive-by attacks, and reducing
the noise in your logs.

It is a minor pain-in-the-ass for users and

It could be inconvenient for users, though it is not a problem for
normal ssh connections.

It has a solution, consequently, it must be a problem :->.


Well, the most secure system is one that is not connected to a network at all - but users always complain!

[...]

actually, antisocial
behaviour (at least in some theoretical sense): When you notice
'lights on and strange noises' in your neighbour's house while he's on
holiday, you should call the police (send a complaint to the abuse
address corresponding with the IP) instead of thinking "Glad they
didn't come over here" and turn back to your TV.

The analogy has broken down long before this stage. You don't see
attacks on "neighbouring" IP addresses no matter how hard you look.

But you do see that some system was very likely compromised when the
IP address it is using appears in the auth.log file:

Dec 1 17:07:39 sapphire sshd[9671]: Failed password for invalid user oracle from 112.78.3.183 port 49229 ssh2

And that's very similar to seeing 'unauthorized people' digging
through someone else's posessions.

I thought you were talking about seeing attacks on other people's systems, and couldn't see how you were monitoring that.
.



Relevant Pages

  • Re: Security problem
    ... simply to use a non-standard port. ... names and passwords, on large ranges of IP addresses. ... Using some non-standard port for a server contributes at best 16 bits ... excellent for cutting out virtually all drive-by attacks, ...
    (comp.os.linux.development.apps)
  • Re: using PubkeyAuthentication, still getting dictionary attacks!
    ... Because they're script kiddie attacks and will try no matter what your ... Just move sshd to listen on a non-standard port and the annoyance will ... If the sshd server isn't there to listen to an attack on port 22, ...
    (comp.security.ssh)
  • RE: autoblocking many ssh failed logins from the same IP....
    ... Defending Against Attacks ... ports can be bombarded with login attempts using common ID/PW ... To the firewall these all look like legitimate packets. ... The simplest defense is to change the port numbers these services ...
    (freebsd-questions)
  • Re: Blocking attacks from spoofed IP addresses
    ... cause a _Self_ Denial Of Service attack. ... Defeating Denial of Service Attacks ... of our DMZ servers, and had source IPs from our public DNS servers. ... Web services are on your port 80 and/or 443, ...
    (comp.os.linux.networking)
  • Re: illegal and failed logins from virus?
    ... >>they are virus type attacks, and the IP addresses of the attempted ... >>is the only open port on this machine (which is obviously open to ... >>internet), and the passwords are in place, no root login, only few users ... > So I moved SSH to another port, replacing it on port 22 with a script ...
    (comp.security.ssh)