Yes, Linux is secure, and we all know that. But we shouldn't stop talking about it's default Firewall, Netfilter, and how to properly configure it. By default, Netfilter and it's front-end Iptables are configured in such way that they accept all incoming/out-going connections. For me this is ridiculous because all it takes is one vulnerable service and "BOOM", there goes the security of your system. Having this in mind I always configured my Iptables in the safest way possible and in the shortest time possible. One day I stumbled upon GUFW, a tool with a GUI designed to easily configure your Linux firewall. Cool huh? Not so much, at least not for me. I tend to not use something if I don't have studies showing the efficiency of this something, and if you look into GUFW's generated rules you'll see that they're very basic in their construction. Considering I'm crazy (proper medical diagnosis) I decided to study Iptables in a deeper manner so that I would be able to configure it the way I wanted. I decided to create a safe setup while at the same time making it possible for any human being to read it. It works, it's safe, and all you need to do is copy/paste the rules I'm going to describe (with your desired changes). Simple, right? Hands-on I'll start explaining that it's possible to create "rule groups" in iptables, so that it's easier to join a set of wanted rules together. Example: I can create a rule group named "invalid" and point as many rules as I want there, and this group can have one single command at the end (like DROP or ACCEPT). This makes Logging easier too. Here's an example: Code: # anti-spoof iptables -N In_RULE_0 iptables -A INPUT -i enp3s0 -s amarildo -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 The first line is commented out (with a hash-tag), which means it won't be executed. This makes reading the rules' names easier without having to read the entire code. I gave this rule group the name "In_RULE_0" but you can name it anything you want. The second line creates a general group called "In_RULE_0". I can now create rules that will, at the end, fall into this desired group, including the logs (continue reading if you didn't understand). The third line specifies that everything coming from my LAN card (enp3s0) in direction to my hostname (amarildo) will fall into In_RULE_0. (PS: change 'enp3s0' to your network card name, and change 'amarildo' to your hostname (cat /etc/hostname). The fourth line says that everything related to In_RULE_0 will be logged. It also informs the Logging level. The last line specifies that every sub-rule created above in this In_RULE_0 group will have a "DROP" effect, which means the Firewall will silently drop those packets without telling the packet sender. Easy, right? Now let's do some work. 1st Rule: Deny everything, and open only the necessary ports The key ingredient to every secure Firewall is to DROP everything, closing all doors, and then open only what the machine needs. This is the safe way to go, contrary to letting it all open and then closing what you don't need. This last setup is insecure, not to mention it requires way too much thinking and time. DON'T DO IT. So now let's block everything: Code: iptables -P OUTPUT DROP iptables -P INPUT DROP iptables -P FORWARD DROP Blocking several network attacks Let's now deny all connections that were open prior to the Firewall start: Code: 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 We now DROP everything that has an "invalid" state, and we'll log those connection attempts too: Code: 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 Anti-Spoof rule. Logged. Code: iptables -N In_RULE_0 iptables -A INPUT -i enp3s0 -s amarildo -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 I also block every ICMP inbound connection, so that nobody can "ping" me. All attempts to do so are also logged: Code: 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 Also, no Whois is allowed. All attempts to do so are also logged: Code: 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 Anti xmas-scan rule, logging Code: 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 If anything escapes the above rule, then DROP *all* xmas-scan stuff, and log: Code: 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 Block and log IP-Fragments Code: 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 Block and Log "Who" attempts: Code: 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 Block and Log tracerout: Code: 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 Now that we blocked some of the most common attacks we can open what we need for incoming rules. The first step is to accept all ESTABLISHED and RELATED traffic. The first type, ESTABLISHED, is the kind of traffic that we establish, like when we open a web browser. The second type, RELATED, is everything related to the first type. Code: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Yes, I know, "-m state" is deprecated, but it works! If you think your loopback needs traffic: Code: iptables -A INPUT -i lo -m state --state NEW -j ACCEPT (we won't open outbound lo traffic yet) Now we open the outbound connections Let's now open the exit traffic. Before we open the ports we need, we need to make sure we don't pass out invalid traffic to other people: Code: iptables -A OUTPUT -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state --state NEW -j DROP PS: Once a rule is dealt by the "NEW" category it falls into the "ESTABLISHED,RELATED" category. Opening ESTABLISHED and RELATED outbound traffic: Code: iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT We now open the loopback outbound connections: Code: iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT EDIT (12/2/201: Unreal Engine requires users to allow multicast on loopback in order to build Lightmass. IN/OUT won't be enough so we need FORWARD lo allowed as well: Code: iptables -A FORWARD -o lo -j ACCEPT DNS: Code: iptables -A OUTPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT iptables -A OUTPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT (PS: port 53 UDP might be enough) FTP: Code: iptables -A OUTPUT -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT http: Code: iptables -A OUTPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT https: Code: iptables -A OUTPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT IMAP: Code: iptables -A OUTPUT -p tcp -m tcp --dport 143 -m state --state NEW -j ACCEPT POP3: Code: iptables -A OUTPUT -p tcp -m tcp --dport 110 -m state --state NEW -j ACCEPT Printer (change accordingly): Code: iptables -A OUTPUT -p tcp -m tcp --dport 515 -m state --state NEW -j ACCEPT SMTP: Code: iptables -A OUTPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT SMTPS: Code: iptables -A OUTPUT -p tcp -m tcp --dport 465 -m state --state NEW -j ACCEPT OpenVPN: Code: iptables -A OUTPUT -p udp -m udp --dport 1194 -m state --state NEW -j ACCEPT KPasswd: Code: iptables -A OUTPUT -p udp -m udp --dport 464 -m state --state NEW -j ACCEPT KMail: Code: iptables -A OUTPUT -p tcp -m tcp --dport 993 -m state --state NEW -j ACCEPT Git: Code: iptables -A OUTPUT -p tcp -m tcp --dport 9418 -m state --state NEW -j ACCEPT OpenPGP: Code: iptables -A OUTPUT -p tcp -m tcp --dport 11371 -m state --state NEW -j ACCEPT Steam (if you're gaming on Linux) Code: # Steam iptables -A OUTPUT -p udp -m multiport --dports 27000:27015 -j ACCEPT iptables -A OUTPUT -p udp -m multiport --dports 27015:27030 -j ACCEPT iptables -A OUTPUT -p tcp -m multiport --dports 27014:27050 -j ACCEPT iptables -A OUTPUT -p udp --dport 1200 -j ACCEPT iptables -A OUTPUT -p udp --dport 3478 -j ACCEPT iptables -A OUTPUT -p udp --dport 4379 -j ACCEPT iptables -A OUTPUT -p udp --dport 4380 -j ACCEPT ------------ FlightGear is a GPL Flight Simulator that uses TerraSync to download Scenery as we flight over the world. By default you won't be able to download scenery, so just go to the following website and change your TerraSync port according to what the server is using that day/week/month. Currently it's 8888: http://scenery.flightgear.org/svn-server Code: # FlightGear iptables -A OUTPUT -p tcp -m tcp --dport 8888 -m state --state NEW -j ACCEPT GnuPG Code: # GPG iptables -A OUTPUT -p tcp -m tcp --dport 11371 -m state --state NEW -j ACCEPT Now we deny and Log everything that doesn't fall into the categories above: Code: 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 Denying all TPC traffic: Code: 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 Any other attempts to connect to the Firewall well be denied and Logged: Code: iptables -N RULE_23 iptables -A OUTPUT -d amarildo -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 I'll upload a tar.gz file with a .txt file containing all rules above. Wait for an update. EDIT: You can download a "Master" file from my Github repository. Please refer to my signature bellow. EDIT (Aug.7): Added rule for Counter Strike: Global Offensive, multiplayer. EDIT (Sept. 26th): Added rules for OpenPGP and Git. General organization done. EDIT (Dec 2, 201: Added a rule that allows Unreal Engine to build lightmass.
It could go there, no problem To all: Can any Linux gamer confirm that the Steam rules work while searching for Multiplayer games? (Menu Play -> Find a Game -> Competitive/DeathMatch/Casual) ? Sometimes I'm faced with an error "Could not connect to match" or something.
Great tutorial... I am thinking about creating a little platform/database where people can add rules for specific applications/services so that other people can easily "create" their iptables according to their needs by just selecting those apps/services and pasting the created rules. Or would one big rule list/file be a good start as well? Just need someone who will look over all the rules and confirms its security and that they are written correctly.
Why? To answer your question: no. I think that really depends on the environment. For a home user locking down the INPUT chain wth numerous rules for protection should be enough, considering the user knows enough not to be infected, for exampl, so that he/she doesn't pass "bad" packets over their network. In all cases I would recomend these INPUT rules for any environment, because they work and won't cause any problems at all. They're mostly for protection. Obviously once we start considering a Server we will have to open more ports like SSH, but that is really up to the admin to manage. These rules, IMO, are a good starting point to some who is learning how iptables work. However, if the user is REALLY a novice he can start by managing GUFW, a Graphical User Interface for UFW (uncomplicated firewall). But since UFW enables a whole bunch of stuff like ICMP, and don't protect the user from a wide range of attacks/scans, I edited the default "before-input" rules so that they match all my stuff here. You're all invited to download them from my Github page https://github.com/amarildojr/Firewall The main files from the "Firewall-master" branch are: * UFW - before.rules * before6.rules The file "before6.rules" is the modified UFW rules for IPv6. It's basically blocking everything IPv6.
Because it's very easy You just install: Code: $ sudo apt-get update $ sudo apt-get -y install iptables-persistent It writes /etc/iptables/rules.v4 and /etc/iptables/rules.v6, and loads then at bootup. After editing the rules, you reload: Code: $ sudo iptables-persistent < /etc/iptables/rules.v4 $ sudo iptables-persistent < /etc/iptables/rules.v6
Very good tutorial and all, but I find IPtables too much like "Greek" in trying to read and understand them. All I did, while probably not the best or most efficient, but it was at least comfortable for me to administer, was: -Install UFW - very lightweight command line interface -set it to deny both incoming and outgoing connection attempts -set my rules using its very easy to understand syntax (eg: $ sudo ufw allow out proto tcp from any to any port 80,443) -Ensure the service loads at boot: -Done My rules are attached. There are some rules I don't really need, but I threw them in there because they reduce logging and are not security concerns. I sit behind a hardware router/firewall as well.
You have to enable outbound connection for port 11371. 11371 is the official port for OpenPGP HTTP key server.
Well, this is just a "starter" guide so that people know more about iptables I can't build a firewall that will work on every computer hehehehe. But I personally never had problems with these rules, not even while using AUR. What exactly did pacman try to do? Thanks. Added to the rules. Also added a rule for Git.
Opening this port is required for exporting/importing public keys to/from keyservers. When adding an unofficial repo, you need to import the corresponding public key of that repo and locally sign it for pacman to install the packages from that repo.
One thing I am missing: Cant I make app specific rules? E.g. allow iceweasel http ports but not other apps?
As far as I know, no. But you can make rules for specific users, and run an app as its own user. For example, tor by default runs in Debian etc as user debian-tor. The user ID varies. You find it by running this ... Code: id -u debian-tor Then, in a rule, you write this ... Code: -m owner --uid-owner [uid]
Meh...this is another minus point. Why would I open ports or allow IPs for the whole system? On windows I would allow each app only the desired ports/connections for the individual app. E.g. why would I allow KeePass do allow all ling of pors and IPs when all it needs it the one port & IP to check for updates? This + the lack of AUR security on Arch + no real av/anti malware solution is making linux a lot less secure than I thought so far.
You're still "thinking Windows". First of all, there are no open ports in Arch Linux by default. Controlling outbound connections is a completely different thing. And while this might be necessary for untrusted 3rd party Windows applications, it's normally not necessary for trusted Linux applications from the official repositories. There are enough paranoid Linux users who check with, e.g, Wireshark what their applications are doing. If, e.g., Keepass would be found guilty of spying out its users it would be immediately removed from the repos and its author would be discredited for evermore. Having said that, it is possible to implement an application-specific network control with AppArmor. I don't know about other MAC sytems. Oh c'mon! Nobody forces you to use packages from the AUR. Besides, it's your decision to chose Arch. If you didn't inform yourself beforehand that the AUR contains unsupported packages, it's your own fault. If you don't accept that I suggest that you move to Debian. Sigh. We've discussed this ad nauseam. I still don't understand why you so desperately need an AV that detects only Windows malware anyhow.
@summerheat, don't even try to be rational with zakazak, he won't learn no matter how logical and what proof you provide. I though his windowsy mentality wouldn't affect my thread. Too bad I was wrong. This doesn't belong to this thread, but I'll say it anyway. AUR is not a repo where you get binary packages, everyone can check the PKGBUILD to see if there's anything wrong with it, and I guarantee you that if anything malicious was posted there it would be removed in a second because our community doesn't accept this kind of behavior. And as summerheat said, almost all packages on Arch are open-source and anyone can check the source code to see what they do, and there are paranoid people checking what each package does. Obviously there are proprietary packages in Linux, and it is YOUR responsibility to trust and install them if you so desire. Arch is a very democratic distro, you only install things you want. But then again, it's easy to verify what the package is doing over the network, much like it's easy to see what Windows is doing on your connection. I never saw a Linux package that was malicious and didn't get removed from the repositories. In fact, I never saw a malicious Linux package from a reputable source.
No open ports by default? So far everything was able to open incoming/outgoing connections without any problem. Wine, browsers, irc, stuff from official repo, libre repo, AUR..... not a single meh by linux. I agree with you that linux users tend to pay more attention about what an app does, but what happens if a malware takes over my KeePass and is then using it to send stuff? Or if an exploit affects KeePass which then makes KeePass do weird stuff? All that wouldn't be noticed by the community because KeePass out-of-the-box works as it should be. But malware modifies it. On windows that wouldn't even be a problem because my Windows-KeePass only is able to do one single connection: update-server-ip + port. Rest is blocked. I will look into AppArmor once I feel condifent enough to take it on Thanks for the suggestion ! Not using packages outside of the AUR? Seriously? Then the system wouldn't be usable as a working environment.. or even as any environment that goes beyond the usage of notepad and calculator. But yes, it is my decision and so far I can live with it. It is just another security problem that I am pointing out. I dont want an AV that dedects windows malware only. Linux needs a real anti-malware solution. So that stuff like AUR can be installed without having to worry or breaking my head about the source code. Yes I can check the PKBUILD and the .install scripts, yes it will offer me some sort of protection but is still far from bulletproof or to be even called "secure". On would need to check the source code for every package, for every update.. and do you seriously go through the complete source code of touchegg ? For every update? And I doubt that there is one single user out there who does it, and even then, he could and probably would still miss malicious code. @amarildojr yes I could check what an app does via the network.. but then its already too late. It's like "oh look it just sent away my personal information & passwords... whoopsie too late". Anyway, I am sorry about where this thread is going. I was just ~ Snipped as per TOS ~ about another negative point and pointed it out by writing it here. That doesn't mean arch & linux don't have any positive points. Eventhough I am struggling with problems and finding negative points, I still like it and so far think I will prefer it over windows one day.
You don't know what open ports are to iptables. By default iptables is "stateless", meaning it will allow everything that YOU do regarding ESTABLISHED and RELATED connections (read above). No outside connection attempt is allowed, all ports are closed to this kind of connection, but obviously anything YOU make that requires an OUTPUT connection will be allowed by iptables. And if Firefox needs an incoming connection on https port 443 than this port will NOT be opened. Contrary to Windows that has at least 4 open ports listening to incoming connections. You still have this nonsense mindset of "what if's" and this will take you nowhere. We've been through this, many times. Do you have some sort of learning disability? Or a mental condition? I don't ask this in a pejorative way, I just want to learn why you're so stubborn. If you subscribed to the Debian Security Mailing List you'd know that they have a security team dedicated only to finding, reporting, and fixing these kind of bugs. And it's not only Debian that does that. It's much easier to the white-hat community to find exploits and fix them than it is to a few individuals (blackhats) trying to find exploits by themselves. It's not a security problem, it's YOUR problem. As many pointed out here, you're wrong, and there's nothing we can do to change that, you'll keep thinking you're right and you won't even make a small effort to try and view things outside of your horse-perspective. What exactly do you mean by "Arch is not usable beying notepad and calculator if I don't use AUR"? No, you don't need an antimalware to verify AUR packages. You know why? Because they are only a bunch of scripts that fetch software from their sources. If a PKGBUILD doesn't do that then it would have been reported already, because many users are actually smart (contrary to some people) and read the pkgbuilds. Remember: there are Trusted Users watching over this stuff on the AUR and most AUR users will read the PKGBUILDS and verify things themselves . And no antimalware company would be keeping an eye on AUR just because you think it's not safe, Linux has only 1% of the desktop market share, you wouldn't be protected by them in the vast majority of cases (which are, at thins point, zero). Like I said, they KNOW Linux don't need this, because it's stupid. They would only be making money out of naive an uneducated people. There's nothing an antimalware company can do that a community won't do for itself. And you can go on and on repeating the same stuff all over, the facts will remain at the right side of the community. Here is a perfect example of how ignorant a Linux user can get. No matter the facts, logic, or anything: he will still be tied to his ignorance and try to "dumb" people down to this mind set. And the worse part is, some people will actually believe him. And you'd think that he would learn anything after that many people trying to teach him, but you'd be wrong. To anyone reading zakazak's posts: Just go over this thread and you'll see for yourselves what really experienced Linux users will have to say about this kind of mindset. If questions arise, please create threads and we'll be happy to go over your questions. No, you lazy kid, it wouldn't be too late because there is a SOURCE-CODE available and distro developers TEST THINGS BEFORE THEY MAKE THEM AVAILABLE. Unless there is no source-code availabe, in this case it's nobody's fault except yours for installing the proprietary software. Remember: this is not a fully-fledged tutorial. You can configure iptables to lock everything down and then allow connections only to specific IP's and protocols, but since it's not necessary and requires a lot more thinking, I didn't make such tutorial.
Its like trying to put a burger into a cd player... I am reading your post and want to answer but then I realize I would just post the same thing again and again. And is kind of boring but I will make it quick: If password-stealer-file want to send smth out (e.g. passwords) then it will be able to. Just like firefox and everything else can connect to the outside. If the debian-security-team or any developer or any arch user are so awesome then why are there endless exploits available, yes also on linux? There are companies that get paid unbeliavable amounts of money to secure a program, to make it impossible to exploit, and they regulary fail. A punch of semi-active-hobby-scriptors wont top that. You realize that a server containing the source u downlosd through pkbuild could be taken over, source modified, hello infection? I dont even know what to write anymore because I am just repeating myself over and over again. And your answers are always...well..you could be a good politician As I said many times, either you only believe what you want to believe or you simply dont know what hackers/blackhat/exploits/malware are possible to.
