emacs-elpa-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[elpa] externals/nftables-mode f354d71598 13/41: break prologue (nee PRE


From: Stefan Monnier
Subject: [elpa] externals/nftables-mode f354d71598 13/41: break prologue (nee PRELUDE) out of input
Date: Mon, 23 May 2022 09:27:23 -0400 (EDT)

branch: externals/nftables-mode
commit f354d71598d0c97d32c764b3cdea774911eea440
Author: Trent W. Buck <trentbuck@gmail.com>
Commit: Trent W. Buck <trentbuck@gmail.com>

    break prologue (nee PRELUDE) out of input
---
 nftables-router.nft | 68 +++++++++++++++++++++++++++++++++--------------------
 1 file changed, 43 insertions(+), 25 deletions(-)

diff --git a/nftables-router.nft b/nftables-router.nft
index 842ee961b4..fb35c54ac2 100644
--- a/nftables-router.nft
+++ b/nftables-router.nft
@@ -94,24 +94,11 @@ flush ruleset
 
 
 table inet my_filter {
+
     chain my_input {
         type filter hook input priority filter
         policy drop
-        # Typically 99%+ of packets are part of an already-established flow.
-        # Allow those first, so we're a fast, stateful firewall.
-        # After this only "ct state new" (or "ct state untracked") will remain.
-        # FIXME: is a vmap here better (more efficient) than two separate 
rules?
-        # FIXME: {established or related: accept} does not match correctly!
-        ct state vmap { established: accept, related: accept, invalid: drop }
-
-        # Loopback traffic is needed for e.g. NFS RPC, and for debugging.
-        # FIXME: is iiftype here better than iif/iifname?
-        iiftype loopback  accept
-
-        # Allow *some* kinds of IPv4/ICMP and IPv6/ICMPv6.
-        # FIXME: are "ip protocol icmp" and "ip6 nexthdr icmpv6" needed?
-        ip protocol icmp  icmp type vmap @ICMP_policy
-        ip6 nexthdr icmpv6  icmpv6 type vmap @ICMPv6_RFC4890_policy
+        jump my_prologue  comment "deal with boring 
conntrack/loopback/ICMP/ICMPv6"
 
         # YOUR RULES HERE.
         # NOTE: service names resolve via nss (/etc/hosts) only in nft 0.9.1+!
@@ -125,23 +112,28 @@ table inet my_filter {
         ##FOR "router" EXAMPLE##iif enp11s0 tcp dport domain accept
         ##FOR "router" EXAMPLE##iif enp11s0 udp dport { domain, ntp, bootps } 
accept
 
-        # Finally, politely reject all other attempts.
-        # Omit to use the default policy ("policy drop", above) instead.
-        reject
+        jump my_epilogue
     }
 
-    # A host can't route unless you explicitly enable it, e.g.:
-    #
-    #   sysctl net/ipv4/ip_forward=1
-    #   sysctl net/ipv6/conf/all/forwarding=1
-    #
-    # We create a "deny all" inet filter forward chain anyway, as
-    # defense-in-depth against someone enabling routing ACCIDENTALLY.
+
     chain my_forward {
         type filter hook forward priority filter
         policy drop
+        jump my_prologue  comment "deal with boring 
conntrack/loopback/ICMP/ICMPv6"
+
+        # YOUR RULES HERE.
+        # NOTE: service names resolve via nss (/etc/hosts) only in nft 0.9.1+!
+        # NOTE: a single rule CAN match "allow 53/tcp and 53/udp", but it's 
UGLY, so we don't.
+        # NOTE: I assume you used systemd (networkd or udev) to rename 
"enp0s0f0" to "lan".
+        tcp dport ssh  accept
+        tcp dport { http, https }  accept
+        iifname lan  tcp dport domain  accept
+        iifname lan  udp dport { domain, ntp, bootps }  accept
+
+        jump my_epilogue
     }
 
+
     # We want output to be "allow all", so we don't even create a chain.
     #chain my_output {
     #    type filter hook output priority filter
@@ -149,6 +141,32 @@ table inet my_filter {
     #}
 
 
+    chain my_prologue {
+        # Typically 99%+ of packets are part of an already-established flow.
+        # Allow those first, so we're a fast, stateful firewall.
+        # After this only "ct state new" (or "ct state untracked") will remain.
+        # FIXME: is a vmap here better (more efficient) than two separate 
rules?
+        # FIXME: {established or related: accept} does not match correctly!
+        ct state vmap { established: accept, related: accept, invalid: drop }
+
+        # Loopback traffic is needed for e.g. NFS RPC, and for debugging.
+        # FIXME: is iiftype here better than iif/iifname?
+        iiftype loopback  accept
+
+        # Allow *some* kinds of IPv4/ICMP and IPv6/ICMPv6.
+        # FIXME: are "ip protocol icmp" and "ip6 nexthdr icmpv6" needed?
+        ip protocol icmp  icmp type vmap @ICMP_policy
+        ip6 nexthdr icmpv6  icmpv6 type vmap @ICMPv6_RFC4890_policy
+
+    }
+
+    chain my_epilogue {
+        # Finally, politely reject all other attempts.
+        # Omit to use the default policy ("policy drop", above) instead.
+        reject
+    }
+
+
     # Allow all ICMPv6 is wrong (insecure);
     # Deny all ICMPv6 is wrong (breaks IPv6).
     # The following vmap merges RFC 4890 4.4 (for hosts) and 4.4 (for routers).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]