Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FreeBSD SSH Hardening

gist.github.com

Post reply on HN
Print view View original

91–100 of 121 posts

Re: FreeBSD SSH Hardening

#91

Post by gperciva »

sillysaurusx wrote: post #87
cperciva wrote: post #36

Earlier quoted context omitted.

Sort of. Not really. spiped operates at the level of individual stream connections, so you can e.g. make one end a local socket in a filesystem and use UNIX permissions to control access to it. In fact that's exactly why I wrote it -- so I could have a set of daemons designed to communicate via local sockets and transparently (aside from performance) have them running on different systems.

Is it possible to use tarsnap's deduplication code on my own server? We're setting up an ML dataset distribution box, and I was hoping to avoid storing e.g. imagenet as a tarball + untar'd (so that nginx can serve each photo individually) + imagenet in TFDS format. https://github.com/xolox/dedupfs was the closest I found, but it has a lot of downsides. Has anyone made an interface to tarsnap's tarball dedup code? A p…

> Has anyone made an interface to tarsnap's tarball dedup code?

Tarsnap's deduplication code is not available under an open-source license.

Re: FreeBSD SSH Hardening

#92

Post by sillysaurusx »

gperciva wrote: post #91
sillysaurusx wrote: post #87

Earlier quoted context omitted.

Is it possible to use tarsnap's deduplication code on my own server? We're setting up an ML dataset distribution box, and I was hoping to avoid storing e.g. imagenet as a tarball + untar'd (so that nginx can serve each photo individually) + imagenet in TFDS format. https://github.com/xolox/dedupfs was the closest I found, but it has a lot of downsides. Has anyone made an interface to tarsnap's tarball dedup code? A p…

> Has anyone made an interface to tarsnap's tarball dedup code? Tarsnap's deduplication code is not available under an open-source license.

True, but a couple years ago I ported most of the Tarsnap dedup algorithms to Python. It wasn't too hard, just time consuming. I was hoping someone else did that in a thorough way, but I guess the intersection of "I love tarsnap's design!" and "I have the time to port it from C!" might not be too large.

Re: FreeBSD SSH Hardening

#93

Post by toast0 »

tiffanyh wrote: post #73
toast0 wrote: post #7

Earlier quoted context omitted.

As with all things, you would really need to benchmark the system, preferably with real load, both ways to know for sure. But that takes a lot of time, especially if you're going to put in the time to tweak both systems. People can do amazing stuff with enough time in both FreeBSD and Linux. I honestly think most server applications wouldn't be held back by either OS. You need your application to be really lightweigh…

Hi toast0 IIRC, I saw a presentation by someone (Rick?) where at your previous employer - you guys slimmed FreeBSD down to be unbelievably minimal such that only 2-3 total services ran on the entire server. Was that done for performance reason? Or for hardening reasons? If someone wanted to do that today with FreeBSD: would you recommend it and how would you go about doing it (NanoBSD)?

Probably Rick, he did a bunch of presentations.

We ran a pretty vanilla FreeBSD. IIRC, we disabled locales, and had 5-10 patches depending on exactly when and what bottlenecks we were running into.

We didn't go out of our way to turn off daemons, we just didn't start anything we didn't need. Out of the box, you get sshd, crond, getty, ntpd, syslogd, our system activity report, and that's really all you need to administer the box. Then on our Erlang machines, we'd run one big Erlang process. Unless something went seriously wrong, only Erlang ever had real work to do.

I don't know that there was a performance benefit, you can run a lot of daemons that are waiting on sockets and don't use meaningful amounts of ram before noticing a performance hit. Hardening has something to do with it, can't get into our smtpd if we're not running it. But mostly it kept things simple and reduced work. No extra daemons means no configuration of them and no update headaches. Even with that limited set, I had to go around and reconfigure sshd sometimes and ntp rather more than I'd have liked, and we used caveman automation, so stuff that needs super user is extra painful.

On hardening, we didn't exclude things from FreeBSD's base, even though that would probably be a good idea. Some things are there for reasonable reasons, but had no relevance to us, and less installed stuff would be better, but tradeoffs. We did run stud (now known as hitch, which we needed when Erlang TLS was too slow) in a totally locked down jail though; statically configured binary, only executable in the jail, etc.

Re: FreeBSD SSH Hardening

#94

Post by da_chicken »

tialaramex wrote: post #81
ilaksh wrote: post #76

Earlier quoted context omitted.

What's a post-quantum key exchange? I assume this is a real thing and not a reference to Devs or Lapsis or something?

So. All of today's practical public key crypto could be broken by a sufficiently powerful quantum computer - if one existed which today it does not - thanks to a trick called Shor's Algorithm. However, there are new public key algorithms that aren't affected by Shor's algorithm. Two problems. 1. They're all worse, they have huge keys for example, or they're slow, so that sucks. 2. We don't know if they actually work,…

> All of today's practical public key crypto could be broken by a sufficiently powerful quantum computer - if one existed which today it does not

That we know of. There are commercially available quantum computers [0] and there are roadmaps for commercial technology ramp up significantly [1]. Remember, that's a roadmap to projected commercial viability. It's hard to say what state actors are capable of right now.

[0]: https://azure.microsoft.com/en-us/services/quantum/

[1]: https://venturebeat.com/2020/12/09/ionq-roadmap-quantum-mach...

Re: FreeBSD SSH Hardening

#95

Post by wwarek »

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.

I can recommend similar, but locally running tool, `ssh-audit`: https://github.com/jtesta/ssh-audit

Disclaimer: I'm not associated in any way

Re: FreeBSD SSH Hardening

#96

Post by LukeShu »

cpach wrote: post #57
amarshall wrote: post #56

Earlier quoted context omitted.

OpenVPN may have its issues (complicated setup vs. e.g. Wireguard, but not vs. e.g. IPsec), but I wouldn’t call it “not good” and it predates spiped by a decade.

Ok. I don’t agree there. What I’ve heard from security experts is that WireGuard is vastly superior to OpenVPN. Addendum: OpenVPN was released in 2001 and there where lots of cryptography-related systems from that era that certainly didn’t age well – IMO OpenVPN is one of those examples.

OpenVPN's encryption is just TLS. It uses OpenSSL for this, not rolling their own implementation. Yes, there are parts of SSL/TLS that haven't aged well, but... it's good enough for the world's web traffic.

Re: FreeBSD SSH Hardening

#97

Post by LukeShu »

drclau wrote: post #69
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 use blacklistd [0], on FreeBSD, instead of changing the port. It works with sshd, and it temporarily blocks IPs that are abusive. [0]: https://docs.freebsd.org/en/books/handbook/firewalls/#firewa...

I always move sshd to a non-standard port, and blacklistd would not address the reason why I do it.

One IP abusing it and trying to gain access isn't what I address by moving the port. I move the port to cut out the noise of the thousands of IPs that will connect to it once to probe it and never again. The volume of those one-off probes is so dramatic that it makes the logs entirely useless. By moving the port, I cut out that noise so that if I glance at the logs I actually have a chance of noticing anything that is worth noticing.

Re: FreeBSD SSH Hardening

#99

Post by toast0 »

waynesonfire wrote: post #60
toast0 wrote: post #7

Earlier quoted context omitted.

As with all things, you would really need to benchmark the system, preferably with real load, both ways to know for sure. But that takes a lot of time, especially if you're going to put in the time to tweak both systems. People can do amazing stuff with enough time in both FreeBSD and Linux. I honestly think most server applications wouldn't be held back by either OS. You need your application to be really lightweigh…

> but what I like most about FreeBSD is the lack of churn I agree completely. As I mature in this field this becomes an ever important characteristic of the technology I adopt. Erlang also shares this property.

I feel like Erlang churn is more acceptable because they're usually honest in naming. You get pg2 which does what pg did, but differntly. And now pg (which could have been pg3, but the old pg had been gone long enough to reclaim the name). Similar with phash2, although phash may live for much longer.

Re: FreeBSD SSH Hardening

#100

Post by acatton »

bityard wrote: post #86
acatton wrote: post #23

Earlier quoted context omitted.

In the same vein, protecting your SSH server with spiped[1] does 99% of the job. (= No need to setup fail2ban, password auth is not a big deal anymore, protects against out-of-date SSH servers and/or zero-days exploits, ...) [1] https://www.tarsnap.com/spiped.html

spiped looks like netcat with symmetric encryption. If your SSH server has password auth disabled, then all you're doing is moving the attack surface from one thing to another. You're making a trade-off no matter which way you go. spiped probably has a smaller attack surface than sshd due to being less code, but it's also less "tried and true" than openssh. Not to mention, managing symmetric keys securely is more dif…

> spiped looks like netcat with symmetric encryption

True. But to be more specific, it does symmetric encryption and authentication.

> If your SSH server has password auth disabled, then all you're doing is moving the attack surface from one thing to another.

I get what you're saying. But I see spiped as port-knocking with a 256bits combination. So basically, you are reducing the attack surface. In order for the attacker to get through, they need a vulnerability in spiped and in openssh-server. (If these probabilities are 50-50 each, that means the overall probability is 0.25)

At the end of the day, spiped should run in a chroot, as a user, so the attack surface of spiped is really low. If it gets compromised, the only thing the attacker can do is "be able to try to establish a connection to the SSH server".

The goal of spiped for me is to eliminate the need for constant monitoring of openssh vulnerabilities, and for installing fail2ban/blacklistd (which can lock legitimate users out)

Post reply on HN