Are these rules really useful?

Jason.nix · 12-19-2023, 01:13 AM

Hello,
I found these iptables rules:

Code:

# DROP XMAS PACKETS
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# DROP NULL PACKETS
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# DROP EXCESSIVE TCP RST PACKETS
-A INPUT -p tcp -m tcp --tcp-flags RST RST -m limit --limit 2/second --limit-burst 2 -j ACCEPT

# DROP ALL INVALID PACKETS
-A INPUT -m state --state INVALID -j DROP
-A FORWARD -m state --state INVALID -j DROP
-A OUTPUT -m state --state INVALID -j DROP

# DROP RFC1918 PACKETS
-A INPUT -s 10.0.0.0/8 -j DROP
-A INPUT -s 172.16.0.0/12 -j DROP
-A INPUT -s 192.168.0.0/16 -j DROP

# DROP SPOOFED PACKETS
-A INPUT -s 169.254.0.0/16 -j DROP
-A INPUT -s 127.0.0.0/8 -j DROP
-A INPUT -s 224.0.0.0/4 -j DROP
-A INPUT -d 224.0.0.0/4 -j DROP
-A INPUT -s 240.0.0.0/5 -j DROP
-A INPUT -d 240.0.0.0/5 -j DROP
-A INPUT -s 0.0.0.0/8 -j DROP
-A INPUT -d 0.0.0.0/8 -j DROP
-A INPUT -d 239.255.255.0/24 -j DROP
-A INPUT -d 255.255.255.255 -j DROP

# ICMP SMURF ATTACKS + RATE LIMIT THE REST
-A INPUT -p icmp --icmp-type address-mask-request -j DROP
-A INPUT -p icmp --icmp-type timestamp-request -j DROP
-A INPUT -p icmp --icmp-type router-solicitation -j DROP
-A INPUT -p icmp -m limit --limit 2/second -j ACCEPT

# DROP SYN-FLOOD PACKETS
-A INPUT -p tcp -m state --state NEW -m limit --limit 50/second --limit-burst 50 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -j DROP

Can these rules help a server against attacks?

Thank you.

Turbocapitalist · 12-19-2023, 01:59 AM

I'd say they are not that useful in general because of three reasons. First, they are old IPTables rules and things have moved on to NFTables, which is easier to work with and where the kernel development is happening. Second, the first point aside, the rules make no differentiation between network interfaces so you can potentially have problems with the loopback in some cases. Lastly, many attacks (and most which I have seen on my production systems) of late are distributed in nature and can only be addressed further up in the network.

Rules like the above, could be fine tuned a bit for more accuracy, such as providing default policies. However, if you are just getting started, you ought to work with NFTables instead of IPTables.

Jason.nix · 12-19-2023, 04:14 AM

Quote:

Originally Posted by Turbocapitalist

I'd say they are not that useful in general because of three reasons. First, they are old IPTables rules and things have moved on to NFTables, which is easier to work with and where the kernel development is happening. Second, the first point aside, the rules make no differentiation between network interfaces so you can potentially have problems with the loopback in some cases. Lastly, many attacks (and most which I have seen on my production systems) of late are distributed in nature and can only be addressed further up in the network.

Rules like the above, could be fine tuned a bit for more accuracy, such as providing default policies. However, if you are just getting started, you ought to work with NFTables instead of IPTables.

Hello,
Thank you for your advice.
Consider a server with a network card. Are these rules better than nothing?

zeebra · 12-19-2023, 07:05 AM

Quote:

Originally Posted by Turbocapitalist

I'd say they are not that useful in general because of three reasons. First, they are old IPTables rules and things have moved on to NFTables, which is easier to work with and where the kernel development is happening. Second, the first point aside, the rules make no differentiation between network interfaces so you can potentially have problems with the loopback in some cases. Lastly, many attacks (and most which I have seen on my production systems) of late are distributed in nature and can only be addressed further up in the network.

Rules like the above, could be fine tuned a bit for more accuracy, such as providing default policies. However, if you are just getting started, you ought to work with NFTables instead of IPTables.

Strangely enough, alot of people use iptables instead of nftables. It might even be more popular than nftables, and many consider iptables easier to work with. Even several big packages use iptables rather than nftables, by default.

If iptables were obsolete and/or didn't work, they would be removed from the Kernel. So they work perfectly fine.

The thing now is that everyone might just be able to skip nftables entirely and move from iptables to bpfilter directly at some point. Strangely enough, people working on bpfiler are making special provisions for people to move from iptables to bpfiler (eventually), rather than nftables to bpfilter, which makes me think that they also think iptables is more popular than nftables.

You could perhaps even say nftables were dead on arrival.

Turbocapitalist · 12-19-2023, 07:29 AM

Not really. IPTables development has been in a holding pattern at best. I looked into some problems with IPTables some years ago and found that there were no plans to fix them, ever, and was steered to NFTables by the netfilter list. There seems to be no effort expended on IPTables lately either way, either to improve it or to eradicate it.

Despite my years of using IPTables, I find NFTables much easier to use and work with and have found it so since day one. It's definitely a step closer to PF which is basically the gold standard for network filtering.

What IPTables does have going for it would be the countless number of outdated and sometimes outright wrong pages about it on the WWW. By all means you can keep using IPTables if you are already familiar with it, it will have a long tail. But it is neither the easy way nor is it the way forward for a beginner. The netfilter mailing list certainly seems to have moved on from IPTables.

zeebra · 12-19-2023, 07:50 AM

There is nothing wrong with using either iptables or nftables. Anyways, both will slowly become obsolete with bpfilter. As I understand it, the way rules are processed in bpf will just make nftables and iptables obsolete due to the speed and cost of looking up things.

I don't mind nftables, but I don't want to learn it, I'd rather wait for bpfilter to mature.

The objection I have with nftables personally is the more complex syntax, which makes it utterly untempting to learn it now. If bpfilter wasn't a prospect, things might be different. But the main migration focus seems to be to allow people using iptables a smooth transition to bpfilter, migrating iptable rules "perfectly" over to bpfilter. This is particularly important due to so many organizations using super complex iptable rulesets of 10.000+ rules and so, which also happens to be the strength of the future bpfilter solution (and which nftables offer no solution to).

Anyways, all I was saying really, is that it's fine to use iptables, and many do. But yeah, you're quite right, for a newbie it's probably better to jump straight into nftables, despite the lack of good documentation.

Turbocapitalist · 12-19-2023, 07:52 AM

Quote:

Originally Posted by zeebra

I don't mind nftables, but I don't want to learn it, I'd rather wait for bpfilter to mature.

I found a LWN article on BPF, is there anything more recent? It sounds interesting but seems off in the indefinite future.

zeebra · 12-19-2023, 07:56 AM

Quote:

Originally Posted by Turbocapitalist

I found a LWN article on BPF, is there anything more recent? It sounds interesting but seems off in the indefinite future.

Yeah, but it will take some active searching. I've been looking around a few weeks ago on the topic, and there really is alot of interesting development going on despite the seeming "quiet". It also helps to follow/look into the development of ebpf. Anyways, good and even recent info exists, but it's not exactly easy to find.

The maintainer of ebpf is a good trail to follow.. Don't remember his name.. Also, some major companies have already moved to bpf, and there are some interesting projects too, which I also forgot the name of. Anyways, it's a work in progress and not exactly super fast. These things were announced and mentioned even earlier than 2018, like 2015-2016. So if things were fast, most people could use it by now..

And there are the "concerns" about ebfp as well, so..

And well, perhaps search "migration from iptables to bpfilter" or something like that. It was one of the more interesting and detailed articles I found on the topic, pointing to real work being done and preparation for migration being "well"(?) underway. But I personally don't expect any major changes in the situation for regular people the next few years.

rknichols · 12-19-2023, 08:21 AM

Quote:

Originally Posted by Turbocapitalist

Second, the first point aside, the rules make no differentiation between network interfaces so you can potentially have problems with the loopback in some cases.

The interfaces are not shown because the listing was generated without using the "-v" (--verbose) option in the iptables command.

Turbocapitalist · 12-19-2023, 08:28 AM

Quote:

Originally Posted by rknichols

The interfaces are not shown because the listing was generated without using the "-v" (--verbose) option in the iptables command.

Also iptables-save generally gives useful output too.

Turbocapitalist · 12-19-2023, 09:30 AM

Quote:

Originally Posted by Jason.nix

Hello,
I found these iptables rules

Looking at them more closely they are more likely to lock you out.

Below is a sample to start from to get you going with your server. You'd put the rules in ~/nft.conf invoke it from nft -f ~/nft.conf, then once it is the way you like it and you are very certain not to lock yourself out, you can move it to /etc/nft.conf

Code:

#!/usr/sbin/nft -f

# Clear all prior state
flush ruleset

# Basic IPv4/IPv6 stateful firewall 
table inet filter {

        chain input {
                type filter hook input priority 0; policy drop;

		# accept local host traffic
                iifname "lo" ip saddr 127.0.0.0/8 ip daddr 127.0.0.0/8 \
		counter accept
		iifname "lo" ip6 saddr ::1 ip6 daddr ::1 \
		counter accept

                #  Accept traffic originated from us
                ct state { established, related } accept

                # Drop invalid connections
                ct state invalid drop

                # Reject AUTH to make it fail fast
                tcp dport 113 reject with icmpx type port-unreachable

                tcp dport   22 ct state new limit rate 4/minute counter accept

                # adjust these as needed
                tcp dport   80 ct state new counter accept
                tcp dport  443 ct state new counter accept
                tcp dport 1965 ct state new counter accept
                tcp dport 6667 ct state new counter accept

                # ICMPv4

                # Accept ICMP
                ip protocol icmp icmp type {
                        echo-reply,  # type 0
                        destination-unreachable,  # type 3
                        echo-request,  # type 8
                        time-exceeded,  # type 11
                        parameter-problem,  # type 12
                } accept

                # ICMPv6
                # Accept basic IPv6 functionality
                ip6 nexthdr icmpv6 icmpv6 type {
                        destination-unreachable,  # type 1
                        packet-too-big,  # type 2
                        time-exceeded,  # type 3
                        parameter-problem,  # type 4
                        echo-request,  # type 128
                        echo-reply,  # type 129
                } accept

                #  Allow IPv6 SLAAC
                ip6 nexthdr icmpv6 icmpv6 type {
                        nd-router-solicit,  # type 133
                        nd-router-advert,  # type 134
                        nd-neighbor-solicit,  # type 135
                        nd-neighbor-advert,  # type 136
                } ip6 hoplimit 255 accept

                # Allow IPv6 multicast listener discovery on link-local
                ip6 nexthdr icmpv6 icmpv6 type {
                        mld-listener-query,  # type 130
                        mld-listener-report,  # type 131
                        mld-listener-reduction,  # type 132
                        mld2-listener-report,  # type 143
                } ip6 saddr fe80::/10 accept

                #  Accept DHCPv6 replies from IPv6 link-local addresses
                ip6 saddr fe80::/10 udp sport 547 udp dport 546 accept
        }

        chain forward {
                type filter hook forward priority 0; policy drop;
        }

        chain output {
                type filter hook output priority 0; policy accept;
        }
}

include "/etc/nftables.d/*.nft"

If you are experimenting with a remote server then you need to have some kind of out of band access like a console to get back in if you locked yourself out. There are other tricks like with at too.

Edit: again, many types of attack cannot be mitigated at the host level.

jayjwa · 12-19-2023, 12:48 PM

Those commands aren't going to make any noticable difference for you in the wild. Even worse, you might shoot yourself in the foot with them when something doesn't work when you expect it to (like dropping rfc1918 packets and then wondering why your LAN hosts can't connect). In reality, almost no one is going to send XMAS packets to you and even if they did, who cares? Most of what you'll see is this:

Someone tries to upload Windows malware, usually crypto miners like Xmrig to your ftp service
Someone tries to relay through your mailserver or tries a DSN attack
If you allow name/password login services like SSH, Telnet, or RDP, they try basic logins/passwords
They send garbage to www server's applications like Wordpress to make it do what they want
You anger someone and they hire a booter to DDoS you
Someone runs Metaspoilt on your (old) service to try to get a shell

and none of those rules will help much at all with this stuff.

Jason.nix · 12-28-2023, 09:58 AM

Quote:

Originally Posted by zeebra

Strangely enough, alot of people use iptables instead of nftables. It might even be more popular than nftables, and many consider iptables easier to work with. Even several big packages use iptables rather than nftables, by default.

If iptables were obsolete and/or didn't work, they would be removed from the Kernel. So they work perfectly fine.

The thing now is that everyone might just be able to skip nftables entirely and move from iptables to bpfilter directly at some point. Strangely enough, people working on bpfiler are making special provisions for people to move from iptables to bpfiler (eventually), rather than nftables to bpfilter, which makes me think that they also think iptables is more popular than nftables.

You could perhaps even say nftables were dead on arrival.

Hello,
Thank you so much for your reply.
Is Bpfilter for facebook? About its performance, I found this article. Have you personally used it?

slac-in-the-box · 12-28-2023, 06:31 PM

Code:

# DROP XMAS PACKETS
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP

OMG! That explains why Santa didn't make it down my chimney!

zeebra · 01-04-2024, 07:53 AM

Quote:

Originally Posted by Jason.nix

Hello,
Thank you so much for your reply.
Is Bpfilter for facebook? About its performance, I found this article. Have you personally used it?

Nah, it's more of a "future thing" for regular folks as of now, and yes, alot of the work with it is being done at major corporations who work with gigantic amounts of data and servers, and some of them already use it proper is what I've read. Like those companies or not, some form of that work is likely to make it into the Kernel at some point (some already has) and create the foundation for the next generation of Linux firwewalls. However, the concept is not new, BPF actually stands for Berkley Packet Filter, or something like that, it's BSD filter/firewall. But the implementation in the Linux Kernel seems to be taking on a quite different, and more complex form. That's where the eBPF comes into the picture, and a range of additional use (dangerous or not) is also being proposed for it, taking it far beyond the scope of just using it for firewall/filter (including rootkits). Probably a BPFILTER for everyday use is still some years off, or so it seems. eBPF is a rather complex topic, but an interesting read too.

Personally I just use iptables, but I'm just a guy (and don't really even need it), but then again, many corporations and businesses also use iptables still, with tens of thousands of iptable rules. This is where the problem is found, because processing such complex rulesets takes alot of time/resources. Perhaps think of it as line by line processing. The advantage of BPF is that it process all lines at the same time, and just extract matches from it, with minimum effort/time/cost, this is the main advantage of it from my understanding.

Anyways, what was initially just thought of as a filter mechanism, turned into an octopus with tentacles, with many potential uses and complexities, which might be why the process it taking alot longer than one should have reasonably assumed at the beginning.