FreeBSD SSH Hardening • Hacker News Board

Re: FreeBSD SSH Hardening

#11

Post by adrian_b » Wed, Sep 15, 2021, 12:14 PM UTC

tester756 wrote: post #2

I always heard that FreeBSD has unparalleled networking Does it mean that it'd be worth picking FreeBSD over Linux for my C# crud app if it had to handle a lot of requests/sec? (let's ignore db for the moment)

There was a time when FreeBSD had much better networking performance than Linux, but that was many years ago.

Now, on supported hardware, their performance should be similar.

However, Linux has drivers for much more varied networking hardware. FreeBSD has very good support for Intel NIC's but some of the hardware from other vendors may happen to be not supported.

FreeBSD has a few nicer kernel features for those who develop themselves a networking application, but more networking libraries useful for high performance applications are available for Linux, even if DPDK, which was mentioned in another reply, is available for both Linux and FreeBSD.

So, while I am a very satisfied FreeBSD user, I would recommend to someone with less experience to use Linux, as there are more resources readily available.

On the other hand, for someone who wants to learn more about the implementation of networking applications, it can be useful to also try FreeBSD, to understand more about alternative solutions.

Re: FreeBSD SSH Hardening

#12

Post by kd913 » Wed, Sep 15, 2021, 12:22 PM UTC

crest wrote: post #5

kd913 wrote: post #4

Earlier quoted context omitted.

I don't think it would be worthwhile. If you want better latency and throughput, you wouldn't be using the kernel network stack and instead be opting for some userspace networking stack like DPDK or onload. Depends obviously on what the bottlenecks of your application are, your NIC and the characteristics of your hardware as well.

FreeBSD has netmap for fast userspace packet processing.

True, and the Linux kernel has zero-copy AF_XDP that enable memory to be shared with userspace. However, low-latency networking is a lot more than just simple kernel bypass.

It's things like pinning cpu cores dedicated for networking, disabling C-states, epolling and being able to utilize bespoke firmware interfaces designed for smartnics. Also application protocol, ie using features like TCP checksum offload and TSO.

Heck the application would also need to be adjusted for a low-latency environment via probably a custom JVM and doing things like reading data structures/variables to ensure they are in CPU cache.

Frankly I would recommend trying openonload which at least is compatible with native Linux socket programming unlike DPDK.

Re: FreeBSD SSH Hardening

#13

Post by hannob » Wed, Sep 15, 2021, 12:23 PM UTC

SSH hardening guide bonus edition: Disable password login if you can, leave the algorithm settings as they are and use an up to date version of OpenSSH.

OpenSSH already agressively deprecates algorithms that are problematic. None of the algorithms enabled by default has any known security issue. But your manual tweaks from a random document you read on the Internet may enable an algorithm that we may later learn to be problematic.

Re: FreeBSD SSH Hardening

#14

Post by chasil » Wed, Sep 15, 2021, 12:29 PM UTC

Is it really necessary to disable an E521 ECDSA host key? By all means, replace a P256 host key with E521, but are E521 keys truly weak to justify removal?

E521 is listed as safe on DJB's main evaluation site:

https://safecurves.cr.yp.to/

More specific DJB commentary: "To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2^521 – 1; but the sheer size of this prime makes it much slower than NIST P-256."

http://blog.cr.yp.to/20140323-ecdsa.html

I believe that OpenSSH is using the E521 provided by OpenSSL (as seen on Red Hat 7):

    $ openssl ecparam -list_curves
      secp256k1 : SECG curve over a 256 bit prime field
      secp384r1 : NIST/SECG curve over a 384 bit prime field
      secp521r1 : NIST/SECG curve over a 521 bit prime field
      prime256v1: X9.62/SECG curve over a 256 bit prime field

These appear to have been contributed by Sun Microsystems, and were designed to avoid patent infringement.

https://security.stackexchange.com/questions/3519/can-ecc-be...

Re: FreeBSD SSH Hardening

#15

Post by ipaddr » Wed, Sep 15, 2021, 12:33 PM UTC

hannob wrote: post #13

SSH hardening guide bonus edition: Disable password login if you can, leave the algorithm settings as they are and use an up to date version of OpenSSH. OpenSSH already agressively deprecates algorithms that are problematic. None of the algorithms enabled by default has any known security issue. But your manual tweaks from a random document you read on the Internet may enable an algorithm that we may later learn to b…

Safest setup

disable password login. disable ssh login. Put the computer back in the box and put the box under your bed.

Re: FreeBSD SSH Hardening

#16

Post by 0xdeadb00f » Wed, Sep 15, 2021, 12:43 PM UTC

ipaddr wrote: post #15

hannob wrote: post #13

SSH hardening guide bonus edition: Disable password login if you can, leave the algorithm settings as they are and use an up to date version of OpenSSH. OpenSSH already agressively deprecates algorithms that are problematic. None of the algorithms enabled by default has any known security issue. But your manual tweaks from a random document you read on the Internet may enable an algorithm that we may later learn to b…

Safest setup disable password login. disable ssh login. Put the computer back in the box and put the box under your bed.

Then, using aluminum foil and unfolded crisp packets make your room into a Faraday cage. Never open the door for any reason whatsoever. In fact, remove the door altogether.

Re: FreeBSD SSH Hardening

#17

Post by qersist3nce » Wed, Sep 15, 2021, 12:44 PM UTC

lou1306 wrote: post #8

Relevant: If your SSH server is public, you can give its address to https://sshcheck.com/ and it will report any weak spots in your config.

nice honeypot ;)

(joking, thanks for the suggestion)

Re: FreeBSD SSH Hardening

#18

Post by 0xdeadb00f » Wed, Sep 15, 2021, 12:46 PM UTC

tester756 wrote: post #2

I always heard that FreeBSD has unparalleled networking Does it mean that it'd be worth picking FreeBSD over Linux for my C# crud app if it had to handle a lot of requests/sec? (let's ignore db for the moment)

FreeBSD (and all BSDs for that matter) have pretty good networking stacks besides any new recent-gen WiFi.

Re: FreeBSD SSH Hardening

#19

Post by kd913 » Wed, Sep 15, 2021, 12:48 PM UTC

lamnk wrote: post #9

The first thing i do on a new remote box is to move SSH to another non-standard port other than 22. I use the same port for every remote boxes I have. Then add that port into `.ssh/config` on local box. Second is to disable root login. Third is to copy my private key over and disable password login. 3 essential steps to secure SSH.

I think there are better approaches than this.

1) Setup a VPN via wireguard and only expose that random udp port. That way only a single UDP port is exposed and port-scans become infeasible.

2) Setup 2fa via libpam-google

Re: FreeBSD SSH Hardening

#20

Post by akerl_ » Wed, Sep 15, 2021, 12:58 PM UTC

lamnk wrote: post #9

The first thing i do on a new remote box is to move SSH to another non-standard port other than 22. I use the same port for every remote boxes I have. Then add that port into `.ssh/config` on local box. Second is to disable root login. Third is to copy my private key over and disable password login. 3 essential steps to secure SSH.

Just so we’re clear, this is 1 step to secure SSH, 1 step to avoid installing logrotate, and 1 step to encourage good admin practices.

Changing the port and using a non-root user for SSH don’t appreciably change the strength of the server’s security.