5 ms·

> Firewall: I don't think default to no firewall is a problem -- if you want something, you can set it up. I'm very curious about this one ... As far as I kno

by byuu 10y ago

> Firewall: I don't think default to no firewall is a problem -- if you want something, you can set it up. I'm very curious about this one ... As far as I know, any remote holes without a firewall on a default install would be a ground-breaking, DEFCON-1 level security event to server admins. Complete with CVEs, news coverage on various sites, etc ... right? The only time in history I recall this being a problem was with Windows XP, which led to Blaster and Sasser. Now I'm absolutely in favor of firewalls, but whenever I spin up a new VPS, there's going to be a window of about 20-30 minutes where I need to get in there, upload my SSH public keys, secure SSHD, tweak my sysctls, write out my pf firewall rules, and then activate them. There are also times when I need to test why a connection is failing, and one of the steps to testing is to turn off the firewall momentarily. I know that attacks are basically incessant against any server on the net. I see dozens of IPs trying brute-force root login SSH attempts a day against my boxes. How much danger is there, honestly speaking (not hypothetically), in this window? Would it be worth it to petition VPS providers to allow us to specify our own IP address, and have them enable a default "deny everything except from this one IP" firewall setup on new instances, or is that just total overkill?

humpdinger 10y ago
The really good VPS providers, allow out of band serial/VNC consoles so you can bring them up and configure prior to enabling networking. The really really good ones allow you to install from your own images, in which case you can preconfigure firewall etc.
lmm 10y ago
I've never understood the argument for system-level firewalls at at all. If a service is listening on a port from the network, presumably that's for a reason and you're going to end up writing a firewall rule for it anyway. If you have complex rules that try to filter out "bad guys" then your firewall is a complex piece of software full of parsers and the like, probably written in C "for performance", and you're exposing it to external packets - that's a bigger attack surface than not having a firewall. If your services are using sockets for local communication, bind to 127.0.0.1 or use a unix domain socket.
- Xylakant 10y ago
  Quite a few services bind to all interfaces by default. Redis used to, elasticsearch used to, iirc mongodb as well. The list is probably long. While this is a bug in the software, having a firewall that denies by default is an additional layer that prevents turning a slip-up into an RCE.
- VLM 10y ago
  If you assume lack of cooperation and separation of duties it can sometimes make a microscopic amount of sense. So security says thou shall not VNC and configures a very tight system level firewall, preventing some jerk end user from compiling and running a VNC server over port 10000 because the system level firewall blocks everything that's not explicitly permitted. Oh you've "broken" the system SSHD such that I can't even use it, I'll just compile and run my own sshd as an end user and run it on port 11000 or whatever. In practice I'd agree with you in that an org where security, admins, and users are pulling opposite directions is going to have massive problems in general and a mere system level firewall isn't going to patch over all of it. For a distant historical example I've worked at places where for temporary use I've had to shut down apache on port 80 and run sshd there on port 80 for a few moments, just to copy a config file over. A REALLY smart deep packet inspection firewall would notice the conversation on port 80 was very SSH like not HTTP like, but whatever. Speaking of VNC that made me LOL at the linked article suggestion to block X11 traffic, an end user who "really wants GUI" will simply fire up an unauthenticated possibly passwordless VNC server on some port. Security would have been a lot better off with SSH trying to be secure rather than VNC not trying at all. Some end users are just crazy some times. Oh I'm not allowed to run NFS because "security theatre", well OK them I'll just set up anonymous FTP because that's not blocked. I've seen some stuff...
  - byuu 10y ago
    > A REALLY smart deep packet inspection firewall would notice the conversation on port 80 was very SSH like not HTTP like, but whatever. Hahahah, I've abused this at a previous employer as well. They filtered out all outbound traffic other than ports 80 and 443; so I put my home SSH server on port 443, and then used a SOCKS5 proxy via dynamic port forwarding. Luckily their packet inspector wasn't smart enough to tell SSL from SSH; and apparently nobody in networking was manually reviewing traffic logs.
api 10y ago
You have a firewall. It's called "don't run services you don't need or don't understand" and "if it binds a non-localhost port it better be secure." It's easy to use netstat to list all bound ports for TCP and UDP. I know on Linux there is also a flag to show the owning pid. Do that and then investigate any you don't recognize. If you don't need it turn it off. Otherwise check it's security record and config.
toast0 10y ago
Out of the box, FreeBSD is going to have sshd, ntpd, and syslogd (i think) listening on wildcards. sshd is ok enough -- PermitRootLogin is default off, would be nice if password login was disabled, but that's a pretty hard default to change because it's going to affect a lot of people. ntpd isn't great, but the out of the box config is pretty restricted, so it's probably fine for a while syslogd is weird, it probably shouldn't be open to the world -- but that's more likely to fill up your disk than to be owned. I don't think there's a problem with running a firewall and I usually do, it provides a simple way to enforce your intent; but there's no sensible default rules. Api said it well, don't run services you don't need, and don't bind to external interfaces if you don't intend to serve the world.
- byuu 10y ago
  Awesome, thanks for this! So it sounds like no real issues, then. But all the same, I should add syslogd_flags="-ss" as soon as possible on a new install. Also worth noting, Vultr 'helpfully' adds "PermitRootLogin yes" at the very bottom of sshd_config on their new installs of FreeBSD. Ostensibly so you can log in without their VNC-in-a-web-browser client, and just use SSH for the initial setup. Which I quite like a lot. They give a really strong password that looks to be around 64^16 in terms of entropy, so that's probably fine. I always turn off root login and password login as soon as I add my authorized_keys to a user account anyway.

by byuu 10y ago

humpdinger 10y ago

The really good VPS providers, allow out of band serial/VNC consoles so you can bring them up and configure prior to enabling networking. The really really good ones allow you to install from your own images, in which case you can preconfigure firewall etc.

lmm 10y ago

I've never understood the argument for system-level firewalls at at all. If a service is listening on a port from the network, presumably that's for a reason and you're going to end up writing a firewall rule for it anyway. If you have complex rules that try to filter out "bad guys" then your firewall is a complex piece of software full of parsers and the like, probably written in C "for performance", and you're exposing it to external packets - that's a bigger attack surface than not having a firewall. If your services are using sockets for local communication, bind to 127.0.0.1 or use a unix domain socket.

Xylakant 10y ago
Quite a few services bind to all interfaces by default. Redis used to, elasticsearch used to, iirc mongodb as well. The list is probably long. While this is a bug in the software, having a firewall that denies by default is an additional layer that prevents turning a slip-up into an RCE.
VLM 10y ago
If you assume lack of cooperation and separation of duties it can sometimes make a microscopic amount of sense. So security says thou shall not VNC and configures a very tight system level firewall, preventing some jerk end user from compiling and running a VNC server over port 10000 because the system level firewall blocks everything that's not explicitly permitted. Oh you've "broken" the system SSHD such that I can't even use it, I'll just compile and run my own sshd as an end user and run it on port 11000 or whatever. In practice I'd agree with you in that an org where security, admins, and users are pulling opposite directions is going to have massive problems in general and a mere system level firewall isn't going to patch over all of it. For a distant historical example I've worked at places where for temporary use I've had to shut down apache on port 80 and run sshd there on port 80 for a few moments, just to copy a config file over. A REALLY smart deep packet inspection firewall would notice the conversation on port 80 was very SSH like not HTTP like, but whatever. Speaking of VNC that made me LOL at the linked article suggestion to block X11 traffic, an end user who "really wants GUI" will simply fire up an unauthenticated possibly passwordless VNC server on some port. Security would have been a lot better off with SSH trying to be secure rather than VNC not trying at all. Some end users are just crazy some times. Oh I'm not allowed to run NFS because "security theatre", well OK them I'll just set up anonymous FTP because that's not blocked. I've seen some stuff...
- byuu 10y ago
  > A REALLY smart deep packet inspection firewall would notice the conversation on port 80 was very SSH like not HTTP like, but whatever. Hahahah, I've abused this at a previous employer as well. They filtered out all outbound traffic other than ports 80 and 443; so I put my home SSH server on port 443, and then used a SOCKS5 proxy via dynamic port forwarding. Luckily their packet inspector wasn't smart enough to tell SSL from SSH; and apparently nobody in networking was manually reviewing traffic logs.

api 10y ago

You have a firewall. It's called "don't run services you don't need or don't understand" and "if it binds a non-localhost port it better be secure." It's easy to use netstat to list all bound ports for TCP and UDP. I know on Linux there is also a flag to show the owning pid. Do that and then investigate any you don't recognize. If you don't need it turn it off. Otherwise check it's security record and config.

toast0 10y ago

Out of the box, FreeBSD is going to have sshd, ntpd, and syslogd (i think) listening on wildcards. sshd is ok enough -- PermitRootLogin is default off, would be nice if password login was disabled, but that's a pretty hard default to change because it's going to affect a lot of people. ntpd isn't great, but the out of the box config is pretty restricted, so it's probably fine for a while syslogd is weird, it probably shouldn't be open to the world -- but that's more likely to fill up your disk than to be owned. I don't think there's a problem with running a firewall and I usually do, it provides a simple way to enforce your intent; but there's no sensible default rules. Api said it well, don't run services you don't need, and don't bind to external interfaces if you don't intend to serve the world.

byuu 10y ago
Awesome, thanks for this! So it sounds like no real issues, then. But all the same, I should add syslogd_flags="-ss" as soon as possible on a new install. Also worth noting, Vultr 'helpfully' adds "PermitRootLogin yes" at the very bottom of sshd_config on their new installs of FreeBSD. Ostensibly so you can log in without their VNC-in-a-web-browser client, and just use SSH for the initial setup. Which I quite like a lot. They give a really strong password that looks to be around 64^16 in terms of entropy, so that's probably fine. I always turn off root login and password login as soon as I add my authorized_keys to a user account anyway.