Our firewall is blocking outgoing traffic from the Hostile Network rules, but when I go to Spamhaus check page, the IP in question is listed as clean. Is there an update system for the Hostile Network IP list that might be slow to update? Or is something else at play?
edit: I’ve also checked this IP at various other blacklist checkers such as
https://whatismyipaddress.com/blacklist-check
And none of them flag this IP as malicious or hostile.
You need to check the ASN that the IP is related to and then search for that ASN in the Spamhaus drop list.
I just ran a check on the IP via the location software which has the spamhaus drop list incorporated and this was the result.
location lookup 95.181.182.182
95.181.182.182:
Network : 95.181.180.0/22
Country : Russian Federation
Autonomous System : AS210756 - EdgeCenter LLC
Hostile Network safe to drop: yes
So that IP is part of AS210756 which I suspect you would find is listed as that is why the last line shows that it is safe to drop as a hostile network.
I just checked and the ASN for that network range is in the Spamhaus ASN drop list.
Thank you. I didn’t realize there was another list in use for Hostile Networks besides the one at
https://check.spamhaus.org/results
Still, it’s curious that no other bad traffic list has this IP in it. I thought Talos was the go-to and VirusTotal as an aggregator would’ve flagged it too.
Here is info from the spamhaus site on their ASN drop list.
https://www.spamhaus.org/resource-hub/dnsbl/the-return-of-the-asn-drop/
That is interesting,
ipset list | grep 95.181.182.182
comes out blank
and other blocklist check comes out sparking clean as well
and DNSBL comes out almost clean : 38 not listed and 1 listed (in some CA list)
but ASN is listed in the ASN DROP json
{"asn":210756,"rir":"ripencc","domain":"62yun.com","cc":"RU","asname":"EdgeCenterLLC"}
What part of IPFire firewall do you think is performing the blocking of ASN?
The IP resolves to a website
There is an article about the owner of that webiste
If you have a problem with the ASN Drop assignment of the Spamhaus list then you should raise this with them.
Yeah right. SH will listen to peppe
I have no issues with ASN, just wanted to know
What part of IPFire firewall do you think is performing the blocking of ASN?
My guess is location blocking (country)
Or ipblock list.
I think the OP mentioned that the firewall was blocking outgoing traffic, so I think it couldn’t be Location blocking, but let me know if this is incorrect.
I think it couldn’t be ipblock list either because the IP doesn’t seem to be in any of the blocklists,
let me know what you get when running:
ipset list | grep 95.181.182.182
It will be coming from the “Drop packets from and to hostile networks” selection in the Firewall Options menu.
This drops all IP’s that that are flagged with an XD Country Code by the IPFire Location software and this is done via the three drop files provided by Spamhaus DROP, DROPv6 & ASN-DROP which are imported into the location database via this part of the code.
location-importer.in python script
The link goes to the lines that are related to the Spamhaus files being defined as feeds.
All the DROP files are defined at subnet level and not at IP level.
I’m not sure how one would go about testing this, but I manage three IPFires and have had a handful of (what I would call) false positives that originated from ASN-DROP over the past several months. Never a false positive from Spamhaus DROP or Dropv6. Since Hostile Networks is supposed to be the worst of the worst, it should also be least likely to generate a false postive. As I started to say, I’m not sure how one would even go about testing for false positives on these items other than stumbling upon them accidentally. Seems an impossible task. But if I was voting, I would remove ASN-DROP from the Hostile Networks. It seems to drop by association. Maybe the IP you are trying to go to is not evil, but happens to be in a group of IPs where another IP is evil. I can see a place for choosing to drop these packets, but I don’t think it should be under the Hostile Networks all-or-nothing umbrella. But I understand I don’t get a vote in this situation. 
The ASN-DROP list is groupings of IP’s under one ASN, ie one responsible company or organisation.
That ASN is being run by Cyber criminals or Spammer organisations etc.
They can often be hosting organisations that provide hosting services to those criminal activities.
If someone who is not a criminal or spammer or… has paid for a hosting option on that service, then I would say that is not a good idea and they should find an alternative hosting service whose ASN is not in the ASN-DROP list.
If the hosting service organisation believe that they are incorrectly listed then they should contact Spamhaus to provide the evidence to be removed from their list.
Here is a link to a Spamhaus page talking about the ASN-DROP list with the description of
ASN-DROP is now available in JSON format, listing Autonomous System Numbers (ASNs) associated with the worst of the worst behavior. These are ASNs that our researchers wouldn’t recommend engaging with and are highly likely to announce or supply transit to IP ranges associated with malicious behavior. From networks hosting botnet command and control systems, to “bulletproof” networks selling connectivity/hosting to cybercriminals, to hardcore spammers, and more.
Thank you for clarifying this. That is something I wasn’t aware of.
This forum is so much more informative than any wiki page .
I confirmed that you can just simply disable it and I could ping the IP address above
To disable the ASN DROP you could simply do this
Firewall options for RED interface
Drop packets from and to hostile networks OFF
I could agree that something like this should be documented at least with a disclaimer for advanced users. Obviously the functionality keeps changing with every update but not everyone here knows where to find the the particular section of the code to review. Maybe just a hint would be a perfect compromise.
I am always confused with the many layers that deal with the SPAMHAUS DROP lists, even after SPAMHAUS combined the 2 lists into a single one.
It makes sense to use the ASN blocklist because one of the techniques bad guys use is swapping IP’s on the go, using the same provider. Most of them don’t change providers on the go, just IP’s . so ASN block is very useful for most admins.
It is still a little confusing to comprehend all the layers but would this assumption be correct?
1) XD Country Code by the IPFire Location only blocks incoming traffic from DROP and DROPv6 and DROP ASN lists.
2) Drop packets from and to hostile networks” selection in the Firewall Options menu. block incoming and outgoing traffic from and to DROP and DROPv6 and DROP ASN lists
3) IP Address Blocklist blocks incoming and outgoing traffic from and to DROP list only and does not block DROPv6 and not DROP ASN lists.
If any of these assumptions are correct, anyone is aware of any variations in the new core updates, let say in the recent months?. This would be informative for admins who haven’t kept up with the core updates.
but then those hostile networks will be able to try and access your network, if you have any port forwarding rules enabled.
If no port forwarding rules are enabled then those hostile networks would be getting dropped anyway.
The more critical aspect is that the drop hostile works both on incoming and outgoing traffic, so if you have someone accidentally clicking on a link that would take them to a hostile network (XD country code) then that would be dropped. Also if you had someone that had got malware on their system and that malware was trying to call home (C&C Command & Control) then again that traffic trying to go out would be dropped.
As the wiki says it is recommended to not disable it. Since it was introduced then all users who install IPFire will have the drop hostile option enabled by default.
Not quite.
2) uses 1) to drop the packets and it does it for both incoming and outgoing traffic.
So the XD code in the libloc database does nothing unless the Drop packets from and to hostile networks is selected in the Firewall Options menu in which case a firewall rule is enabled that drops all traffic that matches to XD from libloc.
For 3), yes that is correct. IP Blocklists from CU186 onwards only has the subnets from the DROP list which since March this year was combined with EDROP.
Prior to CU186 the IP Blocklists had both DROP and EDROP lists available.
The EDROP text list is currently still available but is empty except for the header lines.
The only changes is that in the Firewall Options page the logging for drop hostile used to be log all or log nothing before CU184. From CU184 onwards you can choose to log drop hostile incoming and/or drop hostile outgoing. The actual dropping of hostile networks hasn’t changed.
So if you don’t have any or many port forwards, you might decide to not log any incoming drop hostile but have logging of outgoing drop hostile turned on so you can see if anything is trying to call home from your network.
This is how I have my setup defined and periodically my android phone tries to contact locations that get dropped because they are in the Drop Hostile list. I suspect this is an aspect of some of the apps, unfortunately some of which have been installed by the phone manufacturer and can’t be uninstalled. I am more than happy that these are dropped. I never get any calling home messages from any of my Arch Linux computer systems.
The only thing that has changed in IP Blocklists is that EDROP was merged into DROP by Spamhaus and so the EDROP list was removed from IP Blocklists as was the Alienvault list as it was no longer being updated for a long time and was no longer supported. These changes were done in CU186.
In CU187 3CORESec and Abuse.ch Botnet C2 lists were added into the IP Blocklist.
All of the above were mentioned in the Announcement Blog posts for the involved Core Updates.
So you can’t use the included blocklist for DROP ASN for incoming only. Once the Drop hostile Firewall option is disabled, it will not block incoming through Location block.
Thank you that is very informative.
Is the DROPv6 list that the OP mentioned even relevant since IPFire is IP4 only?
I think if you disable the Drop Hostile option in the Firewall Options menu but then select the XD code in Location Block, then you will Drop Hostile for Incoming only.
However this will only make a difference if you have Port Forwards in place that allow the Internet side access to servers in your system. If you have no port forwards then Location Block only helps by reducing the log messages. If a country is blocked in Location Block then no logging for that traffic occurs, so that is where mostly the benefit comes from with Location Block. See the notes at the top of the Location Block wiki page.
Be aware that if you don’t have drop hostile enabled but only Location Block for XD then there is no protection from an internal user that contacts one of these networks and once they have made a connection then traffic can go both ways and all it takes is a careless click by the user and you have some unwanted malware on one of your systems. That at least is how I look at it.
Of course every user has to make their own judgement on the security and privacy risks for what is enabled and what is not enabled on the system(s) they are managing.
I don’t know but I would presume that there might be a way for something to occur otherwise the developers would not have added it into the feeds. Maybe if a user has a Dual Stack provision from their ISP then although IPv6 routing can’t be done by IPFire maybe sending traffic to an IPv6 IP can. Someone else would need to answer that question as I am just guessing on that.