Iptables best practices for a public time server

Server operators
#1

My public time server (stratum 2) has the following iptables configuration.

Is there anything I should adjust or optimize? Performance seems good and the logs are clean.

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p udp -m udp --dport 123 -j NOTRACK
-A OUTPUT -p udp -m udp --sport 123 -j NOTRACK
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp --destination-port 22 -j DROP
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
#2

You can do it without manual IP-tables in total.

You can simply block sshd.conf to listen only to local adresses and ignore everything else.

Just make sure you don’t have services running that are unwanted.

For hackers I use fail2ban that blocks attempts for 30 minutes.

It’s a sort of auto-firewall-robot that writes IP-tables based on log-errors and it works very well.

#3

Yes, Fail2ban is a great solution.

I was reading Avoiding the linux statefull firewall for some traffic / 2018-01-23 - Koos van den Hout and that’s why I’ve added these rules.

Seems like good advice?

#4

You can do that, but modern kernels detect DDos attacks and stop responding.
When a DDos starts on your system, there isn’t much you can do then wait for it to stop.

However, I have not seen many of those attacks on NTP servers as there are counter measures taken some time ago.

You may want to check this page out:

https://www.ntppool.org/join/configuration.html

I’m not worried over this, there are no current reports of NTP-server problems, else the forum would be filled with people telling others about it.

#5

Needless to say, this might not be the case if your server is some VPS, outside your home (unless you only log in to it via a remote console session or so).

The NOTRACK-part of the iptables is good. From what I can tell, the configuration makes sense (disclaimer: I only briefly went over it).

3 Likes
#6

As @marco.davids guessed, my time server runs on a VPS. That was the reason I have 22 in my rules.

#7

Did you check your running severs with ‘netstat -l’ ?

I would remove all unwanted services in any case, as they use CPU-power for nothing.

Also, remote desktops etc is a waste of CPU-cycles, SSH is a far better way of accessing a Linux-blackbox.

SSH defaults to MaxAuthTries 6, after it starts make it difficult to try further attempts.

Typical machines are not hacked via SSH but rather via poorly programmed php-script running on http-servers.
Or systems that leave config-scripts in place. People that use simplistic and/or default passwords.

Script-kiddies will try, but fail2ban solves that.

As said before, I do not use manual written iptables at all. I rather remove all unwanted services from running.

I do not trust firewalls for my defense, they are an add-on but not the first step.

E.g. if your system is running Apache-http server and they manage to install a terminal-program via http-injection, they are half way into your system and your firewall has no clue if port 80 is allowed.

That is my problem with firewalls :slight_smile:

#8

Heh!

So it is a clean up-to-date installation of the latest Ubuntu LTS.

I do have a web server running but that’s NGINX. It displays nice graphs produced by vnStat.

These are the active sockets;

Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  2      [ ACC ]     SEQPACKET  LISTENING     15881    /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     21446    /var/snap/lxd/common/lxd/unix.socket
unix  2      [ ACC ]     STREAM     LISTENING     187283   /run/user/0/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     187289   /run/user/0/bus
unix  2      [ ACC ]     STREAM     LISTENING     187290   /run/user/0/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     187291   /run/user/0/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     187292   /run/user/0/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     15863    @/org/kernel/linux/storage/multipathd
unix  2      [ ACC ]     STREAM     LISTENING     187293   /run/user/0/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     15850    /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     187294   /run/user/0/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     187295   /run/user/0/pk-debconf-socket
unix  2      [ ACC ]     STREAM     LISTENING     15852    /run/systemd/userdb/io.systemd.DynamicUser
unix  2      [ ACC ]     STREAM     LISTENING     187296   /run/user/0/snapd-session-agent.socket
unix  2      [ ACC ]     STREAM     LISTENING     15861    /run/lvm/lvmpolld.socket
unix  2      [ ACC ]     STREAM     LISTENING     15866    /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     15876    /run/systemd/journal/stdout
unix  2      [ ACC ]     STREAM     LISTENING     21431    /run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     21443    /run/fcgiwrap.socket
unix  2      [ ACC ]     STREAM     LISTENING     21448    /run/snapd.socket
unix  2      [ ACC ]     STREAM     LISTENING     21450    /run/snapd-snap.socket
unix  2      [ ACC ]     STREAM     LISTENING     17018    /run/systemd/journal/io.systemd.journal
unix  2      [ ACC ]     STREAM     LISTENING     21452    /run/uuidd/request
unix  2      [ ACC ]     STREAM     LISTENING     21445    @ISCSIADM_ABSTRACT_NAMESPACE
#9

You need to look at the top part of nstat -l

it shows tcp and udp services. :slight_smile:

But you seem to run snap, snap is crap :yawning_face:

Sorry to say, Ubuntu is not a good platform for servers, most of us use Debian.

1 Like
#10

Snap is there for certbot to make life easy.

I’ve been working with both Ubuntu and Debian as a server OS for many, many years but never really got into trouble with Ubuntu.

#11

Some sidenodes :slight_smile:

Use acme.sh instead if certbot - no need of python / snap

And far as i can you are already run iptables filter in ACCEPT mode, i think you don’t need the accept rule for udp 123 and RELATED,ESTABLISHED

If you running chrony you could also add NTS support.

#12

Thanks! I’ll look into acme.sh

#13

I did, many times. For me Ubuntu is a no-go on servers, that is all Debian.
Desktop, Mint, also no-Ubuntu as it’s not stable in upgrades and changes/breaks things all the time.

Mint is Ubuntu too but doesn’t use Snap, and they have a good reason for that, Snap makes the programs as blunted as Windows does.
Also it makes it use far more cpu-cycles then needed.

As long as you stay inside the box there are no issues, but try outside the box and Ubuntu breaks rules all the time.

For me it’s Debian on servers and Mint-Mate on Desktops…no snap and it works good, even outside the box :smile:

1 Like
#14

This post was flagged by the community and is temporarily hidden.