I am currently running into an issue where legitimate traffic is being flagged and logged under DROP_HOSTILE. Specifically, routine CDN connections and API requests are triggering these kernel drops because entire hosting or CDN ranges appear to be blanket-blocked as hostile.
For example, I’ve observed traffic getting dropped for:
-
i.postimg.cc (resolved to
162.251.63.43, ASNAS63023 - GTHost) which is a legitimate image hosting service. -
Huawei Cloud CDN nodes (under ranges like
38.54.123.0/24, ASNAS138915 - Kaopu Cloud HK Limited) tied to valid certificates belonging to Huawei Software Technologies Co., Ltd., which my devices rely on for normal operations.
Since these blocks impact legitimate usage, I am searching for a reason why these are blocked by DROP_HOSTILE?
External sources:
Huawei Certificate being logged for 38.54.123.57 IP logged by IPfire in Drop_HOSTILE logs: VirusTotal
OTX shows zero threats associated with that Huawei CDN IP: LevelBlue - Open Threat Exchange
How many of these:
grep DROP_HOSTILE /var/log/messages | grep -v " DPT=443" | grep "38.54.123.5" | wc
45 1080 11560
i.postimg.cc
dig i.postimg.cc; location lookup 162.251.63.43
; <<>> DiG 9.20.18 <<>> i.postimg.cc
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29613
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;i.postimg.cc. IN A
;; ANSWER SECTION:
i.postimg.cc. 643 IN A 162.251.63.43
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Sep 30 21:06:17 EEST 2026
;; MSG SIZE rcvd: 57
162.251.63.43:
Network : 162.251.62.0/23
Country : United States of America
Autonomous System : AS63023 - GTHost
Hostile Network safe to drop: yes
grep DROP_HOSTILE /var/log/messages | grep " DPT=443" | wc
342 8208 88265
38.54.123.57:
Network : 38.54.123.0/24
Country : United States of America
Autonomous System : AS138915 - Kaopu Cloud HK Limited
Hostile Network safe to drop: yes
Late edit: DPT=123 withy source IP = red0 also hit DROP_HOSTILE: I was using europe.pool.ntp for Time service and IPFire tried to reached some valid NTP servers under blanked ASN block. That was fixed by setting IPFire to use Germany based NTP servers instead entire Europe pool. But, the surprise to see NTP servers registered under Europe pool being blocked was quite big. I thought that as long as Time service is powered on the FW will ensure that daemon can reach any NTP server on the planet.
zgrep DROP_HOSTILE /var/log/messages* | grep "IN= OUT=ppp0" | grep "DPT=123"| wc
1160 23208 232213
zgrep DROP_HOSTILE /var/log/messages* | grep "IN= OUT=ppp0" | grep -v "DPT=123"| wc
0 0 0
So all DROP_HOSTILE coming from IPFire itself was for NTP sync.