Hi!
For some home projects I use freedns.afraid.org to get free DNS, but now I see freedns.afraid.org [69.42.215.252] get get this is firewall logs when I try to login:
| DROP_HOSTILE| green0 | TCP | 69.42.215.252
Can I whitelist the IP somehow?
Hi!
For some home projects I use freedns.afraid.org to get free DNS, but now I see freedns.afraid.org [69.42.215.252] get get this is firewall logs when I try to login:
| DROP_HOSTILE| green0 | TCP | 69.42.215.252
Can I whitelist the IP somehow?
This issue has already been raised in an earlier thread.
https://community.ipfire.org/t/block-of-69-42-215-252-freedns-afraid/11272
In post 12 it explains the problem and also in the bug that was CLOSED as CANTFIX
https://bugzilla.ipfire.org/show_bug.cgi?id=13628
Unfortunately freedns.afraid.org is being hosted on a provider that also hosts lots of bad actors.
You can’t whitelist it in DROP_HOSTILE and even if you could the Spamhaus drop list that is used for DROP_HOSTILE is also used by more and more ISP’s and other sites/organisations so you would probably find difficulty when you tried to resolve any dynamic name you get from freedns.afraid.org
I ran into the same issue and did the script below based on Carlo’s post in the other thread. And I wrote a note to Josh at freedns.afraid.org.
I have not heard back yet. I suggest letting Josh know you are experiencing this issue. The more people that let him know the better!! The contact info is available on freedns.afraid.org.
Here is the script:
#!/bin/sh
# Used for private firewall rules
# Read variables for Firewall Options (optionsfw.cgi) settings
eval $(/usr/local/bin/readhash /var/ipfire/optionsfw/settings)
#set -x
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
if [[ "${DROPHOSTILE}" == on ]]; then
if ! iptables --check HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --insert HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
# iptables --verbose --insert HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSd "
fi
if ! iptables --check HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --insert HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
# iptables --verbose --insert HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSs "
fi
fi
;;
stop)
## add your 'stop' rules here
if iptables --check HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
# iptables --verbose --delete HOSTILE_DROP -p tcp -d 69.42.215.252 --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSd "
fi
if iptables --check HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
# iptables --verbose --delete HOSTILE_DROP -p tcp -s 69.42.215.252 --sport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSs "
fi
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
@jon,
so can I put this script in iptables?
Is it the “improvement” of what I wrote in the other post?
using the /etc/sysconfig/firewall.local
script is the way to add things to iptables.
also see:
I think it is similar - It is up to you if it is an improvement!
FYI - this is not a permanent fix! Either Josh needs to change things on his side (write him a note!) or you and I and @raffe need to change DYNDNS vendors
Yes, I think both are fine in the end. This one seems to me that it gives the possibility to operate with a log as well. I can try it out.
The only thing I notice is that if you are using the latest IPFire update, the chains should be:
HOSTILE_DROP_OUT
HOSTILE_DROP_IN
For older versions of IPFire, ONLY the chains in this script should be used.
That’s right!!!
Thanks for all info!
So the script in “/etc/sysconfig/firewall.local” with latest Core-Update 185 using HOSTILE_DROP_OUT and HOSTILE_DROP_IN should be something like this?
(not home, so can not test yet)
#!/bin/sh
# Used for private firewall rules
# Read variables for Firewall Options (optionsfw.cgi) settings
eval $(/usr/local/bin/readhash /var/ipfire/optionsfw/settings)
#set -x
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
if [[ "${DROPHOSTILE}" == on ]]; then
if ! iptables --check HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --insert HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
iptables --verbose --insert HOSTILE_DROP_IN -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
fi
if ! iptables --check HOSTILE_DROP_OUT -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --insert HOSTILE_DROP_OUT -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
iptables --verbose --insert HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
fi
fi
;;
stop)
## add your 'stop' rules here
if iptables --check HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
iptables --verbose --delete HOSTILE_DROP_IN -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
fi
if iptables --check HOSTILE_DROP_OUT -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP_OUT -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
iptables --verbose --delete HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
fi
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
Will write a note to Josh
Not exactly. I’m sending you my newly tested configuration (which I simplified a bit). I have the latest version of IPFire installed…
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
## Catene "afraid"
if ! iptables --check HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --insert HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
iptables --verbose --insert HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSd "
fi
if ! iptables --check HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --insert HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
iptables --verbose --insert HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSs "
fi
## Catene "afraid"
;;
stop)
## add your 'stop' rules here
## Catene "afraid"
if iptables --check HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
iptables --verbose --delete HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSd "
fi
if iptables --check HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
iptables --verbose --delete HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSs "
fi
## Catene "afraid"
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
My version that you find in the other topic can also go, but this one “handles” it better, with LOG and more!!!
You can adapt this simplified script with @jon’s or modify it to your liking. The important thing is to respect the name of the chains and the order of the rules.
For versions of IPFire before CU184, “HOSTILE_DROP” chains apply.
I will try to explain the lines VERY briefly:
if ! iptables --check HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
Check if the rule exists. If it does NOT exist, these rules are added:
iptables --verbose --insert HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
This rule opens outgoing traffic to port 443 of IP 69.42.215.252 and is the ESSENTIAL rule.
iptables --verbose --insert HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSd "
This rule is “of less importance.” It “handles” logs and more, always OUTPUT to port 443 of IP 69.42.215.252.
if ! iptables --check HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --insert HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
iptables --verbose --insert HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSs "
fi
This second “block” does the same thing as the first “block.” Only it opens the INPUT traffic that comes from port 443 of IP 69.42.215.252
if iptables --check HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -j ACCEPT
iptables --verbose --delete HOSTILE_DROP_OUT -p tcp -d 69.42.215.252 --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSd "
fi
if iptables --check HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT >/dev/null 2>&1 ; then
iptables --verbose --delete HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -j ACCEPT
iptables --verbose --delete HOSTILE_DROP_IN -p tcp -s 69.42.215.252 --sport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "HOSTILE_BYPASSs "
fi
If from the terminal you type:
/etc/sysconfig/firewall.local stop
These lines check and remove (if they exist) previously entered rules.
-------------------------------
All rules mentioned, apply to chains
HOSTILE_DROP_IN
HOSTILE_DROP_OUT
In older versions of IPFire, both chains are grouped into the single chain
HOSTILE_DROP
-------------------------------