First of all, all credits go to @YukiteruAmano, because this post is based on the tutorial you posted on the forum. The difference is that I am going to focus on Arch, although it will probably work for other distros based on systemd.
What is Firehol?
firehol, is a small application that helps us to manage the firewall integrated into the kernel and its tool iptables. Firehol, lacks a graphical interface, all configuration must be done through text files, but despite this, the configuration is still simple for novice users, or powerful for those looking for advanced options. All that Firehol does, is simplify the creation of iptables rules as much as possible and enable a good firewall for our system.
Installation and configuration
Firehol is not in the official Arch repositories, so we will refer to AUR.
yaourt -S firehol
Then we go to the configuration file.
sudo nano /etc/firehol/firehol.conf
And we add the rules there, you can use these.
Keep activating Firehol for each startup. Pretty simple with systemd.
sudo systemctl enable firehol
We started Firehol.
sudo systemctl start firehol
Finally we verify that the iptables rules have been created and loaded correctly.
sudo iptables -L
Disable IPv6
As firehol does not handle ip6tables and since most of our connections do not have support for IPv6, my recommendation is to disable it.
En Arch we add ipv6.disable = 1 to the kernel line in the / etc / default / grub file
...
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="rw ipv6.disable=1"
GRUB_CMDLINE_LINUX=""
...
Now we regenerate the grub.cfg:
sudo grub-mkconfig -o /boot/grub/grub.cfg
En Debian enough with:
sudo echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf
I do not understand. Do you follow the tutorial and you already have the Firewall running and all connections blocked? Another thing A tutorial for Arch is complex, for example I have never used sudo or yaourt Firewall. However it is Understood. Or maybe someone new writes yaourt and will get an error. For Manjaro it is more correct.
As you say @felipe, following the tutorial and putting in the /etc/firehol/firehol.conf file the rules given by @cookie in the paste, you will already have a simple firewall to protect the system at a basic level. This configuration works for any distro where you can put Firehol, with the peculiarity of each distro it handles its services in different ways (Debian through sysvinit, Arch with systemd) and as for the installation, everyone knows what they have, in Arch you must use the AUR and yaourt repos, in Debian the official ones are enough for you, and so in many others, you just have to search a little in the repositories and adapt the installation command.
I think Yukiteru has already clarified your doubts.
Now, about sudo and yaourt, for my part I don't consider sudo a problem, you just have to see that it comes by default when you install Arch's base system; and yaourt is optional, you can download the tarball, unzip it and install with makepkg -si.
thanks, I take note.
Something that I forgot to add to the post, but I can't edit it.
https://www.grc.com/x/ne.dll?bh0bkyd2
On that site you can test your firewall 😉 (thanks again to Yukiteru).
I ran those tests on my Xubuntu and everything came out perfect! What a delight to use Linux !!! 😀
All that is very good ... but the most important thing is missing; You have to explain how the rules are created !!, what they mean, how to create new ones ... If that is not explained, what you put is of little use: - /
Creating new rules is simple, the firehol documentation is clear and very precise in terms of creating custom rules, so reading a bit will make it easy for you to customize it and adapt it to your needs.
I think that the initial reason for the @cookie post like mine in the forum, was to give users and readers a tool that allows them to give their computers a little more security, all at a basic level. The rest is left adrift for you to adapt to your needs.
If you read the link to the Yukiteru tutorial, you will realize that the intention is to publicize the application and the configuration of a basic firewall. I clarified that my post was only a copy focused on Arch.
And this is 'for humans'? o_O
Try Gufw on Arch: https://aur.archlinux.org/packages/gufw/ >> Click on Status. Or ufw if you prefer terminal: sudo ufw enable
You are already protected if you are a normal user. That is 'for humans' 🙂
Firehol really is a Front-End for IPTables and if we compare it to the latter, it is quite human 😀
I consider ufw (Gufw is just an interface of it) as a bad option in terms of security. Reason: for more security rules that I wrote in ufw, I could not avoid that in the tests of my firewall both via the Web and those I carried out using nmap, services such as avahi-daemon and exim4 would appear open, and only a "stealth" attack was enough to know the smallest characteristics of my system, kernel and services that it ran, something that has not happened to me using firehol or arno's firewall.
Well, I don't know about you, but as I wrote above, I use Xubuntu and my firewall goes with GUFW and I passed ALL the tests of the link that the author put without problems. All stealth. Nothing open. So, in my experience ufw (and therefore gufw) I do wonderfully. I am not critical of using other firewall control modes but gufw works flawlessly and gives great security results.
If you have any tests that you think can throw vulnerabilities in my system, tell me what they are and I will gladly run them here and let you know the results.
Below I comment something on the subject of ufw, where I say that the error I saw in 2008, using Ubuntu 8.04 Hardy Heron. What have they already corrected? The most likely thing is that it is so, so there is no reason to worry, but even so, that does not mean that the bug was there and I could evidence it, although it was not a bad thing to die, I only stopped the demons avahi-daemon and exim4, and problem already solved. The weirdest thing of all is that only those two processes had the problem.
I mentioned the fact as a personal anecdote, and I gave the same opinion when I said: "I consider ..."
regards
+1
@Yukiteru: Did you try from your own computer? If you are looking from your PC, it is normal that you can access the X service port, since the traffic that is blocked is that of the network, not localhost:
http://www.ubuntu-es.org/node/140650#.UgJZ3cUyYZg
https://answers.launchpad.net/gui-ufw/+question/194272
If not, please report a bug 🙂
a greeting
From another computer using a Lan network in the case of nmap, and via the Web using this page https://www.grc.com/x/ne.dll?bh0bkyd2Using the custom ports option, they both agreed that avahi and exim4 were listening from the net even though ufw had their blocking configured.
I solved that little detail of avahi-daemon and exim4 by simply disabling the services and that's it ... I didn't report a bug at the time, and I don't think it makes sense to do it now, because that was back in 2008, using Hardy.
2008 was 5 years ago; from Hardy Heron to Raring Ringtail there are 10 * buntus. That same test on my Xubuntu, made yesterday and repeated today (August 2013) gives perfect in everything. And I only use UFW.
I repeat: Do you have any additional tests to perform? I do it with pleasure and report what comes out of this side.
Do a SYN and IDLE scan of your PC using nmap, that will give you an idea of how secure your system is.
The nmap man has more than 3000 lines. If you give me the commands to execute with pleasure, I will do it and I will report the result.
Hmm, I didn't know about the 3000 man pages for nmap. but zenmap is a help to do what I tell you, it is a graphical front-end for nmap, but still the option for SYN scan with nmap is -sS, while the option for idle scan is -sI, but the exact command I will be.
Do the scan from another machine pointing to the ip of your machine with ubuntu, do not do it from your own pc, because that is not how it works.
LOL!! My mistake about 3000 pages, when they were lines 😛
I don't know but I think that a GUI for that in GNU / Linux to manage the firewall would be somewhat prudent and not leave everything uncovered as in ubuntu or everything covered as in fedora, you should be good xD, or something to configure the damn killer alternatives xD hjahjahjaja It has little that I fight with them and the open jdk but in the end you also have to keep the principle of kiss
Thanks to all the stumbles that happened in the past with iptables, today I can understand niverl raw, that is, speak directly to him as it comes from the factory.
And it is not something that complicated, it is very easy to learn.
If the author of the post allows me, I will post an excerpt of the firewall script I currently use.
## Rules cleaning
iptables-F
iptables-X
iptables -Z
iptables -t nat -F
## Set default policy: DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Operate on localhost without limitations
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow the machine to go to the web
iptables -A INPUT -p tcp -m tcp –sport 80 -m conntrack –ctstate RELATED, ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp –dport 80 -j ACCEPT
# Already also to secure websites
iptables -A INPUT -p tcp -m tcp –sport 443 -m conntrack –ctstate RELATED, ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp –dport 443 -j ACCEPT
# Allow ping from the inside out
iptables -A OUTPUT -p icmp –icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp –icmp-type echo-reply -j ACCEPT
# Protection for SSH
#iptables -I INPUT -p tcp –dport 22 -m conntrack –ctstate NEW -m limit –limit 30 / minute –limit-burst 5 -m comment –comment "SSH-kick" -j ACCEPT
#iptables -A INPUT -p tcp -m tcp –dport 22 -j LOG –log-prefix "SSH ACCESS ATTEMPT:" –log-level 4
#iptables -A INPUT -p tcp -m tcp –dport 22 -j DROP
# Rules for amule to allow outgoing and incoming connections on the port
iptables -A INPUT -p tcp -m tcp –dport 16420 -m conntrack –ctstate NEW -m comment –comment "aMule" -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp –sport 16420 -m conntrack –ctstate RELATED, ESTABLISHED -m comment –comment "aMule" -j ACCEPT
iptables -A INPUT -p udp –dport 9995 -m comment –comment "aMule" -j ACCEPT
iptables -A OUTPUT -p udp –sport 9995 -j ACCEPT
iptables -A INPUT -p udp –dport 16423 -j ACCEPT
iptables -A OUTPUT -p udp –sport 16423 -j ACCEPT
Now a little explanation. As you can see, there are the rules with the DROP policy by default, nothing leaves and enters the team without you telling them.
Then, the basics are passed, the localhost and the navigation to the network of networks.
You can see that there are also rules for ssh and amule. If they look well how they are done, they can make the other rules they want.
The trick is to see the structure of the rules and apply to a specific type of port or protocol, be it udp or tcp.
I hope you can understand this that I just posted here.
You should make a post explaining it 😉 would be great.
I have a question. In case you want to reject http and https connections I put:
server "http https" drop?
And so on with any service?
Thank you