Open external port into ipFire firewall?

[dazz]

Hi
In my application, I want to setup an ssh reverse tunnel. The reverse tunnel is initiated by a unsecure remote client (ET phone home). The reverse tunnel stays live 24/7, but I only need occasional access from my end. I need to open a port on the RED interface to allow the reverse tunnel to connect to ipFire…

Typically ssh connections are forwarded from the firewall to a specific machine on the Green/Blue networks. I do not want to do that. If a bad actor gains access to the remote client and hacks in to get access to the machine, they will then be able to get onto my GREEN network.

My solution to this problem is to create a special user within ipFire called abysm using the commands:

$ useradd abysm -m -d /home/abysm -s /bin/true
$ usermod -p ‘*’ abysm

This creates a user with no shell access, and no password login access. Even if a hacker can tunnel to this user, they can’t go any further. The reverse tunnel terminates at the abysm user within ipFire.

The remote client initiates a reverse tunnel to the user absym. From my (any) pc on the green/blue network, I setup a forward tunnel that connects with the absym user. The tunnels are configured to connect end-to-end and act like they are seamless. It creates a tunnel from my pc to the remote client.

This is highly secure. This method creates a reverse tunnel that ends at a dead-end with no access to any ipFire protected network or machine. The tunnel is only open when I connect a forward tunnel to the end of the reverse tunnel. It would be a lot easier to explain if I could attach an diagram, but it worked well on ipCop. Now I need to replicate the setup on ipFire.

On the “Firewall Rules” page of ipFire, I have set the following entries:
Source
Standard networks RED
NAT
No tick in Use Network Translation (NAT)
Destination
Firewall RED
Protocol
TCP

At least one reason this won’t work is because none of the above opens the pin-hole destination port. I can’t find anywhere in the ipFire user interface/documentation where I can specify an incoming port to open without NAT. I am not forwarding the port.

If this is not something I can set up on the ipFire WUI, do I need to use iptables CLI??

[roberto (Roberto Peña)]

Hi @dazz.

I had the same problem due to the accesses that Users from Home made through RDP from their private computers (which, being private, I do not have them under control), since any network virus can infect the internal network through OpenVPN. To do this, I created this rule:

In this way, this type of Users can only communicate through RDP.

I don’t know if this will work for you, but it is the solution I adopted. Maybe someone who knows more will shed more light on us.

You will tell us

Regards.

[dazz]

Hi Roberto

I use a reverse tunnel from the remote clients because the clients are within a Mobile phone network. The Telcos all have a firewall between the Internet and their RF network to keep out traffic. A reverse tunnel from the remote client creates a pinhole through the firewall without any knowledge of the firewall.

I use OpenVPNs to allow remote connection into my DMZ so that is an option I know of. The key feature of SSH tunnels is that they are suitable and configurable for occasional intermittent connections. This includes the ability to terminate the reverse tunnel inside ipFire.

SSH is a very powerful tool that has a lot of features that are a bit like Lego blocks. Simple features can be combined and connected to make something complex.

I figured out how to include an image.
The diagram shows the overall configuration and the SSH commands. It does not include the AutoSSH setup.
I need to be able to open port 12345 (not the port I actually use) in ipFire.

The actual setup is even more complex because remotebox is a Wifi AP with SSH connections to local clients. Once I am connected with remotebox, I open ssh wifi connections to the clients.

[dazz]

Hi
I should probably explain what the diagram shows.

The remotebox builds a reverse tunnel that is aimed at my home ip address obtained with a dynamic DNS service.
The primary tunnel is aimed at the abysm user within the firewall.
All traffic passes through port 12345 at the firewall.

The remotebox also builds two reverse tunnels within the primary tunnel.

When I want to connect from my desktop pc to the remotebox, I build two forward tunnels to the absym user. The important detail is that Port 9012 and 9011 are paired to the incoming reverse tunnels. They connect seamlessly. The user abysm is simply the junction point where the tunnels meet.

So when I want to connect to the CLI of the remotebox, I simply ssh to the localhost through port 9010. That traffic emerges at port 22 on remotebox.

When I want to connect a webserver running on the remotebox, I point my web browser to port 9009 on my home desktop. That traffic emerges at port 8999 on remotebox.

In this way, I can simultaneously run a web browser and be on the CLI of the remotebox. The tunnels are invisible to applications I run on the desktop.

If needed, I could easily add additional tunnels within the primary tunnel. Traffic for all tunnels passes through the single port 12345 of the firewall.

The diagram does not show the autossh config I use to maintain the reverse tunnel.

So the problem I have is opening port 12345 on ipFire, and directing all traffic to the user abysm.

[dazz]

So without any obvious (to me) way of opening a port in ipFire, I have resorted to iptables at the CLI. This is what I have figured out.

At the CLI of ipFire enter:

$ iptables -A INPUT -p tcp --dport 12345 -j ACCEPT

$ iptables -A OUTPUT -p tcp --dport 12345 -j ACCEPT

Save the rules in Ubuntu

$ iptables-save

List the rules:

$ iptables –nL | grep 12345

These rules open port 12345 on every interface. When I look at the list of interfaces I see:

• red0,
• red0.10
• ppp0 and,
• tun0

so I think I need to add -I red0 to the commands to open the port on the red interface.

I haven’t worked with iptables before, so I could easily have got something wrong, but I think this is a viable workaround.

[cfusco]

I think you should be able to create the rule you are proposing from IPFire web user interface. Source, red; destination firewall (all), protocol: TCP, port 12345, accept.

[cfusco]

@dazz

The remotebox builds a reverse tunnel that is aimed at my home ip address obtained with a dynamic DNS service.

could you explain what you mean by the word “reverse” in your design? I find it fascinating but I have problems understanding the big picture.

[dazz]

That looks like it should do it. I am assuming the source port will be the 12345 at the RED interface.

[dazz]

Hi
It took me a long time to understand ssh well enough to do what I am doing but I am not an expert.

The way that I think of reverse/forward is that they define the tunnel entrance.
With a forward tunnel, the end that issues the command to build the tunnel is also the entrance.

So the command issued on the laptop:

ssh ipfire.localdomain -N -l abysm
-L 9010:ipfire.localdomain:9011
-L 9009:ipfire.localdomain:9012
–p 12345

builds two forward (Local) tunnels. The entrances to these tunnels are 9010 and 9009.
So to connect to these tunnels, specify one of those ports.
The exits are at 9011 and 9012.

For a reverse tunnel, the entrance is at the far end. So the tunnels built with the command:

ssh remotebox.hopto.org -N -l abysm
-R 9011:localhost:22
-R 9012:localhost:8999
–p 12345

The entrances are ports 9011 and 9012.
These two ports exist within ipFire, and they automatically connect to the forward tunnel exits with the same port numbers.

So when I issue a command from the laptop, it goes forward into the port 9010 and exits port 9011. This connects to the reverse entrance of the next tunnel also at port 9011 and exits at port 22.

Note that the user abysm has no active role in this.

I hope that helps.

[cfusco]

@dazz Thank you, I learned a lot from you. Now reading again your posts I realize that they are well written and I should have understood your design from the beginning, but I could not just because I had the wrong mental framing. I was thinking the opposite of what you wanted, meaning that the laptop was on the WAN and it wanted to connect to your LAN, protected by IPFire.

To summarize, you want to connect from your laptop inside your LAN in the green or Blue zone, to a remote access point, on the red side of IPFire, which is running some web application. You want to have two encrypted connections, one for a console access and the other for web application. You establish a pair of semi-permanent reverse tunnels from the access point to the red zone of IPFire, and a pair of forward ones from the green or blue side of IPFire, using IPFire (with a user with no shell access) to join the two pairs of tunnels. Is that correct?

If yes, I am not sure whether you need only one rule in IPFire or two. Normally, the connections from the green side are not filtered. However my uncertainty comes from the fact that the forward tunnel is not really going to the red, but goes to the firewall (IPFire). Possibly (not sure) you need to setup also a second rule like this:

Source: green
Destination: Firewall
Protocol: TCP, Port 12345
Accept

The other doubt that I have concerns the rule from the red side. Are you sure the source should be the firewall? Maybe the source should be the RED network. I am not sure.

Thank you again for teaching me something that I did not know before.

[dazz]

@cfusco Your summary is correct.

I need to experiment with the rules. In this application I want to route traffic from port 12345 to an internal port that belongs to the user absym. The risk is that the remotebox is entirely unprotected from any hacker. The assumption is that a hacker will gain full control of the remotebox. The objective is to minimise the access a remote hacker could gain to my internal networks (GREEN/BLUE/ORANGE) It is undesirable for incoming traffic on port 12345 to be forwarded directly to the blue/green/orange networks.

Ideally I would like a rule that uses port 12345 as a source, and the user absym as the destination. I don’t believe that is possible with iptables because it doesn’t know about users. The next best thing might be to specify a destination (ip?) within ipFire. I am thinking that destination could be RED. That would provide an ip address that iptables would understand. It would also keep the port 12345 traffic off ALL of the networks. The traffic would be confined to the tunnels created from the laptop.

One of the major advantages of terminating the primary tunnel within ipFire (and not at a specific machine = normal practice) is that If I suspect the remotebox has been compromised, I can connect to the remotebox with a laptop on the ipFire DMZ network. That would limit exposure to the laptop.

Effectively I am doing ssh multiplexing at the command line. The link shows how to use control sockets. I found this link long after I figured out my own method. I have not experimented with ssh control sockets but it looks promising. It would require experimentation to know if it works with unreliable network connections.

ssh is a really powerful tool, but I have also found its potential difficult to understand and identify.