Re: Securing SSH wiki article outdated

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, February 13, 2015 9:05 am, Always Learning wrote:
>
> On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:
>
>> On 02/13/2015 09:15 AM, Chris Adams wrote:
>> > Yeah, the old "move stuff to alternate ports" thing is largely a waste
>> > of time and just makes it more difficult for legitimate use. With
>> > large bot networks and tools like zmap, finding services on alternate
>> > ports is not that hard for the "bad guys".
>
>> Having SSH on 22 is lower-hanging fruit than having SSH on a different
>> port.  Sure, an NBA all-star will be able to reach the apples at the top
>> of the tree easily, but most people are not NBA all-stars.  Most
>> port-scanners do not scan all possible ports.
>>
>> And I am fully aware that people in the 'it's a waste of time' camp are
>> unmoved by that.  It's not worth arguing about; those who move to
>> non-standard ports are going to want to do it anyway.
>
> Lamar's comments are very sensible.
>
> I always change the SSH port to something conspicuously different. Every
> server has a different and difficult to guess SSH port number with
> access restricted to a few IP addresses.
>
> Waste of time = all the time and energy required to clean-up after a
> hacker's breech when a few seconds work selecting a different port could
> make a beneficial improvement to security.
>

Just to mention (even though someone already mentioned that): changing
port numbers, or, say removing disclosure by the daemon what software,
version, ... it is does not really add security. Security through
obscurity is only considered to be efficient by Windows folks. Quite
wrongfully IMHO.

So, I would suggest to not do these "non-standard" things fooling yourself
in wrongful feeling of better security. But instead, maintain the daemons
updated. Keep passwords reasonably sophisticated. Do not start unnecessary
services. Defend against brute force attacks (I use "--hitcount" option of
iptabels on Linuxes and sshguard on FreeBSD). And speaking of security:
maintain system free of local exploits (update, update, update...), that
is if (when I always consider it for my systems) the bad guys are already
in, they can not successfully elevate privileges. Each of the above is
like big chapter on system security each said in one short phrase.

And most importantly, read good fundamental Unix/Linux system book, and
revisit your system configurations (from security point of view) while
reading.

Just my $0.02

Valeri


++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux