Just an FYI thread,
I am not sure if it is a real issue or just how the way things work.
This is on Core Update 162 and 163
I noticed recently that there are 2-3 entries DROP_TCP Scan per day from China, Netherlands, or Kazakhstan in Logs- Firewall log (Country) ,
I have noticed 2000-3000 entries in IPS logs for long time.
This is while Location block is enabled, and blocking all countries.
This is before 162 I am sure.
Looking at the country flags that are showing up in firewall log despite country code block, it is worth checking IP address lookup. The flag and the IP country don’t always match.
For instance, I have seen:
Flag: BG - EU
Flag: NL - CN, Seychelles, GB, NL
Flag: HK - HK
Flag: US - US
Flag: FR - FR
All the above and more being logged despite location block.
Hi,
first, thank you for opening a new thread for this.
This is because packets will first go through the IPS before reaching the location block afterwards. Therefore, the IPS will inspect such packets, and log if any rule triggers, even if the source country is enabled in the location block.
(This, by the way, will change with Core Update 164 and the “drop hostile” functionality: If the latter is enabled, all packets from and to hostile networks will be dropped before they are processed by the IPS.)
At the moment, I can only guess why this is.
My suspicion would be a design flaw in the xt_geoip module the IPFire core developers spotted a few weeks ago: Even if the location database is updated on an IPFire installation, the changed data will never land in the kernel space via xt_geoip module until the system is rebooted.
This means the location data actually used by the kernel will diverge from the location data displayed in the GUI over time. The longer an IPFire installation is up, the bigger will this delta grew. 
For Core Update 164, I cannot offer a solution to this. However, as discussed in February’s telco, we will replace xt_geoip with ipset in Core Update 165, which solves this flaw. Also, ipset is less dangerous in terms of security - we have always had kind of a headache with xt_geoip in this regard…
Thanks, and best regards,
Peter MĂĽller
Just to clarify, I am not using IPS, the logs getting through are in the standard Firewall Log.
I also have my firewall on a scheduled weekly reboot, so shouldn’t diverge that much from the GeoIP database. Will be interesting to see what happens cu 165 onwards.
Thanks
Hi,
well, I don’t have exact numbers at hand, but just looking at the commits generated daily by the location database generator leaves the impression to me that there is a significant delta agglomerating indeed over a week. 
Thanks, and best regards,
Peter MĂĽller
Hello,
I am testing update 164 and I have noticed this same behaviour with FW-loggraphs (country); countries that I have blocked are now being logged again, although they have many fewer hits than before I blocked them. Uptime is only just over a day since the update.
I have the same
I removed anycast.censurfridns.dk from dns on tls list of servers, and it seem’s like it fix my problem.(no drop_tcp scan) … so far for the past two days.
Are you using that dns on tls provider ?
Hi,
what prefix do these logs have? If it’s DROP_HOSTILE, then the networks in question are blocked by the “drop hostile” feature introduced in Core Update 164. Since they will always be logged, this would be the expected behaviour then.
That’s weird, especially because the IP address of this service should be flagged as country DK, not CN.
Could you post the complete log messages here?
Yes, and I never observed such a erroneous log message, or any other problems with it. Interesting.
Thanks, and best regards,
Peter MĂĽller
Yes - that appears to be the case, thank you.
With pleasure … could you specify path of log you want,
Thank’s
thought that server is anycast, and still today no more drop_tcp scan … but not a specialist
@pmueller here are some logs. If you need more info, let me know !
IPFire firewall log
: January 08, 2022
15:58:16 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=221.223.35.118 DST=xx.xxx.xxx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=27052 PROTO=TCP SPT=530 DPT=7354 WINDOW=25094 RES=0x00 URG ACK PSH RST SYN FIN URGP=0
IPFire firewall log
: January 15, 2022
15:47:11 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=49.234.219.226 DST=7xx.xxx.xxx.xx LEN=552 TOS=0x00 PREC=0x00 TTL=41 ID=43842 DF PROTO=TCP SPT=59081 DPT=31636 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=15011
10:09:06 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=193.112.143.81 DST=xx.xxx.xxx.xx LEN=552 TOS=0x00 PREC=0x00 TTL=41 ID=57289 DF PROTO=TCP SPT=47549 DPT=10877 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=13473
08:41:07 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=123.178.109.62 DST=xx.xxx.xxx.xx LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=43601 DF PROTO=TCP SPT=60551 DPT=36707 WINDOW=0 RES=0x00 URGP=0
IPFire firewall log
: January 22, 2022
22:41:10 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=49.235.127.59 DST=7xx.xxx.xxx.xx LEN=60 TOS=0x00 PREC=0x00 TTL=41 ID=31676 DF PROTO=TCP SPT=20986 DPT=1472 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=9885
13:57:52 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=181.92.9.57 DST=7xx.xxx.xxx.xx LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=53423 DF PROTO=TCP SPT=64075 DPT=51911 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=58166
13:36:12 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=175.24.234.116 DST=xx.xxx.xxx.xx LEN=60 TOS=0x00 PREC=0x00 TTL=41 ID=53445 DF PROTO=TCP SPT=46773 DPT=5903 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=21211
13:57:52 DROP_TCP Scan red0 TCP 181.92.9.57
xx.xxx.xxx.xx 64075
51911 AR
IPFire firewall log
: February 05, 2022
07:43:32 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=180.188.232.12 DST=xx.xxx.xxx.xx LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=26261 PROTO=TCP SPT=52229 DPT=32791 WINDOW=65535 RES=0x3c CWR ECE URG ACK PSH RST SYN FIN URGP=65535
07:43:32 DROP_TCP Scan red0 TCP 180.188.232.12
xx.xxx.xxx.xx 52229
32791 IN
IPFire firewall log
: February 08, 2022
23:04:47 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=45.148.10.241 DST=xx.xxx.xxx.xx LEN=44 TOS=0x00 PREC=0x00 TTL=243 ID=21882 PROTO=TCP SPT=32333 DPT=3283 WINDOW=65535 RES=0x00 URGP=0
22:28:30 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=45.148.10.241 DST=xx.xxx.xxx.xx LEN=43 TOS=0x00 PREC=0x00 TTL=243 ID=63246 PROTO=TCP SPT=12515 DPT=3702 WINDOW=65535 RES=0x00 URGP=0
20:43:30 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=185.81.157.51 DST=xx.xxx.xxx.xx LEN=55 TOS=0x00 PREC=0x00 TTL=243 ID=39664 PROTO=TCP SPT=20295 DPT=11211 WINDOW=65535 RES=0x00 URGP=0
23:04:47 DROP_TCP Scan red0 TCP 45.148.10.241
xx.xxx.xxx.xx 32333
3283 NL 00:c1:b1:61:08:19
22:28:30 DROP_TCP Scan red0 TCP 45.148.10.241
xx.xxx.xxx.xx 12515
3702 NL 00:c1:b1:61:08:19
20:43:30 DROP_TCP Scan red0 TCP 185.81.157.51
xx.xxx.xxx.xx 20295
11211 FR
IPFire firewall log
: February 24, 2022
14:22:53 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=123.178.109.62 DST=xx.xxx.xxx.xx LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=52846 DF PROTO=TCP SPT=242 DPT=48778 WINDOW=0 RES=0x00 URGP=0
14:22:53 DROP_TCP Scan red0 TCP 123.178.109.62
xx.xxx.xxx.xx 242(DIRECT)
48778 CN
IPFire firewall log
: February 25, 2022
13:17:15 IN=red0 OUT= MAC=00:10:a7:25:fd:11:00:c1:b1:61:08:19:08:00 SRC=2.57.122.35 DST=xx.xxx.xxx.xx LEN=83 TOS=0x00 PREC=0x00 TTL=240 ID=63078 PROTO=TCP SPT=32027 DPT=80 WINDOW=65535 RES=0x00 URG ACK PSH RST SYN FIN URGP=0
13:17:15 DROP_TCP Scan red0 TCP 2.57.122.35
xx.xxx.xxx.xx 32027
80(HTTP) NL
Those are just samples of logs from january to march 3.
As you can see, it’s not only CN, but FR NL AR IN.
On march 3, i removed
[quote=“loup001, post:7, topic:7334”]
anycast.censurfridns.dk
[/quote] and since then no drop tcp scan …
Thank’s
Hi,
sorry for my late reply.
Thank you for providing these log messages.
Anything that has the “URG ACK PSH RST SYN FIN” is interesting to see. These appear to be FIN-ACKs (which conntrack seems to flag as invalid sometimes, but I do not know why that is yet), but I do not expect those packets to have a SYN flag set, too.
Either I am missing something completely, or those packets are bogus - I would blame a completely broken TCP implementation if this wasn’t for some well-known public DNS resolvers…
To be honest, I still do not have a reasonable idea on the “TCP scan” hits from countries being blocked in the location block. As I mentioned here, there might be a delta between the country allocations the GUI shows and the xt_geoip module is actually using, but none of the offending source IP addresses was recently reallocated, so I doubt this could be a reason.
Looking at the firewall initscript, the chains related to TCP/UDP/… scan come before the connection tracking. This means a packet matching one of the criteria for the BADTCP chain will be logged and dropped accordingly, even if it belongs to a connection that was established by IPFire or a client behind it.
Consequently, that would mean one or more of your devices established connections to these IP addresses, which would at some point respond with a bad/(deliberately) broken network packet. That packet is being logged as a “TCP scan”, giving the misleading appearance of the location filter not working properly.
At the moment, I cannot really think of another reason. Is there any way of telling if a client established connections to these IP addresses, i. e. if you enabled logging of accepted connections in a firewall rule? That might clarify things even further.
Thanks, and best regards,
Peter MĂĽller