Peace love and kindness:
Hello awesome people of IPfire my name is Salam and wish you all Happy new year to all of you and your families.
I have got question:
I have bash script in my IPfire firewall named “block_IT_empires.sh”. it make use of ipset to create block list named ‘blockITempires’ and then populate it with IPv4 addresses and then it reload ‘firewall.local’ file for some reason. !!!
but recently an electricity cut in my living place resulted in severe damage to IPfire OS. downloaded “ipfire-2.27-core170-aarch64.img.xz” file from the official website. extracted the ipfire-2.27-core170-aarch64.img and burn it to SD card then connected it to Raspberry PI 3. then did the usual TWO interface network configuration - RED and GREEN - and now everything works in perfect order. but the aforementioned script does not.
The script does successfully the following:
A- Create list named “blockITempires” using “ipset” program.
B- Populate the list with MASSIVE MASSIVE number of IPv4 addresses of technology EMPIRE such as: Microsoft , Apple , Facebook , MANY cdn (which is short for Content Delivery Network) IPv4 ranges , SolarWinds , AND MANY MANY MANY other companies or as i prefer to call them… EMPIRES.
C- The script reload the firewall.local with following command: /etc/sysconfig/firewall.local reload.
however it does NOT block those IPs. why is that ! I am remember perfectly good that i had to modify the /etc/sysconfig/firewall.local but i have forgotten what I added to it.
Could any kind and sweet soul here help me figure out what i should add to “firewall.local” file to make the ipset’s “blockITempires” list effective ?
Core Update 170 is no longer available from the official IPFire website.
EDIT:
It would also be easier if you just pasted the contets of your script into a forum post rather than making a link to a pastebin which might stop working after some time and where users might not feel secure to just click the link.
What are the firewall rules using this ipset set? Your script is just creating an ipset set and not the associated firewall rules.
I have a number of issues/observations with your script.
I suggest with just about any ipset command you use the -exist switch. This stops you getting errors if you run the script again.
I don’t know how you do your firewall.local, but entries will fail if the ipset set does not exist. I suggest you do an ipset create just prior to your iptables firewall rules.
I also suggest you load your rules into a set like blockITempires_temp, then when your script finishes, instead of ending it with a firewall reload, you can finish it with an:
To cope with a reboot, save your ipset to a temp file e.g:
ipset save blockITempires > /usr/src/blockITempires.save
sed -i 's/create/create -exist/g' /usr/src/blockITempires.save
sed -i 's/add/add -exist/g' /usr/src/blockITempires.save
Then on reboot you can do ipset restore < /usr/src/blockITempires.save to IPF boots up with your ipset set working…
Note that with this approach there is no need to ever reload the firewall as you can swap ipset sets live.
First of all, I am thankful for taking time to answer my question. Second of all Merry Christmas to you and your high family. wish these holidays (Christmas & New Year) bring never-ending peace and love to this world.
Now, about your question: no it is not typo. I did download and burn the older version of IPfire because… unknown reason. Ha ha ha ! I am laughing because i honestly do not know why i downloaded an older version of IPfire.
Core Update 170 is no longer available from the official IPFire website.
I am thankful for taking time to answer my question. really i am. but I would love to do it the way i used to for a year or year and half now. “what is that way, o Salam?” well, it is a bash script:
1- create list with: “ipset create blockITempires hash:net” command
2- populate it with: “ipset add blockITempires xxx.xx.xxx.xx” command
3- reload the firewall.local with: “/etc/sysconfig/firewall.local reload”
and the script used to work but now after installed brand new IPfire version 2.27 with core 170 the script stopped being effective!!! It used to block ALL IPv4 addresses in it but not any more. I AM PERFECTLY SURE the “firewall.local” was different than the one in this brand new of old version of IPfire because the current one does not have anything under “reload)” section of firewall.local but in the old IPfire (which was 2.29 with core 189) there was… some command ? or rule ? i do not remember. and i think there was word like “CUSTOMINPUT” some where in the firewall.local but not in the current one.
in shortest words… the issue i am having lay in the third step/stage of the script (which is reload the firewall.local). in the past (before format the SD card) reloading the mentioned file would ACTUALLY block all IPv4 addresses in the script.
Thanks sincerely for reading my poor English. and have a wonderful day. =D
I meant that there is no direct link to the old files.
If you manually edit the url to change the core update version to 170 and you know that the major version was 2.27 back then instead of 2.29 then yes you can access the old version but I really don’t understand why.
The latest version has all the fixes to the various security vulnerabilities that will have been found in the last two years, which is how old Core Update 170 is.
From a security point of view (which I believe is important for a firewall) I would encourage you to do a fresh install with Core Update 190.
This indicates that you used to have Core Update 189 installed and for some reason you have done a fresh install with Core Update 170, which is two years older.
If you want the same result as you used to have with Core Update 189 then I would install Core Update 190
I meant that there is no direct link to the old files.
Ohh okay. well, then you, Sir, are right. there is NO direct link to the bootable image.
then yes you can access the old version but I really don’t understand why.
I PROMISE you: I have not clue as to why I chose to download and use an older version of SECURITY PROGRAM such as IPfire firewall. Ha ha ha. I guess consuming Five (5) large cans of “SAPPORO PREMIUM” makes person a funny one. =D
From a security point of view (which I believe is important for a firewall) I would encourage you to do a fresh install with Core Update 190.
Hundred percent (100%) correct. I SHALL do that once I get enough hours of sleep. it is deep into the night where I live.
But, I am honestly thankful for your time and do forgive me for communicating with, Sir, while having smaller amount of alcohol in my system but because the issue i am having toke place immediately after i finished the very last can of the mentioned beverage. I am respectful person. God bless you and have a wonderful day. Sir: Adolf Belka.
Thank You sincerely Mister: Adolf. for your kind words and understanding. now after roughly Seven hours of sleep, woke up and washed my face and did what you Sir told me to do last night: installed brand new IPfire 2.29 core 190. and tested the script but still not working because by default, the “firewall.local” file has no entries under: “start” , “stop” , “reload”. but when the script was working there was one or two lines somewhere in the mentioned file.
Because redundancy is strongest with me not just here in the digital space but even in real/physical life, allow me to summarize:
I did downloaded IPfire 2.29 with core 190 image from the official website and burned it against my Raspberry PI 3’s SD card. and booted into IPfire did the typical TWO interfaces, RED - GREEN, and now i have fully and perfectly working IPfire 2.29 with core 190. but the script still now working as it used to.
Please allow me to add the following:
The IPfire OS is working in perfect order. there is ZERO issue with IPfire itself but the issue I am having is in the 3th step or stage of the script which reload an empty “firewall.local” at: /etc/sysconfig/ directory.
CLARIFICATION:
when i say ‘reload an empty “firewall.local”’ i mean no lines under: “start)” , “stop)” , “reload)”.
nothing. !! and by that i mean the default content. meaning there is nothing under “start)” , “stop)” , “reload)”.
however, I am PERFECTLY sure there was one or two line some where in the firewall.local file and I THINK one of the lines had CUSTOMFORWARD or maybe it was CUSTOMINPUT word in it. I swear i have forgotten what was in it. and that is why i am here to ask if somebody in the forum can figure out what was in firewall.local file. maybe some experienced user perhaps.
What you do next is really dependent on what you are trying to do. The following will protect anything you host:
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
ipset create blockITempires hash:net
iptables -I CUSTOMINPUT -m set --match-set blockITempires src -m conntrack --ctstate NEW -j DROP
iptables -I CUSTOMFORWARD -m set --match-set blockITempires src -m conntrack --ctstate NEW -j DROP
;;
stop)
## add your 'stop' rules here
iptables -F CUSTOMINPUT
iptables -F CUSTOMFORWARD
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
if you are trying to stop your LAN and IPF from contacting any of those sites, remove the -m conntrack --ctstate NEW from the rules.
If you want to protect particular services only you can add port and protocol selectors and so on.
Thank you greatly my dear. I found the solution at: https://confluence.jaytaala.com/display/TKB/Using+ipset+to+block+IP+addresses+-+firewall
what actually helped me was ‘Enabling (and deleting) the list in iptables’ part of the attached article. but with slight modification: INPUT to CUSTOMINPUT and FORWARD to CUSTOMFORWARD and of course i removed sudo at the beginning of the commands and changed the name of the blocklist.
It turn out ONLY thing i had to do was to add TWO lines under “start)” section/portion of firewall.local file located at /etc/sysconfig/ directory.
BUT
I will be the happiest to mark your comment as “Solution” if you would remove “-m conntrack --ctstate NEW” part from the commands you provided me with, generously. “Why?” because conscientiously I do not know what will those flags/switches would do to people’s computers. maybe they will create even more troubles.
Finally:
I am SUPER thankful to the couple of improvements you have suggested to me at your very first comment on this thread we are commenting on.
God Bless you and your family. and Merry Christmas and Happy New Year. wish the next Year will shower humans, all humans, with: Kindness , Softness , Love , Excellent Health , and finally… Peace.
It turn out ONLY thing i had to do was to add TWO lines under “start)” section/part/portion of “firewall.local” file and those two lines were:
1- iptables -I CUSTOMINPUT -m set --match-set blockITempires src -j DROP
2- iptables -I CUSTOMFORWARD -m set --match-set blockITempires src -j DROP
and… that it. I spent hours upon hours upon hours only to discover that the fix is… two bloody lines. TWO BLOODY LINES. bloody Linux. Ha ha ha.
Anyway… I am HONESTLY VERY THANKFUL for taking time and trying to help me. God Bless you and your family. May the new Year bring: Peace of Mind , Excellent Health , and significantly less of Linux and IPfire bugs/issues to you and to the whole world. =D
The purpose of the cstate but is to just block new incoming packets. it means that your LAN is allowed to connect to these servers to send stuff out, but those servers are not allowed to connect to you, for example to try to attack your web server if you have one.
Take, for example, the TOR network. You may want your users to be able to use the TOR network, but you do not want malicious traffic from the TOR network to hit your router. Without the cstate section, you would block traffic both to and from the TOR network.
This is where you have to customise the rules to suit your own firewall. As an example, in another firewall, I country-block OpenVPN, IMAP and STARTTLS but not SMTP because I only use OpenVPN, IMAP and STARTTLS when travelling, yet I receive emails from all sorts of places, so I have to craft very specific rules rather than your all or nothing rules which, presumably, suit your requirements.
I am GREATLY thankful for taking time writing (or in this case typing) all that to help me out understand the " -m conntrack --ctstate NEW" portion of the command. Okay. okay, now I can mark your previous comment as Solution because the two commands of yours are much better than that of the Article attached to my previous reply comment to you.
my name is Salam and wish you all Happy new year to all of you and your families.