On 04/04/2014 07:36 AM, Angus McIntyre wrote:
Dan McAllister wrote:
I'm very much not a fan of re-assigning well-known-ports to other
locations (like FTP or SSH).
Most of us admins have static IPs where we work, if not where we live.
If you try to SSH into any of my servers (other than just 1 that is not
especially public), you'll be denied (connection dropped).
I can get in because of my [source] IP address and my iptables rules.
I think what you say is true for 'pro' admins, but may be less true for
others. For instance, I'm on the road a lot, so it wouldn't work for me.
Anyone who uses a home broadband connection that gets dynamically-assigned
IPs is also in trouble (unless they widen the iptables rule to allow
anything from the blocks assigned to their ISP's pool).
One thing that is certain is that moving, say, SSH to another port isn't
going to prevent script kiddies and SSH grinders from targeting it. On the
other hand, in my experience it does significantly reduce the volume of
attempts, at least for now.
It's not "security by obscurity", but "aggravation minimization by
obscurity". The important thing is not to have any illusions about its
effectiveness.
Although I have to say that incoming spam volume has plummeted since I
moved SMTP from port 25 to port 10347. :-o ;-)
I also use a "trigger port" (try to open this "odd" port and it will
fail -- but my SSH port will be OPEN for 3 minutes!
I'm not convinced that port-knocking is any more or less elegant than
port-moving, but I am far from being an expert admin, so I'm sure I could
be persuaded. I do know that I wouldn't like to have to explain
port-knocking to some of the people who need SFTP access to some of my
servers.
Although maybe the ability to understand basic security techniques ought
to be a requirement for access, and people who can't get their heads
around it don't have any business on my boxes.
One slight weakness of port-knocking is that a grinder can simply hit a
range of ports, then make a second pass to access the now-open well-known
port (at which point they get three attempts to guess the password before
fail2ban knocks them on the head). I would guess that SSH grinders will
eventually start doing this, although at least port-knocking adds an extra
layer of complexity for them.
I guess if you're truly paranoid, you could take the scheme further, and
either require users to visit a login web page (obscure location, https,
authentication) or to send some kind of verification message to the
'knock' port before the protected port is opened up for the precise IP
address making the request. But the arms race hasn't yet reached the point
at which such heroic measures are necessary.
Angus
---------------------------------------------------------------------
This has turned into quite a discussion, eh Angus? Thanks for the starter.
I'm not very familiar with port knocking, but it seems to me that using
a non-std port is always preferable security-wise than using a default
(aka standard) port. This is applicable to ssh as well as ftp.
I wonder about this. Why do default/std ports even exist? For email,
there's no mechanism that I'm aware of for domains to advertise which
port they accept incoming mail on, so port 25 (some constant port) is
pretty much required. Same holds for DNS lookups (53) and http(s).
Reason appears to be that these are all public anonymous ports, iow
ports with public access requiring no authentication.
For public ports with authentication though (such as imap, pop,
submission and perhaps ftp), the only benefit appears to be that client
programs can be more easily configured if they know which port(s)
they're using. It's not entirely unfeasible though to set up these
services on non-std ports. Whether or not this actually improves
security can be debated.
Now the thing that surprises me a little is that there are bots that hit
ports other than 22 with multiple ssh attempts. This says to me that
some sort of port scanning must have been involved to find the port that
ssh is listening on.
Which begs the question. Is there some sort of hard-ass security tool
that detects port scans, or perhaps repeated traffic from any IP to any
port(s) with no services associated with them? (Then takes the next
logical step of blocking that IP for a period of time.)
I can't be the first person who's thought about this.
Anyone?
Another option (of course) is to have both public and private interfaces
on any public facing host (as many servers do), and only allow ssh
access from the private side.
And yet another is to have a perimeter firewall that port forwards
traffic to QMT. This case should not allow ssh on port 25 at all, and
forwards no ssh traffic anywhere from a public address. Yet QMT can
accept SSH connections from anywhere, since the firewall is taking care
of potentially malicious traffic.
I'd be interested to know how many people run QMT on a public address,
vs behind a NATing router. This affects how the QMT firewall is
configured, and I'm planning to automate that setup. Just curious to
know though how people are setting up their QMT hosts.
(Survey Says:)
--
-Eric 'shubes'
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
