Critique my firewall

These are my firewall rules. Please tell me the good and bad so I can become BULLETPROOF!!!!!! Or am I already there?

iptables -P OUTPUT  DROP
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j DROP
iptables -A OUTPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j DROP
iptables -N drop_invalid
iptables -A OUTPUT -m state --state INVALID -j drop_invalid
iptables -A INPUT -m state --state INVALID -j drop_invalid
iptables -A INPUT -p tcp -m tcp --sport 1:65535 --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j drop_invalid
iptables -A drop_invalid -j LOG --log-level debug --log-prefix "INVALID state -- DENY"
iptables -A drop_invalid -j DROP
iptables -N In_RULE_0
iptables -A INPUT -i wlan0 -s darkstar -j In_RULE_0
iptables -A In_RULE_0 -j LOG --log-level info --log-prefix "RULE 0 -- DENY"
iptables -A In_RULE_0 -j DROP
iptables -N In_RULE_1
iptables -A INPUT -p icmp -m icmp --icmp-type any -j In_RULE_1
iptables -A In_RULE_1 -j LOG --log-level info --log-prefix "RULE 1 -- DENY"
iptables -A In_RULE_1 -j DROP
iptables -N In_RULE_2
iptables -A INPUT -p tcp -m tcp --dport 43 -j In_RULE_2
iptables -A In_RULE_2 -j LOG --log-level info --log-prefix "RULE 2 -- DENY"
iptables -A In_RULE_2 -j DROP
iptables -N In_RULE_3
iptables -A INPUT -p tcp -m tcp --tcp-flags ALL URG,PSH,FIN -j In_RULE_3
iptables -A In_RULE_3 -j LOG --log-level info --log-prefix "RULE 3 -- DENY"
iptables -A In_RULE_3 -j DROP
iptables -N In_RULE_4
iptables -A INPUT -p tcp -m tcp --tcp-flags ALL URG,ACK,PSH,RST,SYN,FIN -j In_RULE_4
iptables -A In_RULE_4 -j LOG --log-level info --log-prefix "RULE 4 -- DENY"
iptables -A In_RULE_4 -j DROP
iptables -N In_RULE_5
iptables -A INPUT -p all -f -j In_RULE_5
iptables -A In_RULE_5 -j LOG --log-level info --log-prefix "RULE 5 -- DENY"
iptables -A In_RULE_5 -j DROP
iptables -N In_RULE_6
iptables -A INPUT -p udp -m udp --dport 513 -j In_RULE_6
iptables -A In_RULE_6 -j LOG --log-level info --log-prefix "RULE 6 -- DENY"
iptables -A In_RULE_6 -j DROP
iptables -N In_RULE_7
iptables -A INPUT -p udp -m udp --dport 33434:33524 -j In_RULE_7
iptables -A In_RULE_7 -j LOG --log-level info --log-prefix "RULE 7 -- DENY"
iptables -A In_RULE_7 -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j DROP
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp -m udp --sport 67 --dport 68 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp -m udp --sport 123 --dport 123 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 6667 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 6697 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 6881 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 6881 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 8881 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 7881 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 8881 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dports 25,110,143,465,587,993,995 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp -m multiport --dports 500,1701,4500 -m state --state NEW -j ACCEPT
iptables -N RULE_17
iptables -A OUTPUT -p tcp -m tcp --dport 20:21 -j RULE_17
iptables -A OUTPUT -p tcp -m tcp --sport 1024: --dport 1024: -j RULE_17
iptables -A RULE_17 -j LOG --log-level info --log-prefix "RULE 17 -- ACCEPT"
iptables -A RULE_17 -j ACCEPT
iptables -N RULE_18
iptables -A OUTPUT -p 47 -j RULE_18
iptables -A INPUT -p 47 -j RULE_18
iptables -A OUTPUT -p tcp -m tcp --dport 1723 -j RULE_18
iptables -A RULE_18 -j LOG --log-level info --log-prefix "RULE 18 -- ACCEPT"
iptables -A RULE_18 -j ACCEPT
iptables -N RULE_19
iptables -A OUTPUT -p tcp -m tcp --dport 3389 -j RULE_19
iptables -A OUTPUT -p udp -m udp --dport 3389 -j RULE_19
iptables -A RULE_19 -j LOG --log-level info --log-prefix "RULE 19 -- ACCEPT"
iptables -A RULE_19 -j ACCEPT
iptables -N RULE_20
iptables -A OUTPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -j RULE_20
iptables -A INPUT -s 192.168.0.0/24 -d 192.168.0.0/24 -j RULE_20
iptables -A RULE_20 -j LOG --log-level info --log-prefix "RULE 20 -- ACCEPT"
iptables -A RULE_20 -j ACCEPT
iptables -N RULE_21
iptables -A OUTPUT -p udp -m udp -j RULE_21
iptables -A INPUT -p udp -m udp -j RULE_21
iptables -A RULE_21 -j LOG --log-level info --log-prefix "RULE 21 -- DENY"
iptables -A RULE_21 -j DROP
iptables -N RULE_22
iptables -A OUTPUT -p tcp -m tcp -j RULE_22
iptables -A INPUT -p tcp -m tcp -j RULE_22
iptables -A RULE_22 -j LOG --log-level info --log-prefix "RULE 22 -- DENY"
iptables -A RULE_22 -j DROP
iptables -N RULE_23
iptables -A OUTPUT -d darkstar -j RULE_23
iptables -A INPUT -j RULE_23
iptables -A RULE_23 -j LOG --log-level info --log-prefix "RULE 23 -- DENY"
iptables -A RULE_23 -j DROP

It is blindly dropping icmp, and therefore breaks e.g. path MTU discovery.

Give the rules more meaningful *names* than ...1, ...2, to aid readability

There really is no reason to make all those rules i.e., 1 2 3 and so forth. They are doing nothing special that could not be handled in INPUT or OUTPUT. I would also question why you are firewalling the OUTPUT chain? Do you not trust your own system? This could lead to services not working as you are blocking something that needs to be open for the system to operate.

I live by the KISS rule and here are my rules:

/ # iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 192.168.15.101/32 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

The usual order, for performance reasons (matching on the most commonly-occurring and simple-to-decide rules first) is:

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT

ICMP traffic will be relatively rare (but sometimes essential, for reliable communication).

Originally Posted by brebs It is blindly dropping icmp, and therefore breaks e.g. path MTU discovery.

Is PMTU not similar to post office calling every couple of minutes inquiring about dimensions of your mailbox?
They're like, Hi, what is the length of the mailbox slot, what is the height, and what depth? I'm like <click> and I don't even answer calls anymore.
Seriously, I just drop first ask questions later.

Originally Posted by elcore Is PMTU not similar to post office calling every couple of minutes inquiring about dimensions of your mailbox?

No. If there's an MTU mismatch, then it will probably cause intermittently unreliable communication.

Others have helped you with specific firewall rules. I am going to approach your question from a different viewpoint.

First, on becoming 'bullet proof'. You can't and won't. There is a rule of thumb that has yet to be proven wrong: any security system designed by man can be defeated by man. You ignore this at your peril. Security is more a frame of mind than a tool such as a firewall. The firewall is necessary, but is only a tool. Ignoring the rest of a 'security system' can and will be fatal at some point. Saying you want to be 'bullet proof' implies you expect to have a firewall that meets all threats and you no longer have to worry about them. I may have missed something, but I saw no provision for logging. Of course if you are 'bullet proof' I suppose you have no need for logs or to check them to see what is happening, but then how will you know if it has failed at some point or if a new threat has emerged? What is the nature of the threat(s) you are guarding against? What is the source? Personal defense on the battle field changed a bit when firearms started replacing the long bow. Those that missed this fact did not last long. Look at the casualty rates in the American Civil War (AKA the war of northern aggression). Look specifically at Picket's charge at Gettysburg. That question was alluded to in the question about why you are filtering output? Filtering is not necessarily wrong, but is it necessary and does it accomplish anything worthwhile? How much overall performance are you willing to trade for firewall performance? Every rule requires time to process. That time is then not available for doing your actual work. At what point is that a problem? Have you considered port knocking as a security measure in some instances? Could physical security be a problem? Are you doing anything that would bring sophisticated attacks your way like the van sitting outside your location? They do exist, you know. Another factor is the time aspect. A military plan to start an attack at dawn probably needs a different level of security than the national nuclear launch codes. Lets face it, at dawn the enemy will know he is being attacked at dawn so guarding the information may no be longer necessary. Use of comments would also be helpful to those reviewing your firewall as well as to you at a later time (a week from now) when you review it yourself.

The most secure system I know of is a computer that is not connected to the outside world in any way, is in a windowless, doorless room encased in a grounded copper mesh (faraday cage, I believe), powered by a generator that is not connected to the power grid in anyway. etc., etc. I realize there is a problem with this system but it will certainly be secure until somone comes along with a sledge hammer or a stick of dynamite.

The full exercise I refer to may be a pain to do but to ignore it completely is dangerous and makes your firewall efforts of much lesser value.

Originally Posted by brebs No.

So then it's more like sewage company calling every couple of minutes, asking about the pipe diameter?

Originally Posted by brebs If there's an MTU mismatch, then it will probably cause intermittently unreliable communication.

I've seen fragmentation, and there wouldn't be a MTU mismatch, if there was a sane default. Sometimes also called a standard MTU of 1500 for ethernet.
What I've also seen is icmp abuse, and generated icmp packets that are spoofed. Otherwise I wouldn't have dropped the entire protocol.

Originally Posted by elcore standard MTU of 1500 for ethernet.

The problem is, the MTU on one side can easily be reduced, e.g. ADSL uses 8 bytes (the ADSL router itself might be altering packets, to work around this problem).

Just google it - here's an example.

For starters, I know anything man-made will be broken by another man. Was taught that at a young age.

I've only being using Linux on-off for about 3 years and still learning. I got the ruleset from

https://www.wilderssecurity.com/thre...alling.376935/

I assume the guy knows a lot more than me when it comes to linux security and firewalling. So I took the ruleset and adjusted it to my likings.

Nonetheless, its interesting to get feedback from more experience people in the Linux Security field. I'm only here to learn.

Originally Posted by brebs The problem is, the MTU on one side can easily be reduced, e.g. ADSL uses 8 bytes (the ADSL router itself might be altering packets, to work around this problem). Just google it - here's an example.

What I understand from your article is when NEW connection is made, certain routing/switching gear may retain the last used MTU value, in the attempt to offload fragmentation to client, rather than reset the MTU value, is that correct?
I get that some gear opens a way for client to set a value of 1 (for example) and it's retained until icmp response, so if another client on the same route does not icmp respond then it's stuck with MTU of 1.
If the gear is smart enough to dynamically adjust MTU according to client spec but not smart enough to clamp MTU to standard value for NEW connections before inquiring about the client-side value, it's a gear/firmware problem.
Expecting every client to open an icmp floodgate in order to work around arbitrary switch limitations, that's just wishful thinking, it'll never work in practice.

And since you've mentioned it, DSL's not reliable by default, with or without PMTU, for example dynamic address picked from the pool may have been previously used by a compromised machine, and is being hit constantly.
If some of your neighbours on the same dslam are infected with windows malware and you get assigned their link after 24H reset, you too will get telnet/vpn/ssh attempts, floods, and hits on 8080 without actually requesting any of them.

I have activated logging now. Thanks, I had to create a firewall.log file in /var/log/firewall.log and had to edit /etc/syslog.conf with

kern.* /var/log/firewall.log

I can see everything now. This was helpful input.

What about sport vs dport? I really don't understand the difference when one should be use over the other.

sport is the port on the source the packet is coming from. dport is the port on the destination the packet is going to.

From 'man iptables-extensions':

tcp
These extensions can be used if `--protocol tcp' is specified. It provides the following options:

[!] --source-port,--sport port[ort]
Source port or port range specification. This can either be a service name or a port number. An inclusive range can also be specified, using the format first:last. If the
first port is omitted, "0" is assumed; if the last is omitted, "65535" is assumed. The flag --sport is a convenient alias for this option.

[!] --destination-port,--dport port[ort]
Destination port or port range specification. The flag --dport is a convenient alias for this option.

Originally Posted by elcore ... is that correct?

Nope. You're misunderstanding and/or missing the point so much, that I don't know where to begin. There's countless articles on PMTU Discovery on the Internet. And also e.g. rate-limiting using iptables, rather than "opening the floodgates".

Originally Posted by brebs Nope. You're misunderstanding and/or missing the point so much, that I don't know where to begin. There's countless articles on PMTU Discovery on the Internet. And also e.g. rate-limiting using iptables, rather than "opening the floodgates".

So now it's my duty and responsibility to accept and rate limit unsolicited icmp packets, rather than drop them like I have been doing for years?
Apparently, your point is that vendors who want to save CPU cycles on their gear, should be able to offload fragmentation process to my gear.
Forget about it man, it's not going to happen on my LAN. Maybe you think it should, but it won't.