Restrict NAS access to local IPs only

[Vortigern]

Dear All,
I would like to know if there's a way to block all incoming connection to the NAS (no matter the protocol) from all IP addresses apart from local IP addresses. Best would be to have a way to blacklist all and whitelist only the selected IP addresses, e.g.:

• IP address of my PC
• IP address of my TV
• IP address of my Smartphone

I generally use IP reservation over DHCP. I was thinking on something like "/etc/hosts.allow" and "/etc/hosts.deny". Is this possible?

Thanks in advance,
Vortigern

 

[danb35]

The default configuration of pretty much any residential router/firewall is going to prevent non-local IPs from entering your network, so that would generally address your question--at least as far as you presented it in the first sentence. But TrueNAS has no firewall capability, despite several (IMO misguided) requests that it be added.

 

[jgreco]

I was thinking on something like "/etc/hosts.allow" and "/etc/hosts.deny"

You're referring to libwrap.a, also known as "TCP wrappers", which is something that Wietse Venema wrote back in the 1990's. It is basically 30 year old crap. It predates the commercial Internet and was an interesting tool at a time when new security concerns were popping up on the Internet. At that time, the development of server daemons was pretty much all userland stuff, so it was possible to have an interception layer that controlled access. However, because it is essentially intended to be a userland interception layer, no one in their right minds uses it today for any serious security. Most modern daemons do not implement it, and some modern daemons are at least partially embedded in the kernel, such as FreeBSD's iSCSI, NFS, web accept filters, etc., while others use more sophisticated IP protocols such as multicast. TCP wrappers have been on a long, slow deprecation path and slide into irrelevance with the advent of high quality firewall systems.

It is usually not possible to implement libwrap globally across your services unless you are the designer of the protocols and author of the services. I would expect that numerous services would remain accessible on TrueNAS even if you tried to disable them with libwrap.

One easy way to "block" all non-local IP addresses is to omit a default gateway setting. This actually prevents return path traffic to non-local IP addresses and doesn't technically block reception of traffic from non-local IP addresses.

It is possible, but strongly discouraged, to install firewall rules onto a TrueNAS host. There is a substantial risk of these silently failing open, because the techniques people have advocated may not survive updates or reinstalls.

If you are considering exposing your NAS directly to the Internet, you are strongly cautioned against this in the harshest terms possible. The system isn't designed for this. Place a firewall like OPNsense in between your system and the Internet.

 

[Vortigern]

Dear @jgreco and @danb35,

thanks for your replies. I plan to connect the NAS to my router which is actually a modem+router (Swisscom Internet-Box2). The router has it's own firewall but I wanted to actually prevent the access with an additional security layer.

It is usually not possible to implement libwrap globally across your services unless you are the designer of the protocols and author of the services. I would expect that numerous services would remain accessible on TrueNAS even if you tried to disable them with libwrap.

I will mostly be running just Plex and NFS so, would it be possible to implement libwrap for each service? or at least restrict the NFS mounting to certain IP only?

One easy way to "block" all non-local IP addresses is to omit a default gateway setting. This actually prevents return path traffic to non-local IP addresses and doesn't technically block reception of traffic from non-local IP addresses.

I actually like this a lot: blocking all the outgoing traffic is enough. Is this easy to set? I'm still building my first system so I'm not familiar with Treunas.

Thanks for your support,
Vortigern

 

[MrGuvernment]

Unless you specifically add a NAT rule into your NAS, no one from the outside can get into it, it is only accessible from your internal LAN.

Really if you want to truly secure your network, get a proper firewall (I always suggest building out a PFSense box) and use VLANS (will need a managed switch as well that can handle VLANS) and put that in front of your ISPs modem / router - or replace it all together if they let you.

For example, I do not even use my ISP's modem, i go right from the Fiber that runs into my house, to their converter to RG45 into my PFSense. (I have yet to try and just go direct fiber into my pfsense, it should work, just have not tried it.)

 

[jgreco]

Unless you specifically add a NAT rule into your NAS, no one from the outside can get into it, it is only accessible from your internal LAN.

This isn't true. There are currently 2,572 FreeNAS systems reported on Shodan, and it is a significant misunderstanding of IP networking to assume that there is anything called "a NAT" in a network. IPv6 actually is substantially more risky because there isn't even a NAT paradigm (which is super-double-good-plus-plus actually). Even on IPv4 networks, I can trivially assign one of thousands of IPv4 addresses and give a TrueNAS host a live IP address on the Internet. Would it be smart? No. Do people do it? Definitely.

Really if you want to truly secure your network, get a proper firewall (I always suggest building out a PFSense box) and use VLANS (will need a managed switch as well that can handle VLANS)

It should be noted that this isn't "truly secure" either in many deployments I've seen. VLAN trunking is often done very sloppily, offering an attacker who has acquired a toehold access to a connected host platform access to all VLAN's.

 

[Vortigern]

Dear @MrGuvernment and @jgreco.
thanks for your comments. I've already checked the possibility to replace the ISP modem but that's not an option: Swisscom only accepts connection from their modem and since Switzerland is not in the EU the ISPs are not forced to accept generic modem...
@jgreco: in ordet o omit the gateway I assume I can just follow TrueNAS Network configuration guide and just delete the gateway in "Network>Global Configuration" is that enough?

Regards,
Vortigern

 

[jgreco]

in ordet o omit the gateway I assume I can just follow TrueNAS Network configuration guide and just delete the gateway in "Network>Global Configuration" is that enough?

If you're using a statically assigned IP address, then, yes, that should be enough.

 

[Vortigern]

If you're using a statically assigned IP address, then, yes, that should be enough.

I'm actually reserving IP addresses over DHCP. Would that work?

Cheers

 

[jgreco]

I'm actually reserving IP addresses over DHCP. Would that work?

Cheers

Only if you configure DHCP not to assign a default gateway to your NAS.

 

[Vortigern]

Only if you configure DHCP not to assign a default gateway to your NAS.

I was checking the router configuration and couldn't find any option to not assign the gateway but just a static IP to each MAC address. I might probably end up mixing static IP and DHCP: anyway I've restricted the DHCP range to 192.168.1.101-256 so I can just set all the NAS card to a static IP in the range 192.168.1.2-100. I hope this will work.

Cheers,
Vortigern

 

[MrGuvernment]

Dear @MrGuvernment and @jgreco.
thanks for your comments. I've already checked the possibility to replace the ISP modem but that's not an option: Swisscom only accepts connection from their modem and since Switzerland is not in the EU the ISPs are not forced to accept generic modem...
@jgreco: in ordet o omit the gateway I assume I can just follow TrueNAS Network configuration guide and just delete the gateway in "Network>Global Configuration" is that enough?

Regards,
Vortigern

Sometimes they just say that, but you can still do it ;) All depends how they are using their routers and if they use them to limit your connection or not. If you were really curious you could run pfsense in a VM, clone the MAC from your router and use it, an see if it works :) (I was told the same thing for me, "can only use our routers" ya, okay

 

[MrGuvernment]

This isn't true. There are currently 2,572 FreeNAS systems reported on Shodan, and it is a significant misunderstanding of IP networking to assume that there is anything called "a NAT" in a network. IPv6 actually is substantially more risky because there isn't even a NAT paradigm (which is super-double-good-plus-plus actually). Even on IPv4 networks, I can trivially assign one of thousands of IPv4 addresses and give a TrueNAS host a live IP address on the Internet. Would it be smart? No. Do people do it? Definitely.



It should be noted that this isn't "truly secure" either in many deployments I've seen. VLAN trunking is often done very sloppily, offering an attacker who has acquired a toehold access to a connected host platform access to all VLAN's.

Certainly, but in this context it is true, those other people gave an external IP to their NAS, and unless TrueNAS uses UPnP to open ports, out of the box, a TrueNAS install should not be accessible from the external internet when deployed on a LAN, unless someone specifically put in a NAT / Port forward rule to make it accessible from the public internet, or connected it to a port that directly gives it an IP, publicly routable.

VLAN hoping is very real, yet so few seem to know about it, even with locked down VLAN's with ACL's restricting access between them, limiting access to the core router and such, if someone really wants to get across your VLANs....they are going to, trunking is great, but we are almost having to go backwards now and return to physical switches for every VLAN to keep that segmentation and hope your core networking gear keeps up to the task and doesn't open some other way to be compromised.

It is a scary world we live in these days! Anything you do , can likely be exploited by at least 1 person if they really want in right.

 

[Patrick M. Hausen]

so I can just set all the NAS card to a static IP in the range 192.168.1.2-100

What do you mean by that? You cannot place more than one interface in the same network. You can of course use addresses from that range for VMs or VNET jails.

 

[jgreco]

those other people gave an external IP to their NAS, and unless TrueNAS uses UPnP to open ports, out of the box, a TrueNAS install should not be accessible from the external internet when deployed on a LAN, unless someone specifically put in a NAT / Port forward rule to make it accessible from the public internet, or connected it to a port that directly gives it an IP, publicly routable.

Okay, this is sort of silly. If you plug a device into a network jack because some YouTuber showed you "How to set up FreeNAS", and you really had no clue what you were doing, you could absolutely get a DHCP reservation on the public Internet. I guarantee that AT&T and Spectrum will both happily serve a UNIX box just by hooking up. No port forwards, no UPnP, no NAT rules. There are absolutely environments where none of those things exist or are needed.

Trying to blame the user by saying that they "specifically[....]connected it to a port" is not relevant; your original statement was

Unless you specifically add a NAT rule into your NAS, no one from the outside can get into it, it is only accessible from your internal LAN.

which clearly says "no one from the outside can get into it" and also restates it as "it is only accessible from your internal LAN." I'm willing to get into an argument over this because it is plain old wrong. Especially with the advent of IPv6 /64's.

VLAN hoping is very real, yet so few seem to know about it, even with locked down VLAN's with ACL's restricting access between them, limiting access to the core router and such, if someone really wants to get across your VLANs....they are going to, trunking is great, but we are almost having to go backwards now and return to physical switches for every VLAN to keep that segmentation and hope your core networking gear keeps up to the task and doesn't open some other way to be compromised.

VLAN hopping is mostly an imaginary issue that becomes a tragic reality on poorly designed and poorly configured networks. In a proper VLAN environment, with proper ingress and egress controls, and without the infamous Broadcom broadcast domain issues that were present in some mid-2000 chipsets, there should not be cases where frames are misdelivered, and so the network should be equivalent to regular LAN's, just with the peculiarity that multiple networks may come in over a trunk.

The common misconfigurations are --

-- to allow double tagging packets to ingress: many switches will allow ingress from both tagged and untagged frames on a trunk port, but this is an error. You should reject untagged frames on a trunk port. The silicon in many switches will strip the first tag on a packet and then forward the packet to members of the VLAN referenced in the second tag. This is stupid behaviour. It can be turned off in most decent switches. Plus, there's no return path from the victim network back to the client injecting the packet, so this is of very limited usefulness.

-- allowing automatic trunking or automatic vlan negotiation: do not let clients control your network architecture. This is just akin to giving an attacker a means to plug a cable into any part of your network.

But these are naive configuration errors.

hope your core networking gear keeps up to the task and doesn't open some other way to be compromised.

That's always been a problem with virtualization. The convenience of being able to virtually move network connections around from your office desk and the convenience of being able to spin up and control virtual machines both have similar risk/rewards; properly designed systems are reasonably safe but there is always the opportunity for a new exploit to cause harm. Yet we had intruders causing problems years before vlans or vm's.

 

[MrGuvernment]

I am not looking to argue over anything, but as @danb35 noted

The default configuration of pretty much any residential router/firewall is going to prevent non-local IPs from entering your network,

I never claimed plugging a Unix, or any device directly into a direct connection from an ISP would not give you a DHCP address. In the context of this post, the user has a router / modem provided by their ISP as they noted which is assigning Internal non routable IP addresses and is using IPv4 (192.168.*.*) No mention of IPv6 in their post, so going based on the information they are providing is what I was basing my comments off.

Sure this stuff you already know (I don't doubt your knowledge in this area likely far exceeds mine) Some ISP's in the past will not assign you an IP with out using their device (Costa Rica ISP's thought they were smart locking things to a MAC address, not realizing, sadly, that can be cloned...). But some just drop a line and you can connect what ever you want to it!

Back in the day, some ISPs even used their device for controlling of your speeds, then they got smart and moved passed that when they realized people could modify their devices to get faster speeds (talking over 20+ years ago with Rogers in Canada and a couple other ISP's)

By default, ISP's devices (at least any I have dealt with from home to business in the 26 years I have been around the I.T world) those do not forward traffic to your internal LAN by default out of the box , but if UPnP is enabled (which many do ^%$$%^ for home) then yes, that could open a hole into one's network. Or, if they bridged a port (as some ISP devices let you, in order to run your own device behind it so you don't have to deal with double NAT) then no, there should be no way for anyone externally to be able to access your internal LAN, unless one specifically created rules to allow traffic in.

So, based on the OP's current configuration, no what if's, or possible scenario's or clueless people from youtube telling someone what to do, their environment, externally, no one should be able to get into their NAS or network, unless they have set up specific rules with in their ISPs router / modem to allow it.

And ya, IPv6, our savior! Lets give every device a IP that is accessible to the world! Genius!

 

[Whattteva]

And ya, IPv6, our savior! Lets give every device a IP that is accessible to the world! Genius!

I personally don't think IPv6 is automatically a bad thing just because you no longer use NAT. NAT was never meant to be a security measure anyway. If you want security, configure a proper firewall. IPv4 NAT has always been more of a "security by obfuscation" type thing, not really an actual security measure especially since most default configurations automatically keep state and always let return connections as long as it's been initiated by a client within the network and this is exploited by things like TailScale.

 

[Vortigern]

Dear All,
thanks a lot for your replies.

By default, ISP's devices (at least any I have dealt with from home to business in the 26 years I have been around the I.T world) those do not forward traffic to your internal LAN by default out of the box , but if UPnP is enabled (which many do ^%$$%^ for home) then yes, that could open a hole into one's network.

I actually have the UPnP enabled! Is it that bad?

What do you mean by that? You cannot place more than one interface in the same network. You can of course use addresses from that range for VMs or VNET jails.

I have 3 NIC on my motherboard so I plan to connect 2 of them for LAN traffic by using Link Aggregations and the 3rd one is for IPMI. Is there any issue with that? Of course each one will get it's own local IPv4.

I'm fascinated by the amount of knowledge which has been shared it's just hard to digest to me because I'm just a home user and I'm not experienced in networking and that's why I'm looking for an easy solution to secure my NAS. Thanks for being patient.

Cheers,
Vortigern

 

[Patrick M. Hausen]

I have 3 NIC on my motherboard so I plan to connect 2 of them for LAN traffic by using Link Aggregations and the 3rd one is for IPMI. Is there any issue with that? Of course each one will get it's own local IPv4.

If you use link aggregation there will be only one IP address on the aggregated interface. And your switch needs to support LACP. You cannot, I repeat: you cannot, assign two different IP addresses from the same network to two distinct interfaces. One network, one interface. That's how IP works.

If your server platform supports a dedicated IPMI interface that is of course going to work. Use DHCP to get it connected, then configure a static address if you prefer that or assign a fixed address in your DHCP server.

 

[Vortigern]

Dear @Patrick M. Hausen,
thanks for your reply. Indeed I've just checked my router and looks like it's not supporting LACP. I've also found a very interesting post: Multiple network interfaces on a single subnet.

Thanks,
Vortigern