IP Tables

hosney00ux · 10-27-2022, 02:46 AM

Dears
this is my iptables rules
i need assistance in 2 things
1) could you please review and if you optimize it please help me on that
2) all first log command not working from my side

Code:

BSD-NDN:/home/hosneyosman/Documents # lsb_release -a
LSB Version:    n/a
Distributor ID: openSUSE
Description:    openSUSE Tumbleweed
Release:        20221025
Codename:       n/a
BSD-NDN:/home/hosneyosman/Documents #

Code:

BSD-NDN:/home/hosneyosman/Documents # iptables --version 
iptables v1.8.8 (legacy)
BSD-NDN:/home/hosneyosman/Documents #

Code:

#!/bin/bash

## 01. Log INPUT traffic
iptables -I INPUT 1 -j LOG

## 02. Log FORWARD Traffic
iptables -I FORWARD 1 -j LOG

## 03. Log OUTPUT Traffic
iptables -I OUTPUT 1 -j LOG

## 04. To log network activity in the NAT table execute the following commands for tracking activity in their respective chains
iptables -t nat -I PREROUTING 1 -j LOG
iptables -t nat -I POSTROUTING 1 -j LOG
iptables -t nat -I OUTPUT 1 -j LOG

## 05. IP Tables Flush Command
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

## 06. default policy for each of the chains
iptables --policy INPUT DROP
iptables --policy FORWARD DROP
iptables --policy OUTPUT DROP

## 07. Open LoopBack Interface
iptables --append INPUT --in-interface lo --jump ACCEPT
iptables --append OUTPUT --out-interface lo --jump ACCEPT

## 08. Allow Connections Initiated by the Machine
## Allow Connection Initiated by wireless interface
iptables --append OUTPUT --out-interface wlp2s0 --jump ACCEPT
## Allow Connection Initiated by wire interface
iptables --append OUTPUT --out-interface enp0s31f6 --jump ACCEPT
iptables --append INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT

## 09. Filter untrusted traffic
iptables -A INPUT --in-interface wlp2s0
iptables -A INPUT --in-interface enp0s31f6

## 10. Block Invalid Packets
## This rule blocks all packets that are not a SYN packet and don’t belong to an established TCP connection.

iptables -t mangle -A PREROUTING -m conntrack --ctstate INVALID -j DROP

## 11. Block New Packets That Are Not SYN
## This blocks all packets that are new (don’t belong to an established connection) and don’t use the SYN flag.
## This rule is similar to the “Block Invalid Packets” one, but we found that it catches some packets that the other one doesn’t.
iptables -t mangle -A PREROUTING -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

## 12. Block Uncommon MSS Values
## The above iptables rule blocks new packets (only SYN packets can be new packets as per the two previous rules)
## that use a TCP MSS value that is not common. This helps to block dumb SYN floods.
iptables -t mangle -A PREROUTING -p tcp -m conntrack --ctstate NEW -m tcpmss ! --mss 536:65535 -j DROP

## 13. Block Packets With Bogus TCP Flags
## The below ruleset blocks packets that use bogus TCP flags, ie. TCP flags that legitimate packets wouldn’t use.
iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP
iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP

## 14. Block Packets From Private Subnets (Spoofing)
## These rules block spoofed packets originating from private (local) subnets.
## On your public network interface you usually don’t want to receive packets from private source IPs.
## These rules assume that your loopback interface uses the 127.0.0.0/8 IP space.
## These five sets of rules alone already block many TCP-based DDoS attacks at very high packet rates.
## With the kernel settings and rules mentioned above, you’ll be able to filter ACK and SYN-ACK attacks at line rate.
iptables -t mangle -A PREROUTING -s 224.0.0.0/3 -j DROP
iptables -t mangle -A PREROUTING -s 169.254.0.0/16 -j DROP
iptables -t mangle -A PREROUTING -s 172.16.0.0/12 -j DROP
iptables -t mangle -A PREROUTING -s 192.0.2.0/24 -j DROP
iptables -t mangle -A PREROUTING -s 192.168.0.0/16 -j DROP
iptables -t mangle -A PREROUTING -s 10.0.0.0/8 -j DROP
iptables -t mangle -A PREROUTING -s 0.0.0.0/8 -j DROP
iptables -t mangle -A PREROUTING -s 240.0.0.0/5 -j DROP
iptables -t mangle -A PREROUTING -s 127.0.0.0/8 ! -i lo -j DROP

## 15. Additional Rules
## This drops all ICMP packets. ICMP is only used to ping a host to find out if it’s still alive.
## Because it’s usually not needed and only represents another vulnerability that attackers can exploit,
## we block all ICMP packets to mitigate Ping of Death (ping flood), ICMP flood and ICMP fragmentation flood.

iptables -t mangle -A PREROUTING -p icmp -j DROP

## 16. This iptables rule helps against connection attacks.
## It rejects connections from hosts that have more than 80 established connections.
## If you face any issues you should raise the limit as this could cause troubles with
## legitimate clients that establish a large number of TCP connections.
iptables -A INPUT -p tcp -m connlimit --connlimit-above 80 -j REJECT --reject-with tcp-reset

## 17. Limits the new TCP connections that a client can establish per second.
## This can be useful against connection attacks,
## but not so much against SYN floods because the usually use an endless amount of different spoofed source IPs.
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT
iptables -A INPUT -p tcp -m conntrack --ctstate NEW -j DROP

## 18. This rule blocks fragmented packets.
## Normally you don’t need those and blocking fragments will mitigate UDP fragmentation flood.
## But most of the time UDP fragmentation floods use a high amount of bandwidth that is likely to exhaust the capacity of your network card,
## which makes this rule optional and probably not the most useful one.
iptables -t mangle -A PREROUTING -f -j DROP

## 19. This limits incoming TCP RST packets to mitigate TCP RST floods. Effectiveness of this rule is questionable.
iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT
iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP

## 20. Mitigating SYN Floods With SYNPROXY
## SYNPROXY is a new target of iptables that has been added in Linux kernel version 3.12 and iptables 1.4.21.
## CentOS 7 backported the feature and it’s available in its 3.10 default kernel.
## The purpose of SYNPROXY is to check whether the host that sent the SYN packet actually establishes a full TCP connection
## or just does nothing after it sent the SYN packet.
## If it does nothing, it discards the packet with minimal performance impact.
## While the iptables rules that we provided above already block most TCP-based attacks,
## the attack type that can still slip through them if sophisticated enough is a SYN flood.
## It’s important to note that the performance of the rules will always be better if we find a certain pattern or signature to block,
## such as packet length (-m length), TOS (-m tos), TTL (-m ttl) or strings and hex values (-m string and -m u32 for the more advanced users).
## But in some rare cases that’s not possible or at least not easy to achieve. So, in these cases, you can make use of SYNPROXY.
## Here are iptables SYNPROXY rules that help mitigate SYN floods that bypass our other rules:
iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

michaelk · 10-27-2022, 05:36 PM

Quote:

all first log command not working from my side
## 05. IP Tables Flush Command

Which means that all rules added in "steps" 1-4 are now flushed i.e deleted.

astrogeek · 10-27-2022, 06:59 PM

As already pointed out, the flush command removes all previously entered rules.

The rules then set a default policy of ACCEPT for all traffic, followed immediately by setting a policy of DROP for all traffic, which makes little sense.

The remaining sets of rules include some which have no effect at all except perhaps to count packets, and others which may have useful effect when used in a well structured context, but there is no meaningful structure to the rules overall.

As such, there is little that anyone could help to optimize because these are all just rules without any guiding context which says what you are trying to accomplish.

This last point, the need for structure is the place to start: write a brief description of what you want you iptables firewall to accomplish for you, then study the online documentation - and I recommend the man pages as an important source to consult - and learn what features are available to accomplish your goals.

Important things to understand include:

* Understand the overall structure imposed by iptables, for example: iptables flow
* Then add structure by your own rules and chains within that flow to accomplish your goals
* Understand clearly that every packet will traverse every rule along its path until some rule ACCEPTs or DROPs/REJECTs it
* Understand that the policy (-P or --policy) determines what happens to packets not handled by any rule

Optimization consists largely of identiying packets that you want to DROP or ACCEPT early in the flow, before they traverse long sets of irrelevant rules.

But it is most important that you understand what each rule actually does for you, and how to best make use of it. Copying rules from around the internet can be instructional and useful as learning tools, but in the end you must write your own to work within your own systems to meet your own goals. There is no "one size fits all" solution!

Begin with a single goal, write a rule or a few rules that accomplish that goal and verify that it works as intended... then take on the next goal... when you are done you will have a rule set that works for you, and which you understand!

Good luck!

xlfs-0.2 · 12-25-2022, 11:56 PM

YOU FORGOT FORWARDING RULES.

(debian sarge and or old firefox) apps would forward suspiciously to get around firewall.

looks pretty typical. TDLP.org? You've been doing some homework it looks like.

the most important think is to block your lower PORTS from any access and also any software ports (Xorg, sshd, rsync sendmail rscsi) that you arent intentionally wanting coms on.

xlfs-0.2 · 12-25-2022, 11:57 PM

my fowarding rules are functional and also in limp mode - they won't make sense in a post.

sundialsvcs · 01-03-2023, 10:01 AM

I admit it: I use utilities like shorewall which set up the rules for me. I specify what I want in a much-simpler configuration file and it performs the arcane magick.

The biggest grief with iptables is not that it's hard to get it right, but rather that it's easy to get it wrong and not know it.

jayjwa · 01-26-2023, 03:42 PM

This ruleset is such a mess I don't even know where to begin. Alot of the rules are unneeded, and alot of the rules do nothing. You set default policies that are already the default, only to re-set them (section 05), and then flip them to DROP (section 06). Logging all incoming, forwarding, and outgoing traffic (sections 01-03) will create a massive amount of log entries that will make the log all but useless unless you are parsing it with a utility. Not sure what section 09 is even doing, as it matches on everything coming in those interfaces but doesn't actually act on the traffic. The fancy TCP flag checking is unneeded unless you anger a script kiddie that just discovered Nmap.

Knowning what you are trying to accomplish would be more helpful in writing an iptables ruleset.

1. Are you a client-only host or do others need access to your machine?
2. Do you want default open access or default closed access?
3. Are you running any robust services like SSH?
4. Are you running any tender services like distributed C compilers, RPC, or Samba that the Internet at large generally shouldn't touch?
5. Are you a general user or a high-value target likely to be attacked (such as a financial institutional or shop)?
6. Do you have an internal network?
7. Do you want those services to be reachable or not?

This might be an unpopular opinion, but if you are a general home user not running servers, you really don't need a firewall at all. The exception might be rpcbind, if that is started by default, and even that will respect libwrap rules. The idea that ports need blocking is a hold-over from the old days of Windows 15-20 years ago where it would open alot of ports, unknown to the user, that where easily exploitable. Those services were difficult, if not impossible, to shut down hence the idea that you needed a firewall. People would often misconfigure the "Network Neighborhood" and leave their C:\ open to the nework, which might in fact be the Internet. Many ISPs block those ports by default because of all the problems that came from that.

Modern XServers don't listen on TCP anymore by default, and there's no reason to block mail ports if they are not open to begin with. It's like putting a lock on a brick wall. Of course, if you need to serve MySQL to someone across the Internet then you might want to block all but which IP addresses can actually take a swing at it (same for RPC) but you didn't indicate that. Same thing if you are running a shell server for multiple users.

Not running a service unless you know what you are doing, making sure it listens only where it needs to, proper access configuration, and keeping up-to-date will go alot more towards security than spagetti iptables rules.

xlfs-0.2 · 02-01-2023, 05:16 PM

* linux security is "freely edited" by foreign powers

* windows drivers come from china as binaries without any supervision

* CHIPS have schmidt triggers, timers, circuits that can trigger without any protocol or specification. you have 0 idea what is printed in silicon, nor can you know

* obscurity (most known crypto today) is not security. it's just obscuring. and it gives channels to attackers to hide in (since if they are on your PC the encryption prevents you from knowing what it is that's on your PC due to being encrypted in memory)

* i turn OFF Firefox/Edge "Wallet store" options, on forced update they are turned back on

* Win10, UBUNTU, Apple, REDHAT all require "you submit your root password to them" upon installing - which is immediately sent to them over internet

The best you can do is keep passers by from browsing private data.

Real security? Don't make me laugh!

I'm just teasing, obviously

xlfs-0.2 · 02-01-2023, 05:17 PM

I secured iptables once.

IT REQUIRES READING ALL OF THE LINUX KERNEL INVOLVED to get right for ipv4 (for ipv6 it would be terribly more difficult i haven't tried).

When the kernel changes anything your firewall is no longer "actually secure" since there are race conditions.

Does it change those things. YES. IT DOES.