Hardening tips

[phalange]

Searches have turned up a mishmash of solutions, so I'd like to get some suggestions. I've been happy with FreeBSD in bare metal scenarios, so I'm testing it in a VPS setup as a Jupyter server.

I'm using ipfw and blacklistd set up using the docs here and here but it's sparse.
For examples:
-- for IPFW would I use workstation or client?
-- does IPFW need to be configured to use blacklistd?
-- is fail2ban a better option? It seems to have more tutorials.

Generally, if anyone has some good common sense tips I'm all ears. This isn't highly sensitive, I just want some sane protection.

 

[SirDice]

-- for IPFW would I use workstation or client?

Neither. It's a server type installation, so the focus will be on incoming connections. Both workstation and client focus on outgoing connections. The "simple" setup is probably more useful but I would still advise to build your own rules.

-- does IPFW need to be configured to use blacklistd?

No, that shouldn't be required for IPFW. Read the script that does the adding of rules, it's /usr/libexec/blacklistd-helper that does the actual work. It's not a complex script.

-- is fail2ban a better option? It seems to have more tutorials.

It depends on your needs. The downside of blacklistd(8) is that services need to be specifically coded to make use of it. With fail2ban you can easily create your own custom rules for any sort of application log. So it's more versatile. I'm personally a fan of security/sshguard because it can monitor all the services I need and it has no dependencies. The downside of sshguard is that it can only monitor a specific set of services and you can't easily change any of its rules (they are hardcoded).

 

[zirias@]

I can't tell anything about IPFW because I never used it. But here's some generic advice:

There's never a "cookbook recipe" for security. If you want to secure something, you have to understand both the threats you want to avoid and the measures you take. Security neither starts nor stops at a "firewall". As far as technical measures are concerned, there's a "base recipe":

• Only run software you actually trust
• Make sure you don't offer any services you don't intend to offer
• Follow security updates (both for the OS and installed software) closely

This is a starting point. Anything else should be added on a "as needed" basis. Packet filtering makes a lot of sense on a firewall box meant to protect network segments "behind" it, whether it makes sense for a standalone server depends. Tools like fail2ban can slow down attackers a lot for any services that require authentication. Both should only be seen as additional layers of security: If you're running a vulnerable OS or service, they are unlikely to help. If you decide that you need a packet filter (like e.g. IPFW), you should know best what rules make sense for your usecase. So, learn how to write rules and write your own ruleset.

 

[SirDice]

Security neither starts nor stops at a "firewall".

Many people seem to think a firewall is some sort of "magic" barrier that stops any and all "bad" things. The thing about firewalls is that you need to poke holes in them or else your services can't be accessed.

 

[phalange]

The thing about firewalls is that you need to poke holes in them or else your services can't be accessed.

And maybe this is instructive. I will only access the server via ssh, although I think Jupyter still needs a port.
I use

ssh -N -L 8080:localhost:8080 <remote_user>@<remote_host>

So could I just set the host firewall to open 8080 and 22 and shut off every other port? Then use fail2ban or something like it to secure 8080 and 22?

 

[SirDice]

So could I just set the host firewall to open 8080 and 22 and shut off every other port?

If you're going to use SSH tunneling to forward that port 8080 you only need to have access to port 22 on the outside. Only open that port 8080 to the outside world if you want others to connect to it directly. And believe me, the minute you open a port (any port) to the outside world it's going to get scanned and poked at.

I'm not familiar with Jupyter but services like this are often proxied through an nginx or Apache instance. That way the service is accessible on the "regular" HTTP(S) ports and you get a little extra web layer to filter on. A setup like that can usually handle more concurrent connections too compared to connecting to the web application directly. Obviously you would then need to open ports 80 and 443.

 

[phalange]

So to summarize:
I already removed SSH ability for root (no keys)
I have strong password for SSH and user
Next steps:
(1) close everything except 22, and open 80 and 443 as needed for sharing with colleagues
(2) use fail2ban to block stubborn attackers on 22, 80 and 443

 

[richardtoohey2]

AllowUsers in sshd_config is also useful.

 

[rootbert]

my advice: use pf where possible and only use ipfw if you need a feature thats not supported by pf ;-)

and also this might be interesting for you: FreeBSD - lesson in poor defaults

 

[Alain De Vos]

I use "forwarding" and it's easier with ipfw then pf.

 

[phalange]

my advice: use pf where possible and only use ipfw if you need a feature thats not supported by pf ;-)
and also this might be interesting for you: FreeBSD - lesson in poor defaults

It's an interesting read, although the takeaway seems to be don't use FreeBSD at all since security is sloppy. I can certainly run a VPS with Ubuntu, but is a Linux distro inherently more easy to secure?

Also, importantly my goal is not to go down a security rabbit hole, but rather to have sane and reasonable protections for a low-risk (low value) target.

 

[zirias@]

It's an interesting read, although the takeaway seems to be don't use FreeBSD at all since security is sloppy.

I knew this article before, and there are a few interesting things in it. But some are outdated, some are debatable, and some depend on how you use the system When it comes to security, the most important thing is being informed. After all, it's the responsibility of the operator to operate a system that meets security requirements.

As an example: The ports framework allows building as a regular user, and it works pretty well. This might have been different in the past. It's definitely a good thing for people who use ports directly, the "old fashioned" way. Of course, if you use poudriere, all builds happen in a jail, so there's very little chance for a security breach during build anyways.

 

[PMc]

my advice: use pf where possible and only use ipfw if you need a feature thats not supported by pf ;-)

I don't know whether pf solves the problem ipfw has. It is not a technical problem, it is just that you need a very precise understanding of how it is intended to work in order to do it right. Even the example in the FreeBSD manual is most likely broken and does not work as intended for a server.

Nevertheless, there is a solution to this: a frontend that automates the ipfw rule creation and thereby avoids all the pitfalls, be it from not fully understanding how the rules interplay, or from understanding it but failing to fully think through all the possibilities.

and also this might be interesting for you: FreeBSD - lesson in poor defaults

This is madness. Quote:

Even with Sendmail's reputation, FreeBSD has kept it around and left it on by default for all their users.

Yes, what else should one do? Kill it for all users? Repression for all because the idiots may be in danger?
That's what I call hysteric paranoia (but socialists may call it otherwise).
Once again: you don't open ports for services you don't want to offer. And you don't offer services when you don't understand the implications. Is that too difficult?

When it comes to security, the most important thing is being informed. After all, it's the responsibility of the operator to operate a system that meets security requirements.

The most important thing is to not get paranoid, because paranoia darkens the mind and hinders clear understanding.