[PLUG] Public SSH server configs

Tom tomas.kuchta.lists at gmail.com
Wed Apr 12 20:34:05 UTC 2017


In my mind - trust, security, privacy, power, cooperation, .... - are
the fundamental friction points in this society. Given how important it
is for the human kind, it is surprising how many people do not
understand it.
If you are after technical stuff - stop reading here and do something
better with your time.
Access control to data and services, firewall, audits and monitoring
should help you to stop, discover and trigger response to malicious
attacks and actors.
Identify sensitive and business critical data sources and the services
allowed to use them - and set up p2p controls and authentication for
their use.
Encrypt sensitive data at rest and in transport, especially in "cloud".
Ironically, ssh on ports >1024 is good way to do this for some use
cases, so are other services which can be used to secure your data as
well as malicious communications.
Delete and not collect data you absolutely do not need - example: SSN
or address + credit card - you only need it to complete a transaction -
give users the choice to decide their level of risk - to store or not
their data for the future use.
This maybe old school and definitely not 100% effective - Setup and
enforce the use of proxy and network protocols at the perimeter. Do not
decrypt/manInTheMiddle ssl/tls data - this breaks security and creates
monumental and well advertized attack target. Create DMZ for services
that needs it. Make it easy for users to work and communicate, so they
are not forced to come up with innovative ways to bypass your controls.
Monitor and learn what normal/heathy baseline looks like. Make it too
restrictive and you will waste peoples work time and their desire to be
productive and innovate. If you do not trust your users and show it to
them at every opportunity - they will know it, and will be asking
themselves why were they hired and for what purpose - they will not not
be part of your security/team/company, you will alienate them. It is
fine line to walk - ask yourself what your priorities are, what you
want to achieve at the end of it all.
I work in engineering, development and data analysis environment -
being able to use network ports is essential to being able to work
productively. Without that, we are be restricted to single computing
process on a single machine or passing data through the file system
(which is essentially slow and high latency network) - that leaves you
in 20th century in terms of productivity a capabilities. On the top of
all that above - restrictions on using computers effectively - leads us
back to architecture/security review boards and that stalls any kind of
progress in its tracks, including security.
I hope that you see the trade offs here, use your full toolbox to
provide safe and productive work environment. The only real 100%
effective IT security is not to have IT, turn off power and networks. 
Alternatively, I've that HugesNet has very good service for keeping
networks, citizens, children and internet safe from bad actors. LOL
Tomas
On Wed, 2017-04-12 at 13:08 -0500, Cryptomonkeys.org wrote:
> Sure. and that would be fine for all the people who aren’t malicious.
> 
> 
> > On Apr 11, 2017, at 7:53 PM, Tom <tomas.kuchta.lists at gmail.com>
> > wrote:
> > 
> > That is what contracts, firewalls, monitoring and compliance tools
> > are
> > for.
> > If you do not trust users to start a process or use network ports -
> > disable their login and physical access to computers.
> > There are so many avenues which can be exploited beside ssh or any
> > myriad of other server processes.
> > Tomas
> > On Tue, 2017-04-11 at 18:41 -0500, Cryptomonkeys.org <
> > http://cryptomonkeys.org/> wrote:
> > > On Apr 10, 2017, at 2:17 PM, Jim Garrison <jhg at jhmg.net> wrote:
> > > > 
> > > > On 4/10/2017 8:22 AM, Paul Heinlein wrote:
> > > > > I've got a CentOS 7 VM running off in the cloud. It exposes
> > > > > SSH
> > > > > on 
> > > > > port 22 to the world. I've thought about moving it to an
> > > > > alternate 
> > > > > port, and may someday do so, but in the meantime I've tried
> > > > > to
> > > > > keep up 
> > > > > with best practices for sshd configuration.
> > > > > 
> > > > > I recently changed the KexAlgorithms setting, removing all 
> > > > > key-exchange algorithms based on NIST curves. (Google
> > > > > variants of
> > > > > "ed25519 nist ssh ecdh" for my reasoning.) Anyway, the new
> > > > > setting:
> > > > > 
> > > > > KexAlgorithms curve25519-sha256 at libssh.org,diffie-hellman
> > > > > -group
> > > > > -exchange-sha256
> > > > > 
> > > > > All of my machines (MacOS 10.12, CentOS 6, CentOS 7) can work
> > > > > with 
> > > > > this setting, so I don't have to worry about infinite
> > > > > backward 
> > > > > compatibility.
> > > > > 
> > > > > One interesting and unintended result of this change is that
> > > > > many
> > > > > SSH 
> > > > > scanners will fail while trying to negotiate a key exchange.
> > > > > The
> > > > > log 
> > > > > entries are short and sweet:
> > > > > 
> > > > > sshd[18200]: fatal: Unable to negotiate a key exchange method
> > > > > [preauth]
> > > > > 
> > > > > The number of scanners that even get through to the stage of
> > > > > 'Invalid 
> > > > > user' has dropped from a couple hundred per day to less than
> > > > > a
> > > > > dozen.
> > > > > 
> > > > > Everyone's situation is different, of course, and this
> > > > > alteration
> > > > > may 
> > > > > not work in your environment -- but you may find it
> > > > > worthwhile
> > > > > raising 
> > > > > the bar on the KexAlgorithm, Ciphers, and MACs in your
> > > > > sshd_config, 
> > > > > especially if your SSH daemon is exposed to the world at
> > > > > large.
> > > > > 
> > > > 
> > > > I've been running sshd on a non-standard port above 5000 for
> > > > about
> > > > 7
> > > > years, on various hosting services, both real hardware and more
> > > > recently
> > > > virtual machines.  I think in 7 years I've seen only **two**
> > > > attempted
> > > > connections and I think those were from someone just doing a
> > > > portscan,
> > > > as the log messages were one-offs and not repeated.
> > > > 
> > > > There has never been any effort from anybody to actually
> > > > connect.
> > > > 
> > > Any thoughts on the consequences of arbitrary users being able to
> > > run
> > > their own sshd on port numbers >1024? Would that mean that if
> > > somebody got access to your machine, they could replace the
> > > listening
> > > sshd with their own?
> > > 
> > > --
> > > Louis Kowolowski                                
> > > louisk at cryptomonkeys.com
> > > Cryptomonkeys:                                   
> > > http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/> <
> > > http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>>
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > PLUG mailing list
> > > PLUG at lists.pdxlinux.org PLUG at lists.pdxlinux.org>
> > > http://lists.pdxlinux.org/mailman/listinfo/plug <
> > > http://lists.pdxlinux.org/mailman/listinfo/plug>
> > _______________________________________________
> > PLUG mailing list
> > PLUG at lists.pdxlinux.org PLUG at lists.pdxlinux.org>
> > http://lists.pdxlinux.org/mailman/listinfo/plug <
> > http://lists.pdxlinux.org/mailman/listinfo/plug>
> --
> Louis Kowolowski                                
> louisk at cryptomonkeys.com
> Cryptomonkeys:                                   
> http://www.cryptomonkeys.com/ <http://www.cryptomonkeys.com/>
> 
> 
> 
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug


More information about the PLUG mailing list