Open external port into ipFire firewall?

bonnietwin · 20 April 2023 12:06

While the ssh server on IPFire is configured only for port 22 or 222 then it doesn’t matter if you define the client to only use port 24837.

The ssh config file for the client enables you to define specific settings from multiple ones that are enabled on the server. For instance allow the client to only connect with an ed25519 key and not to use the rsa or ecdsa keys as the IPFire ssh server has all three defined.

EDIT:
I have removed the Solution mark on post 5 as 75% of the posts have been after that solution was marked.

jon · 20 April 2023 12:12

I am not sure I fully understand what you are trying to do. But this may help:

https://wiki.ipfire.org/configuration/firewall/rules/dmz-setup#tldr-want-to-change-external-port-from-port-80-to-8180

bonnietwin · 20 April 2023 12:35

In this case port 222 is already being used instead of port 22 so I am not sure on how much extra hiding you get from using 24837.

Any determined port scanning will still find the port that is open for ssh even if the port number is different.

dazz · 20 April 2023 22:47

Hi
I have just done some experimentation with /etc/ssh/sshd_config.
If make multiple port entries, like this:

`Port 22
Port 12345’

then change the port to 222 in the ipFire WUI the config changes to:

`Port 222
Port 222’

so any effort to limit specific Ports to the abysm user would be undone by a port change in the WUI. Ouch.

With ipCop, I didn’t have this problem. I was able to create a custom service (which included the port), then create a rule that would direct traffic from RED to the service within ipCop. I am guessing that IPCop was just and alias for RED, but it makes the displayed rule easy to understand. I took traffic from the RED interface and forwarded it to a custom service within IPCop. That is what I am trying to do with ipFire.

I don’t have a running install of ipCop to see how this was actually implemented.

With ipFire, I can create a custom service, but I don’t seem to be able to specify the service as part of a rule. I can’t create a rule that specifies ipFire as a destination (easy to understand). I have to specify RED, which might be technically correct, but makes the WUI rule look like nonsense (RED ==> RED).

dazz · 20 April 2023 23:35

Hi Jon
The typical method for connecting a remote host to a local server in the DMZ or GREEN network is to open a pinhole through the firewall. This assumes the remote host is secure. If someone breaks into the remote host, they can then gain access to the local server through the pinhole. The firewall will offer no protection.

I have created a severely crippled user within ipFire. The user abysm only acts as a junction point for ssh tunnels. The remote host initiates a reverse tunnel to ipFire that terminates at the abysm user. This creates a pinhole through any typical firewall that the remote host might be sitting behind. The local server on GREEN or DMZ initiates a forward tunnel to the abysm user that links up to create what acts like a single contiguous tunnel from the local user to the remote host.

The tunnel from the remote host to ipFire is always open and maintained with autossh. The local user tunnel to ipFire is only opened when needed. Even if the remote host is fully compromised, any hacker would then be faced with the problem of getting past the abysm user.

Opening a ssh tunnel from the remote host requires the -N option which is "do not execute a remote command on ipFire. Without this option the connection is refused by ipFire. This only makes a hackers job of getting past ipFire much more difficult.

This configuration also improves security for the remote host if my network is infected. If my network was compromised, the intruder would firstly need to know about the abysm setup, and then execute the correct commands to open the tunnels to the remote host. Not impossible, but a lot of work. If the link was a VPN, there would be no barrier.

If I only had one remote server to deal with, then it would make sense to direct it through the standard 22 or 222 ipFire ports, but that isn’t the plan. With multiple remote hosts, it will be easier to administer and manage if each system is assigned with its own port. Shifting the port range will not improve security.

That is what I am trying to do.

hvacguy · 21 April 2023 00:45

perhaps this?

dazz · 21 April 2023 10:16

Hi
That looks promising. I will try that tomorrow.

I note there is no clue in the WUI that selecting the -Preset- Protocol is a prerequisite to reveal the user created services on that drop down list. That fragment of information could be the key to a solution.

bonnietwin · 21 April 2023 12:48

See the Firewall Rules creation page in the wiki under Protocol.

https://wiki.ipfire.org/configuration/firewall/rules#protocol

dazz · 22 April 2023 04:00

Hi
I have spent a few hours working on this today. I tried the Firewall Rules with the settings shown above, that included the custom service. I also turned on DEBUG1 level in the ‘/etc/ssh/sshd’_config file so I could see the logged response by ipFire.

The result is the same as before but worse.
I can gain remote access with the command $ ssh -N -222 -v abysm@123.456.789.0
I can see this in the ipFire logs.

I then ran the command $ ssh -N -24837 -v abysm@123.456.789.0
The connection was refused, but nothing showed in the ipFire logs.

I then added Port 24837 to /etc/ssh/sshd_config and restarted sshd.
I now have Port 222 and Port 24837 entries.

When I ran the ssh command with -p222, I connect.
When I run the same ssh command with -p24837, the connection is refused. This is worse than before.

Before I added the custom service to the Firewall Rules, I could connect by adding -p24837 to /etc/ssh/sshd_config. Now the connection is refused. Nothing appears in the ipFire logs. It appears that the connection attempt never makes it to sshd. I don’t think this has anything to do with specifying a service.

I looked at the iptables page on the ipFire WUI. I have little knowledge of iptables, but it appears that the connection attempt on port 24837 is being routed back out to the Internet.

From the ipFire CLI, I get:
`# iptables -S | grep 24837

-A INPUTFW -d 222.153.88.251/32 -p tcp -m tcp --dport 24837 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "INPUTFW "
-A INPUTFW -d 222.153.88.251/32 -p tcp -m tcp --dport 24837 -j ACCEPT `

and also:
`# iptables -L | grep 24837

LOG tcp – anywhere 222-153-88-251-fibre.sparkbb.co.nz tcp dpt:24837 limit: avg 10/sec burst 20 LOG level warn prefix "INPUTFW "
ACCEPT tcp – anywhere 222-153-88-251-fibre.sparkbb.co.nz tcp dpt:24837
`

For anyone concerned about me revealing my actual ip address, the ISP routinely changes it.

So it appears that the connection is being refused because the Firewall Rule is wrong. I think the traffic is being forwarded back out to the Internet. I want a rule that will allow me to route all traffic on port 24387 to within ipFire, and not out to any other network. ipCop included that as an option, but ipFire doesn’t.

My understanding of the instructions for external connections is to use RED as a destination to stay within ipFire, but that doesn’t work for me. I definitely want to block traffic on port 24837 escaping from ipFire out onto one of my networks.

So my question is how do I create a Firewall Rule that specifies ipFire as the destination (that is not all)?

dazz · 22 April 2023 06:24

Hi
I have successfully made a connection on port 24837.

I was restarting ssh using the WUI after making changes to the ports in the /etc/ssh/sshd_config file.
I discovered that every time I restarted ssh in the ipFire WUI, the Port 24837" entry would be replaced with Port 222’. As a result, sshd would reject connection attempts.

My work around was to edit the /etc/ssh/sshd_config file, then restart the ssh server using the commands:
# /etc/init.d/sshd stop
and then
# /etc/init.d/sshd start

This prevented ipFire WUI from over-writing the config file. This work-around is not a good long term solution. There are a number of routine reasons why I restart ssh, and I don’t want to have to restore my settings in the ssh_config every time I do a restart.

The major flaw in the working ssh server configuration right now is that allowing external access to the abysm user also allows access to root. I want to use Groups and Match commands to only allow external connections to the abysm user via port 24837.

Although it is now working, the firewall rule still looks wrong so I’d still like to know how to specify ipFire as a destination.

dazz · 22 April 2023 11:13

Hi
I am thinking that I may be reading the iptables entry wrong. If it is interpreted as:
source = any ip on the RED side from the Internet,
destination = traffic to port 24837 traffic on the RED interface
then it starts to make sense.

If this is the case, it is not intuitive to have any * traffic from RED going to RED + port.

bonnietwin · 22 April 2023 11:42

The meaning of source and destination depend on the traffic direction.

This wiki page might help.

https://wiki.ipfire.org/configuration/firewall/rules#Source & Destination

luani · 22 April 2023 18:48

Hi,
have you tried using NAT? I think it might be possible to redirect the external port 24837 to SSH port 222. So that the service can run unchanged.

dazz · 22 April 2023 23:39

Hi
I have considered NAT to port 222 but it is not my preferred option. I am aiming to allocate a port to each remote host, then use the Groups feature of sshd_config, as suggested above, to help administer access to ipFire. Every remote host would be identical, so using unique ports would make it easier to keep track of them.

More specifically, I want to allocate root to a group to deny external access. No point in creating a crippled user abysm for secure external access if root is still exposed.

Groups will only work if ipFire doesn’t overwrite Port options within Groups. If ipFire indiscriminately overwrites all Ports within sshd_config, that would effectively make Groups unusable for me. That is what I aim to test for today. I need to learn more about sshd Groups and iptables.

dazz · 22 April 2023 23:55

Hi
On reading the link it says:
"

Firewall

The firewall dropdown menu allows an easy selection of the firewall’s IP addresses. They can be selected to create rules which filter packets that are originating from or directly sent to the firewall system."

Which is OK unless the entire network changes address space. The solution would be to allocate a colour (black?) as a pre-defined alias for the firewall system. This would then make it consistent with the treatment of other pre-defined networks as described on the same WUI page:

If you want to create a rule for one of the pre-defined networks (GREEN, BLUE, ORANGE, etc.), use the dropdown boxes. Doing it this way makes it much easier if your entire network changes address space.

This would have the benefits of improved user usability using colours rather than ip addresses and simplifying ipFire administration.

dazz · 23 April 2023 02:41

Hi
I have done some testing to determine when ipFire overwrites values in the Port option.
I set multiple Port test values in /etc/ssh/sshd_config like this:

Port 22
Port 222
Port 12345
Include /etc/ssh/sshd_inc

I also Included a file with multiple Port test values. The purpose to see if these were overwritten.

Port 12345
Port 22
Port 222

I restarted ssh in the WUI with the following sequence:

Goto ipFire>System>SSH Access
Untick SSH Access
Click Save
Tick SSH Access
Click Save

The effect was that all of the Port options in /etc/sshd/ssh_config were overwritten.
None of the Port options in the Include file were overwritten.

I then restored the Port options values and rebooted ipFire from the WUI.
None of the Port values were overwritten.

Stopping and starting sshd from the CLI with the commands:

/etc/init.d/sshd stop
/etc/init.d/sshd start

did not overwrite any Port values.

At this time, I am unable to test the use-case where ipFire is updated.

The conclusion is that stopping/starting ssh from the ipFire WUI is the only identified case where the values for Port are overwritten. This is unexpected and inconsistent with other use-cases. There may be values of other options overwritten, but I didn’t look.

There are a few options to fix this problem.

The work-around is to include Port values within an Include file. These are not overwritten.

Given that the WUI only allows for the selection of 22 or 222, there seems to be no obvious reason to change every Port value in the sshd_config to 22 or 222. If there was a reason, then the same should apply to Included files.

A simple fix could be to only change the first Port value found in sshd_config file with a comment to that effect. This would leave manually added values of Port untouched. The WUI would still work properly while leaving any additional custom Port values untouched.

dazz · 23 April 2023 06:21

Hi
I am now trying to figure out how to block root access from the RED network while still allowing ssh from GREEN. I can’t find anywhere in the WUI to block root access from the RED network.

A Google search came up with the options shown here: Allow ssh access but deny root on specified networks. It is a very old link so I don’t know if it is still OK to use.

One option is to match the RED ip and deny root access.

Match Address “172.24.*.33”
PermitRootLogin yes
Match Address “192.168.1.18,192.168.1.20”
PermitRootLogin yes

The other option is to match root and specify the allow ip’s.

Match User root
 AllowUsers root@ a.b.c.d root@q.r.s.t

This looks simple to write and understand. I suspect this requires knowledge of the source ip, rather than the ip of the GREEN interface.

bonnietwin · 23 April 2023 08:33

The cgi code has been set up so that when you press the save button the sshd_config file is rewritten from scratch to have all the settings as specified in the WUI page defined. Therefore the whole file is rewritten every time you do a save.
EDIT:
This statement is incorrect. I had presumed this but not confirmed it by looking at the code. I have now looked at the code and the sshd_config file has a c based program called sshctrl that finds the lines with Port in them and changes them based on the settings on the WUI page. The same is done for Protocol, PubKeyAuthentication, AllowAgentForwarding etc. Then the sshd daemon is restarted.
This means that additions made to the file are not all overwritten. So adding an Include line to sshd_config stays in place. sshd_config is also backed up so that line will also stay in place with Core Updates. You would just need to add the file that you want to be included into the include.user file so that it is backed up.

This is the same for the DHCP and OpenVPN config files and I would expect, although not confirmed personally by looking at the code, that all config files for the WUI pages are treated in that manner.

What the DHCP and the OpenVPN configuration allow is to have include files, or to have the contents of a specific local file added to the end of the configuration file.

Currently there is no include file option available with the SSH WUI code.

You would be welcome to modify the code to have an include file added to the sshd_config and create and submit a patch for that to the IPFire development team.

https://wiki.ipfire.org/devel/ipfire-2-x/build-howto
https://wiki.ipfire.org/devel/submit-patches

tphz · 23 April 2023 09:04

I wonder if, in this case, using sslh will be helpful.

Best

dazz · 23 April 2023 09:17

Hi
I have confirmed that saving or rebooting does not affect the include files. That is where custom settings can be set. The have not had the need to overwrite parameters in the config file, just add to them. I haven’t tried, but I think I could effectively overwrite config settings by varying the line number the Include file had. Perhaps even having multiple Include files (header/footer) to control their application. I don’t think the WUI should include an option for an Include file. All of that that is good enough for what I want to do.

I have previously looked at contributing to development of ipFire. Just the time to complete the build process tells me that this is far larger that I have ever coded for/with and is probably beyond my capability. I don’t recall reading which language(s) is used. I am not a professional coder and I anticipate the learning curve would be long and steep. I had to Google “cgi” to find out what it is.