Firewall source location rule ignored

Security Firewall Rules
1

To access my IPfire box from outside I created two rules:

  • One for local access from Germany and
  • One for worldwide access over a forwarded SSL port. This one is normally disabled except I’m traveling in the world.
    This looks like:

FW rules
FW rules1615×158 24 KB

In the moment I’m staying in Greece so both rules are enabled.
Accidentally I connected via port 222 (rule 4) - AND IT WORKED! :roll_eyes:
My ISPs IP here is 213.249.8.xxx, this is Greece, I’m sure.

Can anyone please check, if there is a problem in core 167 with the location based rules before I file a bug report.
I definitely expected that rule 4 would block my current IP.
Or am I doing something wrong?

2

Did a quick Test in Ipfire v167,
image
Im based in the NL.
From the US I can access through port 81 but port 443 is filtered.
From the NL I can access through port 443 but port 81 is filtered.

So it does seem to work for me how you would expect it to work.

On another note
222 is the Ipfire SSH port? Not sure if opening up your SSH port to the internet is a good idea under any circumstances. I travel a bit around EU too, but make use of the Location Block, I just unblock the countries on route and then block them again when I come home. Also use OpenVPN setup on my Windows/Linux and Android Phone for when I do need access to my home network.

3

Thanks for checking this.
Even if I disable the location based rule, I still can log in.
So I think, that the SSH port (222) bypasses the firewall. My understanding so far was, that SSH is only accessible on GREEN and needs a port forward from RED. But it seems to be accessible on RED, too.
Can anybody confirm this?

Concerning the security of SSH on RED, IMHO it’s safe, if a very strong password is used or even better, using no pwd auth at all.
But you are right, VPN should be the first choice.

4

Hi,

for the records: It is indeed.

[root@maverick ~]# location lookup 213.249.8.0
213.249.8.0:
  Network                 : 213.249.0.0/19
  Country                 : Greece
  Autonomous System       : AS12361 - VODAFONE-PANAFON HELLENIC TELECOMMUNICATIONS COMPANY SA

To the best of my knowledge, no such general issue is known.

Once in a blue moon, there were people on the forum complaining about their IPFire’s SSH port being erroneously exposed to the internet, but we unfortunately never managed to find the root cause for these incidents, and I was unable to reproduce it by any means. :frowning:

Trying to reproduce your problem, I noted that creating such a rule as (3) causes an unintended (?) side-effect: Despite being NAT’ed, port 222 becomes reachable from the country in question. This is explicitly configured by rule (4) in your example, but seems to be a quirk in the firewall engine for rule (3) as well.

I will raise a bug for this, which only appears to affect port forwardings to IPFire itself, so it is not a complete disaster. :upside_down_face: EDIT: Bug #12873 has been filed for this.

However, as @lowres already noted, a VPN would be the better approach.

Thanks, and best regards,
Peter Müller

5 Likes
5

@pmueller thanks a lot for replication and for creating a bug report for this issue.
Disabling rule (4) and getting port 222 exposed to RED nevertheless, might be considered as a potential security risk.

1 Like
6

Hi,

yes, giving this a second thought, you are right. This is not an expected behaviour at all, so it is security-relevant. Looking at the history for bug #12873, @ms thinks so as well, and takes care of this issue.

Thanks, and best regards,
Peter Müller

1 Like