3 ms·

I have been meaning to write up a similar guide. I would like to recommend using just iptables instead of ufw, I had a case on my vps where an update to ufw fa

by tmaly 10y ago

I have been meaning to write up a similar guide. I would like to recommend using just iptables instead of ufw, I had a case on my vps where an update to ufw failed and then the firewall was not working. With iptables, install iptables-persistent package so they are saved when you do restarts. Do not try to block entire country ip ranges as this slows the machine down substantially. fail2ban is great, I would recommend looking at some of your system logs to figure out new rules to add.

throwanem 10y ago
Seconding the recommendation to avoid ufw. I haven't actually used it or had a problem with it, but if you understand iptables then you don't need it, and if you don't understand iptables, you're better off just learning to use iptables directly so you can handle those cases that ufw doesn't support or clean up after it when it breaks. I didn't know about iptables-persistent, but it's easy enough to just "iptables-save > /etc/network/iptables" once you're finished changing the config, and "iptables-restore < /etc/network/iptables" in /etc/rc.local. Pretty sure those binaries come with iptables itself, so they should always be available. (I've never dealt with a system that had iptables where they weren't.)
- tmaly 10y ago
  I recommend iptables-persistent because fail2ban is adding rules dynamically, and it just makes it easier to handle with that aspect automated.
  - throwanem 10y ago
    I didn't notice that iptables-persistent actually saves the currently configured rules periodically. That's both kinda neat and a little scary, and I'm not entirely sure I see much value in persisting dynamic rules; it seems like it'd be easy to end up with a long chain of stale rules that way. Still worth knowing about the automatic persistence, though.
    - porker 10y ago
      Surely as rules are deleted they disappear from the saved copy? Or is the issue that fail2ban et al don't remove stale rules?
      - throwanem 10y ago
        It does, but I seem to remember it having trouble cleaning up after itself when abruptly terminated and restarted. It's been a few years, though, so that's probably no longer an issue.
vidarh 10y ago
Ferm [1] is wonderful as an iptables frontend. Apart from making it simpler to read, it can avoid a lot of repetition with handy shortcuts such as ability to group things. E.g.: proto tcp dport (smtp ssmtp qmtp pop3 pop3s imap2 imap3 imaps) ACCEPT; .. creates rules for each of the ports listed. You can use multiple groups in the same statement as well (lets say all the services above for some crazy reason also listened to udp - you'd just replace "tcp" with "(tcp udp)"). Being able to set variables is also fantastic. E.g.: @def $DEV_PRIVATE = (eth0 eth1); [1] https://github.com/MaxKellermann/ferm https://github.com/MaxKellermann/ferm
- zhynn 10y ago
  Also, FireHOL [1] is an interesting option. It also has a DSL for managing firewall rules. The custom service port definition is a little weird, but overall I like it better than ferm. [1] https://firehol.org/ https://firehol.org/

by tmaly 10y ago

throwanem 10y ago

Seconding the recommendation to avoid ufw. I haven't actually used it or had a problem with it, but if you understand iptables then you don't need it, and if you don't understand iptables, you're better off just learning to use iptables directly so you can handle those cases that ufw doesn't support or clean up after it when it breaks. I didn't know about iptables-persistent, but it's easy enough to just "iptables-save > /etc/network/iptables" once you're finished changing the config, and "iptables-restore < /etc/network/iptables" in /etc/rc.local. Pretty sure those binaries come with iptables itself, so they should always be available. (I've never dealt with a system that had iptables where they weren't.)

tmaly 10y ago
I recommend iptables-persistent because fail2ban is adding rules dynamically, and it just makes it easier to handle with that aspect automated.
- throwanem 10y ago
  I didn't notice that iptables-persistent actually saves the currently configured rules periodically. That's both kinda neat and a little scary, and I'm not entirely sure I see much value in persisting dynamic rules; it seems like it'd be easy to end up with a long chain of stale rules that way. Still worth knowing about the automatic persistence, though.
  - porker 10y ago
    Surely as rules are deleted they disappear from the saved copy? Or is the issue that fail2ban et al don't remove stale rules?
    - throwanem 10y ago
      It does, but I seem to remember it having trouble cleaning up after itself when abruptly terminated and restarted. It's been a few years, though, so that's probably no longer an issue.

vidarh 10y ago

Ferm [1] is wonderful as an iptables frontend. Apart from making it simpler to read, it can avoid a lot of repetition with handy shortcuts such as ability to group things. E.g.: proto tcp dport (smtp ssmtp qmtp pop3 pop3s imap2 imap3 imaps) ACCEPT; .. creates rules for each of the ports listed. You can use multiple groups in the same statement as well (lets say all the services above for some crazy reason also listened to udp - you'd just replace "tcp" with "(tcp udp)"). Being able to set variables is also fantastic. E.g.: @def $DEV_PRIVATE = (eth0 eth1); [1] https://github.com/MaxKellermann/ferm https://github.com/MaxKellermann/ferm

zhynn 10y ago
Also, FireHOL [1] is an interesting option. It also has a DSL for managing firewall rules. The custom service port definition is a little weird, but overall I like it better than ferm. [1] https://firehol.org/ https://firehol.org/