Could you please elaborate how location block distinguishes from dropping hostile networks s.t. almost all countries are blocked. As far as I understand location block only covers incoming traffic whereas the new feature tackles incoming and outgoing traffic.
Assuming checking outgoing traffic would not be crucial for me what is the benefit of enabling the new feature in addition to blocking all countries?
Thank you.
Hi,
yes, this is correct.
Also, I think it is important to understand that the “drop hostile” feature is about a network’s reputation, not the country it is allocated to. For example, many networks falling under this definition are located in the US, the Netherlands, and other countries one cannot block completely (at least not for outgoing traffic), because that would generate way too many false positives.
In my opinion, blocking traffic because of the believed (this is not an accurate science) location of an IP address lures people into thinking countries have a sort of reputation score assigned to. Today, depending on your believes, the “baddest” country might be Russia, China, or the US.
None of that is true - in all countries are networks with an excellent reputation as well as networks with a very poor reputation. Therefore, the “drop hostile” feature is more accurate in filtering out the latter than any location-based firewalling is.
No offense intended, but I believe this is categorically wrong.
You do care about outgoing traffic, because it is much more security-sensitive than incoming one. Every software is nowadays prepared to handle bad incoming packets, but little effort is made to spot malicious outgoing connections - for example, to C&C servers, or malware distribution sites, or phishing servers.
Having a good IPS policy can help you to detect known patterns of badness in outgoing connections, but there are some networks being so dangerous that you do not want to process any connection from or to them, no matter what. These are covered by “drop hostile”.
Therefore, I believe enabling that feature makes sense for virtually all IPFire users - which is why that is default on new installations. 
Hope to have helped.
Thanks, and best regards,
Peter MĂĽller
Another related question. Having upgraded to CU164, and having turned on “Drop packets from and to hostile networks (listed at Spamhaus DROP, etc.)”, how many hits does one expect to be logged? In a 24 hour period, I have logged in excess of 1800 log entries. This makes the FW log file difficult to sort through. And this does not include the DROP_CTINVALID entries which are also numerous, around a few hundred.
I am mostly curious about what other folks are experiencing.
On a slightly related note. In Location Block, how does the filtering order work? For instance, ip address 123.456.789.123 out of country AA is on the hostile networks list and is associated with country AA, does the country filtering work first or does the hostile network filter XD come first? I realize that one or the other will filter it.
Have a great day all, PZ
Hi,
indeed, the “drop hostile” feature can produce quite an amount of log messages - maybe because there are so much hostile networks on the internet. 
I don’t have the numbers of any IPFire machine I administer at hand, but several thousands of them seem to be a plausible value. For attractive targets (such as machines hosting public services or being located in countries or networks commonly referred to as being interesting), one can safely expect more, depending on where the attacker’s systems are located.
A related comment to that: If the attackers are smart, they will most certainly avoid networks being flagged as “hostile” (i. e. being listed at Spamhaus DROP), and rather abuse compromised legitimated machines or rent VPSs at legitimate hosters straight away. Sadly, thanks to poor abuse handling at some IT giants, they have an easy time doing this.
To cut it short: Expect “drop hostile” to get rid of the mass scanning for you. Targeted attacks will most certainly slip through, if the attacker invested some brain cells on their business.
Regarding the logging: Yes, indeed, the log analysing capabilities of IPFire 2.x are not really state-of-the-art. However, I believe you could still gain insights from those logs, for example, by setting up a Cron job searching for outgoing DROP_HOSTILE events, and alerting you if there were any. These are certainly ones you want to know about.
DROP_CTINVALID is actually the attempt to make debugging easier: These packets have always been dropped, but were never logged. Personally, I suspected conntrack to drop some packets it shouldn’t, but could never proof that. Now, thanks to logging of these, things are more transparent since it is more clear what IPFire does and what it doesn’t.
To answer your last question: Yes, the “drop hostile” feature takes precedence over the location block.
Thanks, and best regards,
Peter MĂĽller
Thank you very much. That was helpful.
Have a pleasant rest of the week. PZ
If you’ve installed the IPFire addon named monit, then you can add this to the config file to monitor outgoing DROP_HOSTILE events:
# review messages log
check file messageLog path /var/log/messages
ignore content = ".*monit.*"
# review messages log for DROP_HOSTILE
# but do not look at red0
if content = "DROP_HOSTILE IN=(blue0|green0|orange0)"
then alert
EDIT: temporarily add a space to test so test can pickup non-red0 content.
if content = "DROP_HOSTILE IN=( |blue0|green0|orange0)"
This should disappear in future.
This is great idea, I will try if it works with suricata, and maybe apc-upsd
I set up monit and verified its function. Hostile drops on red0 are being reported. I tried to test it with green0 but I did not find any malicious domain associated with Spamhouse’s IP-drop list. Does anyone know a domain to test outgoing drops on green?
It is a good question! I tested with red0 also, but I have not had any hits with green (or blue or orange).
If I come access something I will share.
Hi,
just for the sake of completeness: Since the Spamhaus DROP lists are publicly available here, you can just try to establish a connection to an IP address that is covered by a CIDR listed in any of the DROP lists.
A live phishing (and/or malware) domain being hosted in such networks would be my-authentication-x322s[.]com, tracing back to 45.9.148[.]44 at the time of writing, being covered by this SBL/DROP listing.
Thanks, and best regards,
Peter MĂĽller
Thanks Peter, i already tried some of the addresses from the drop list but wasn’t able to trigger an alert. The domain name you stated worked out just perfectly 
It is a good thing Sam suggested testing! There may be an issue. IN=red0 is good.
But there is no IN= info for green0. (I did not test blue or orange).
Add a report to bugzilla?
Apr 14 11:02:49 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MAC=00:0x:x9:5x:x9:x8:00:01:5x:67:4x:46:08:00 SRC=194.nnn.nnn.nnn DST=73.nnn.nnn.nnn LEN=40 TOS=0x00 PREC=0x20 TTL=232 ID=62944 PROTO=TCP SPT=45675 DPT=5998 WINDOW=1024 RES=0x00 SYN URGP=0
Apr 14 11:02:55 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MAC=00:0x:x9:5x:x9:x8:00:01:5x:67:4x:46:08:00 SRC=89.nnn.nnn.nn DST=73.nnn.nnn.nnn LEN=40 TOS=0x00 PREC=0x20 TTL=237 ID=53917 PROTO=TCP SPT=56804 DPT=45635 WINDOW=1024 RES=0x00 SYN URGP=0
Apr 14 11:02:56 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=19320 DF PROTO=TCP SPT=46056 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:02:57 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=19321 DF PROTO=TCP SPT=46056 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:02:59 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=19322 DF PROTO=TCP SPT=46056 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:03:03 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=19323 DF PROTO=TCP SPT=46056 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:03:11 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=17225 DF PROTO=TCP SPT=46058 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:03:12 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=17226 DF PROTO=TCP SPT=46058 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:03:14 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=17227 DF PROTO=TCP SPT=46058 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:03:18 ipfire kernel: DROP_HOSTILE IN= OUT=red0 SRC=73.nnn.nnn.nnn DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=17228 DF PROTO=TCP SPT=46058 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Apr 14 11:03:59 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MAC=00:0x:x9:5x:x9:x8:00:01:5x:67:4x:46:08:00 SRC=194.nn.nn.nnn DST=73.nnn.nnn.nnn LEN=40 TOS=0x00 PREC=0x20 TTL=232 ID=45697 PROTO=TCP SPT=45675 DPT=3623 WINDOW=1024 RES=0x00 SYN URGP=0
EDIT: same issue with blue0
EDIT2: added bug report:
https://bugzilla.ipfire.org/show_bug.cgi?id=12850
Jon, could you please post your monit rule. This is the content of the monit alert I received after probing with the mentioned domain.
Content match Service messageLog
Date: Wed, 13 Apr 2022 23:07:08
Action: alert
Host: ipfire.localdomain
Description: content match:
Apr 13 23:06:08 ipfire kernel: DROP_HOSTILE IN=green0 OUT=red0 MAC=xxx SRC=192.168.5.2 DST=45.9.148.44 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=10389 DF PROTO=TCP SPT=49064 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
...
Your faithful employee,
Monit
Here is the current monit rule (updated yesterday):
# review messages log
check file messageLog path /var/log/messages
ignore content = ".*monit.*"
# review messages log for DROP_HOSTILE
# but do not look at red0
if content = "DROP_HOSTILE IN=( |blue0|green0|orange0)"
then alert
FYI… Just found this:
When I open a Safari browser and enter:
http://my-authentication-x322s[.]com
then IN=[blank]
When I open a Safari browser and enter HTTPS (not HTTP):
https://my-authentication-x322s.com
then IN=green0
Hi Jon,
that very much sounds like HTTPS connections bypass your IPFire’s web proxy.
For HTTP, the web proxy can intercept and redirect requests, hence the TCP connection to the actual destination ( 45.9.148[.]44 in this case) is established from IPFire itself, and there is no incoming interface for it. For HTTPS, the TCP connection is established directly from Safari to the web server, hence it has an incoming interface from IPFire’s perspective.
Thanks, and best regards,
Peter MĂĽller
I think the answer is “yes”. I have Web Proxy Transparent mode enabled on both green and blue.
I assumed that since I am in transparent mode that everything (http and https) would come from IN=green0. Like this example from https.
Apr 15 11:47:50 ipfire kernel: DROP_HOSTILE IN=green0 OUT=red0 MAC=00:01:b2:53:b4:d5:36:c7:88:49:f0:11:02:03 SRC=192.168.60.212 DST=45.9.148.44 LEN=48 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=50599 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Hi,
this is why I am always a reluctant to transparent network things: On the one hand, they make tasks so much easier since the end-user does not have to do anything, but on the other hand, they can be really painful to debug, especially if side-effects are not obviously caused by a certain functionality.
Anyway, glad to have this worked out.
Thanks, and best regards,
Peter MĂĽller
I’ve tried a few times to get non-transparent mode working but I’ve failed each time.
The wiki just didn’t make sense to me!
[deep breath] - I’ll have to try again.