After updating ipfire today, I can no longer access my own website hosted at 194.87.87.50. According to the firewall logs the traffic triggered DROP_HOSTILE. My site is hosted by Oxide Hosting (https://oxide.host/) and from what I can tell, they also own the IP: 194.87.87.50 Ip Address - 194.87.87.50 in Czech Republic
None of my customers have difficulty accessing the site, and I can access it via my smartphone on cellular (not using IPFire).
Is it possible this address has been falsely flagged somehow?
I specifically want to keep this IP address as it’s registered as my company’s static IP with third parties, and it would be awkward and disruptive to change this.
Are you sure that your IP is actually being listed with DROP_HOSTILE in the logs.
I have Drop Hostile enabled on my system but I can access the IP without any problems.
I checked the ASN for that IP and the name Oxide and neither are in the Spamhaus json Drop list which is used in IPFire.
If it was in the Drop Hostile list I would expect to be prevented from accessing it. That definitely happens with other IP’s that I test that are covered by the Spamhaus Drop list.
I was able to access your website without any issue. It did not get flagged as DROP_HOSTILE, whereas other IP’s that are covered by the Spamhaus Drop list were blocked from being accessed
There was also no change in the Drop Hostile function in the move from Core Update 184 to Core Update 185.
I updated to 185 just in case, but there’s no difference in behaviour. Do you know if there’s any way for me to force refresh the list and clear out older entries?
If not, I suppose I’ll need to disable drop hostile for now.
Can you run the following commands on your system from the console or via an ssh terminal.
location version location list-networks-by-flags --drop > /home/drop-list
The first will give the version of the location list. Mine was dated 23/4/24
The second command lists all the networks that are classified into the drop list. It will place them in a file called drop-list in your IPFire home folder.
You can then look through that and see if the 194.87.87.0/24 subnet is listed in there.
From my test just done here are the 194.87.xx.o/24 subnets in the drop list
It would be good to see if it is in the version of the location database that you have and what version that was.
After getting the above list and checking it then you can run the following command
location update
This will update the location database to the version from today. I did that and again checked the drop list and again the 194.87.87.0/24 subnet was not in there.
You can confirm that also on your system after doing the update by running the command that outputs the drop list but I would not expect it to be there as it was not in my version from today.
After that you can try accessing the IP again and see if it now works and no longer gets DROP_HOSTILE.
The output of location list-networks-by-flags --drop has exactly the same 194.87.x.0/24 subnets as those you posted, meaning my site’s IP isn’t in there. It also has a lot of IPv6 addresses. I don’t use IPv6 so not sure how that might affect things.
Doing location update updates to the version from today, but predictably doesn’t have any effect on the issue.
I had a look at iptables -L to see what the hit counters are like for the HOSTILE_DROP_IN and HOSTILE_DROP_OUT rules. This rule’s hit count increases every time I try to load my site with drop hostile enabled:
25 1899 HOSTILE_DROP_OUT all -- any red0 anywhere anywhere match-set XD dst
This implies the IP is still a part of the XD set somehow. I can’t quite figure out how to check the contents of a set in iptables though…
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
;;
stop)
## add your 'stop' rules here
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
Yes, it’s a web server so all access is by browser. I was mentioning that my customers and my cellular network could access the site fine to show that the issue lies with my ipfire gateway, and not with the site itself.
I only mentioned it because another user found an old rule in firewall.local that had been forgotten about.
I am sorry I have run out of further ideas. There has to be something additional in your setup causing this because I can access your website without triggering any DROP_HOSTILE response yet I have Drop Hostile enabled.
I just used the same command and got the cursor back. So it is not in the XD set that I have.
Do you have any IP Blocklists enabled? I don’t believe that they work with the XD set but if you do have some set it would be worth disabling the IP Blocklist and see if that stops the problem.
That would mean you have a modified ipset set which would survive reboots.
Maybe also check if you have any command in the /etc/sysconfig/rc.local file that does something with ipsets. Mine only has a header section. There are no commands in mine.
I also do not have an ipset.conf file.
If you run ipset -t list what does it say for the XD set.
Mine gives
Name: XD
Type: hash:net
Revision: 7
Header: family inet hashsize 16384 maxelem 1048576 bucketsize 12 initval 0x93e16750
Size in memory: 269904
References: 2
Number of entries: 6709
Tried another reboot, no dice - it’s still in there. I could remove it manually (probably?) but I wonder if this indicates an issue with ipfire and looking into it further could help resolve the problem.
I have no /etc/ipset/ipset.conf and nothing in /etc/sysconfig/rc.local.
ipset -t list gives:
Name: XD
Type: hash:net
Revision: 7
Header: family inet hashsize 16384 maxelem 1048576 bucketsize 12 initval 0xee54d20f
Size in memory: 371232
References: 2
Number of entries: 9699
You have way more entries in that ipset than I have, around 50% more!!!
That looks like something went wrong with the creation of that ipset. However doing a reboot would be expected to recreate that ipset, especially as there is no ipset.conf file.
I am going to have to look through the code to see where the ipsets are created. Maybe with an update over 14 core versions something did not go correct with the updating and some code got corrupted.