OMV5 Network Firewall Setup - An error has occured

You do realize that post is from 2014 and it was made for OMV v1.0, correct?

Sorry but since I don't use it, can't really help you on that one.

Only thing I can say is: you could stick with the fail2ban service which will prevent most of the attacks you might have.

Setting up a Firewall without knowledge (following what other's might say) is a safety error. (My personal opinion)

If you don't go opening ports on your Router, you won't be that exposed to attacks.

Let's talk about security:

If you can not keep people out of your local network, how are you configuring your firewalls?

You will have to open the services you use for some IP in you local network. If I am connected to the same network, I can reuse any of the addresses and connect to NAS. If you are using DHCP and not static IPs you can not even filter only your own IP.

If you really need to protect it that way, you should invest into some intelligent switch with authentication and into some knowledge.

Instead of fighting with the firewall, use proper passwords and permissions for the nas.

It's very good that you try to have a firewall! Contrary to popular opinion on this forum...

What this particular problem stems from, I don't know much to guess about.

Start fresh clean...

Don't open up to every service on principle. Only what you need or ALL but only for a specific IP(and interface), but also be careful.

Having a correctly set fw does not work miracles, but it should be treated like washing your hands after using the toilet. Routine preventive exercise.

The rule I recommend is always block everything and allow only the narrowly chosen ones.

OMV fw gui is slightly constrained and only affects in / out.

Start by rigidly creating your environment... What IP and MAC addresses can be accessed by OMV? Let's assume that you treat the selected IP as safe and trusted.

Allow tcp / udp traffic for them and block everything else. If you have any services that need to be accessed, please specify.

Let's start with an abstractly simple example!

1. Set your OMV box to static IP and your PC!

2. Your OMV IP is 192.168.0.10
3. 192.168.0.1 is your gateway.
4. Your LAN is 192.168.0.0-192.168.0.255 (/24)

5. Your PC is 192.168.0.20

Then, based on this, you can start expanding the rules with appropriate machines and services and add flags. This is just an abstract minimalist starter example!

Of course, change the IP addresses according to your real ones !!!

Zitat von prashkd

WOW ! Although not relevant to my actual question, the rules snippet you've shared solves my immediate problem. If I can specify mac address of my devices for all protocols (except plex), I think that will give me a good start.

Theoretically, you can set a rule for the MAC address. But it won't work as much as you'd like.

The rule blocks traffic for MAC address 00: 10: FA: 6E: 38: 4A In this case, the card with this MAC address will not be able to access listening service. The philosophy is simple... you replace the rules for IP to MAC.

The problem is a little lower on the L2 layer. A typical soho LAN lacks low-level control.

If there is a hostile person in your network, at the moment nothing prevents him from changing the IP and / or MAC address to the one allowed in fw on OMV.

For this purpose, you would need at least an L2 switch and the possibility of assigning a given MAC address to a physical port in the switch. Alternatively, enter authorization for eth...

You can play with -m mac --mac-source [MAC] and create rules for other macs you have in lan and block after mac and allow only for a specific type of traffic. For example, you can control by MAC address instead of IP, but the same problem will occur at the end of the day.

Let's say I'm in your LAN as a hostile person. I can easily change IP to yours and MAC to yours. And then I can pass through the firewall and your rules without any problems. Unfortunately, the problem is somewhat elsewhere than the fw itself.

Protection with rules per IP or per MAC is ok but in the case of soho LAN to some extent it is "Security through obscurity". As long as you don't have a hostile person in the LAN who wants to do bad to you, you'll be okay with these rules. But when someone makes a minimum effort, you won't do too much on fw. Then there is the second line of defense, i.e. authorization per service and passwords / keys.

Zitat von prashkd

Our local network is shared by 4 individuals. My goal is to open only plex media port for them while keep everything else in complete lock down. Unfortunately our router is very basic with no fancy functions like VLAN so every device within the network has to be secured by firewalls.

Ask yourself these questions?

• Which IP addresses are you going to allow access to OMV services?
• How do you make sure, the IP address belongs to the right device and is not forged?
• Or how are you going to allow / block MAC addresses by iptables?

Given the rules by JohnStiles:

• Why would you allow access to DNS, NTP, Admin UI on the OMV

As soon as I have physical (unlimited) access to the network an IP firewall will not help, except for making you feel save.

Zitat von Zoki

Or how are you going to allow / block MAC addresses by iptables?

Given the rules by JohnStiles:

Why would you allow access to DNS, NTP, Admin UI on the OMV

-m mac --mac-source 00-10-FA-6E-38-4A Although it is obvious that it is such a prosthesis and it has a lot of limitations... It is also clear that you can forget about anything similar to a wildcard for MACs

Which rules are you talking about?

DNS? in input is not necessary immediately. But if the OP put even a pi-hole it will be needed.

NTP as above.

UI? If someone has OMV control, the first option is probably web ui, not ssh.

I have the impression that you are talking about OUTPUT and not INPUT.

The input chain controls the alien traffic that reaches the server.

The output chain controls the native traffic that comes from or appears on the server and is fed on.

If the OP wants full access from 192.168.0.20 to the server then his business. Alternatively, he can limit the scope for the input chain only to a narrow range of ports that it will need at any given time. Like TCP 80, 443, 22 and a few others depending on services like SMB and others...

So that the user has a better idea, I usually suggest full IP stack per trusted IP but this is a matter of taste when it comes to INPUT chain and LAN.

The output chain must be allowed to exit for udp 53 if it is to have dns, unless OP uses tunnels or DOH.

If there is no TCP 80/443 the main component that will suffer will be APT.

The server must be able to get out UDP 123 traffic if you are using OMV time synchronization.

UDP 53... server has to somehow resolve the domain names.

TCP 80 and 443 will be needed, for example, with APT.

However, TCP 8080 nad ICMP can be removed at the beginning because it does not have to be, if there is no specific need.

Of course, that's all in the case of applying global DROP rules per chain, which are supposed to block everything.

So I don't really understand your view on... the output chain has a final blocking rule, the same input chain, so these rules must exist. It is different if you have no rules then fw has all chains set to ACCEPT.

Another area of discussion is physical LAN / device protection as well as IP / MAC address spoofing. But I mentioned it already...

Zitat von JohnStiles

Which rules are you talking about?

...

UI? If someone has OMV control, the first option is probably web ui, not ssh.

You are right, didn't check the first column.

Don't get me wrong, I am all pro security and have my eervers behind an OnSense gateway even in my home, but given the OPs situation (only to protect from people on the same physical lan without a managable switch) I would not care about a firewall, but try to protect the server on the application level and try not to expose services not needed.

What will happen next is that docker messes with the iptable rules and we will have a hard time supporting that config and find out, why something is not working.

Zitat von Zoki

but given the OPs situation (only to protect from people on the same physical lan without a managable switch)

The situation is pretty bad. Teretically, you can do a little separation by putting the router with openwrt and isolating yourself a little from the LAN part, but... L2

Zitat von Zoki

What will happen next is that docker messes with the iptable rules and we will have a hard time supporting that config and find out, why something is not working.

A new opportunity for OP to learn new things.

At the end of the day, the OP got hints about two different approaches to the topic... his decision about what to choose, I only expressed my opinion because if OP wants to touch FW and do it on the basis of that old thread, it's a bit bland.