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?
Code:
iptables -P OUTPUT 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: Code:
/ # iptables -S |
The usual order, for performance reasons (matching on the most commonly-occurring and simple-to-decide rules first) is:
Code:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT |
Quote:
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. |
Quote:
|
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. |
Quote:
Quote:
What I've also seen is icmp abuse, and generated icmp packets that are spoofed. Otherwise I wouldn't have dropped the entire protocol. |
Quote:
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. |
Quote:
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
Code:
kern.* /var/log/firewall.log 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[:port] 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[:port] Destination port or port range specification. The flag --dport is a convenient alias for this option. |
Quote:
|
Quote:
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. |
All times are GMT -5. The time now is 03:55 AM. |