Trying to configure the firewall, a few questions

The firewalls used in OMV is the linux kernel firewall (iptables).

If you are behind a router, does this router NAT (looks like that as you have private addresses).

So if so, yes all the traffic reaching your OMV will come from 192.168.0.1 with the exception of local traffic (so any other client in your network).

The firewall is deactivated by default. If you really want to open ports to the internet, you should carfully read on or the other internet howto of how iptables work and how you deploy a default rule (drop all). After that default rule in place, (which will block everything), you than can open up ports one by one again and test if they work. You need to be outside of your network to test the rules effectively.

As (i assume) OMV will not act as a router, all pakages that does not have OMV IP as destination IP should be dropped. But anyhow I would also put in a trusted machine somehow (your workstation) so that you can access OMV. Otherwise the first thing that may happen is, that you cut your own admin connection.

NX??? Are we talking about Desktop Virtualization?

The firewall is on but no ports are blocked. You start with all ports open in Debian and then you must close them. Before you close any ports you should make entries for ports you want open and then make entries to close the rest of the ports. There are different approaches you can take to secure your system with the firewall. Take a look at this user. He opened all ports to certain ip addresses and then has entries to close all ports to anyone other ips.

http://forums.openmediavault.o…pic.php?f=15&t=564&p=2096

This is not my preferred method, as I have more complex entries in my firewall that I can't enter into OMV's simplified firewall frontend, but this method will work for most OMV users.

You can have that rule but you need some rules before it. You can use a rule to accept from an IP on your LAN to your OMV with tcp & all ports. Look at link I gave above. The rule you used to block everything needs to be last.

I put up an example in a screenshot.

This ruleset accepts connections to 22 and 80 (ssh and http) from any high port inside my local network.
It allows full communication locally from OMV to OMV on 192.168.0.5
It drops everything else from anywhere to 192.168.0.5
Traffic from and to 127.0.0.1 is not affected.

Hope that is a little better to understand. And YES it works great after you committed the changes to the system.

You need to press the commit button, otherwise the ruleset is not active at all.

The ruleset above worked great and directly cut of my CIFS shares

Ser, you don't use UDP at all?

Funny guy.

This is an example config to demonstrate how the ruleset works without any real usecase. It is neither complete nore bulletproof in any way.

In the configuration above UDP is completely open.

But anyhow I am not aware of any UDP service running on my box (I do not use bittorrent for instance).

The problem with firewall rules is: Please make sure that you really know what you are trying to achieve and how to achieve that goal. Otherwise you will end up with a security hole that you consider to be safe. The UDP example is one of those things.

No, I did not mention to be funny. I mentioned because of this:

UDP/137 - used by nmbd
UDP/138 - used by nmbd
TCP/139 - used by smbd
TCP/445 - used by smbd

http://www.samba.org/samba/docs/server_security.html

I didn't know you were showing rules you did not use. You are probably not even using firewall on OMV because you have hardware firewall.

There are 2 big reasons I did not like this simplified firewall in OMV.
1) No reject all (I don't like everything opened and then closing it. I like everything closed and then slowly open up, like on Fedora when you start firewall.)
2) my tcp forwarding was not working because I need a rule accept if established or related.

Volker asked me to put some things on the bug report but if you need more complex firewall you can just manage in command line.
I do not want to slow Volker down on development of .5. Later down the road I will post some ideas for him on firewall. The firewall works
via the kernel the same as Fedora but the way it is implemented is way different.

Okay, something about firewalls.

Every firewall rule have the following format:

QUEUE ACCESS PROTOCOL SourceIP/Subnet:PortRange DestinationIP/Subnet:PortRange

Kind of a good introduction here: https://help.ubuntu.com/community/IptablesHowTo

I do not dive into QUEUE, ACCESS is like ACCEPT, DROP, REJECT, LOG whatever; PROTOCOL is something like TCP, UDP, ICMP etc. pp.

Now lets come to how the Internet works:
Every IP Packet has a source and a destination Address. That was easy. Source is your PC in this case and destination is your OMV. That form the Layer3 of the OSI Layer Model.

Above that, there is the TCP or UDP layer (4). That uses a source and a target port. The target port is what you know about (like 22 for SSH). The client will randomly select any port above 1023 (so anything between 1024 and 65535). The reason for that is, that ports below are reserved and require admin rights to open a port. No client program should ever try to open a restricted port (and will on most OS anyhow not get any from the TCP stack). To be clear, your ssh client (Putty) will never use port 22 on the client (source) side, where it will allways connect to port 22 on the destination.

The the rule is simply to allow ssh to the machine and remove the ports on source side, which anyhow should never be used. If they were used I would exclude them, cause they are suspicious. But thats my own feeling.

So if you do it on CLI, you could create the ultimate drop rule:

iptables -P INPUT DROP

The policy for the INPUT chain is ALLOW in OMV and it should be DROP as default. That would mean, everything that is not open per definition of a rule is dropped by default.

Unfortunately that will get removed everytime you boot. So this rule will do the same job, if you put it in the last position in the table.

Hope that is more clear

The /24 at the end is the netmask. /24 stands for netmask 255.255.255.0.

At first we did not have the drop command. The only difference between drop and reject all is that reject all will send an error message "connection refused". Drop will not send any error messages.

I see Volker added a lot of options to the protocol list since I last looked at the firewall. Impressive, most impressive!

Drop is in the gui.

I understand that the policies are all set to accept instead of drop, cause otherwise nothing would work.

What i would love to see in the gui is a possibility to change the channel policy. So fo expert users setting this to default drop and then open simply the required ports would be great.

The next step would be to automatically open ports from plugins ... If you activate samba the plugin can add the required rules ... Just dreaming.

Where 192.168.1.29 would be your OMV ip.
Where 192.169.1.0/24 would be your lan.
The 3rd rule directing source 80 to your OMV is needed for updates.

Ser, I wish we had a "do nothing" option for the rules. So we could turn on or off a rule like I do in webmin. Like if you temporaliy want to open a port to the web and don't want to erase the rule. Also, this would be good for testing.

PS- I tested this on virtual machine. When I had 1024-65535 for tcp putty would not connect. So I changed to 1-65535 for lan. Tested lo traffic and it was working fine.

Tekkbebe,

your reject rules can be much simpler today, as OMV as updated the GUI part to the firewalls.

It is simply the rule above. It will drop everything (TCP, UDP, IMCP). If you want ICMP to be open, then not_ICMP would work for you as a setting for the port.

Also I do not use reject at all, but drop. It would simply reduce the risk for some attacks, that check if someone answers. And a reject is an answer, a drop is simply no answer to the client.

Yes, I do not use this. But I wanted to get something posted. I tested it too so if someone used it there should no issue. I will test more but not post before I do. We will help Volker get it right but let him stay on .5 for now. I think somehow these rules above help some to learn before we get too simple. My OMv's are behind a hardware firewall. This just adds a layer. In webmin all you have to do at end of rules is add a rule reject with defaults on all the parameters. It can't get any simpler then that.

Zitat von "tekkbebe"

At first we did not have the drop command. The only difference between drop and reject all is that reject all will send an error message "connection refused". Drop will not send any error messages.

Zitat von "SerErris"

Also I do not use reject at all, but drop. It would simply reduce the risk for some attacks, that check if someone answers. And a reject is an answer, a drop is simply no answer to the client.

I agree Ser. On a home network already behind a hardware firewall I want to get a message. People have to learn and make their own decisions.