Simple (easy to manage) Firewall / Virtual Server Zeroshell

Home Page Forums Network Management ZeroShell Simple (easy to manage) Firewall / Virtual Server Zeroshell

This topic contains 9 replies, has 0 voices, and was last updated by  jeffrhysjones 8 years, 2 months ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #41757

    We have a customer that has a server they want to use for as public access development server in the office. The dev server has quite a few ports on it – they are changing them all the time.

    So eth0 is from the internet, and eth1 thru eth3 are all internal LANs that contain dev servers.

    There is no need to have firewall rules between the internal LANs, as they all basically are in the same security zone.

    The problem is the external interface.

    As default, ZS ships with the firewall default policy allow for input, forward, output chains.

    Now the first thing I normally do is to change all these to deny, and then write specific accept rules. Then I create the Virtual Server port forward rules.

    However – for this customer, who would like to map virtual server ports from the external interface to servers on other LANs – I can see this is going to be a huge headache. They are needing to change ports for certain applications quite regularly, and I am worried it is going to be support heavy. I can teach them virtual server port (adding / removing) but not the firewall also – they would just muck that up.

    Each time they want a new port mapped – they would have to delete the virtual server mapping, and then change the firewall rules, then add the new virtual server mapping. It’s just going to be a nightmare.

    The problem is that if I set default ‘DENY’ for all chains, none of the virtual server port forwards work. I need to create firewall rules for all of these – this is sort of double entry. The same if I change virtual server maps.

    What I would really like is to have some simple way – where I could – on eth0 – set the firewall to ‘DENY’ everything, all apart from stuff specified in the Virtual Server settings.

    In this way, the box will block everything – apart from Virtual Server traffic.

    So I just have to teach this guy how to add / remove virtual servers – and nothing else!

    Wouldn’t that be much simpler?

    Is this possible with ZS?

    Jeff

    #48343

    Just thought I would ask around for any update on this request before the thread falls of the edge of the forum.

    I have used a number of other firewalls before that behave like this:

    1) Default block all ‘in’ allow all ‘out’
    2) Add NAT port forward rule in NAT section of config
    3) Packet filter rule is created automatically
    4) Packet filter rule is changed
    5) Corresponding NAT rule is updated

    So basically, when you add/change 100 NAT port forwards, you don’t then have to go and add/change 100 packet filter firewall entries.

    It would be nice if there was a way to make ZS work like this.

    J

    #48344

    zevlag
    Member

    I agree. It would be. I bet you could write a simple shell script to do it. And then give your client ssh access to do the update.

    #48345

    I’m glad I’m not the only one wanting this!

    So are you suggesting a script that creates packet filter rules from virtual server rules? Run each time you add / remove a virtual server ( you can’t edit virtual servers)?

    Perhaps this would write filter rules to a special ‘virtualserver’ chain, that way it would not interfere with all other rules / chains?

    For hosting setups this would alsosave huge amounts of time.

    I feel a bounty coming on!

    Any takers?

    #48346

    zevlag
    Member

    I could do this.

    How much of a bounty is it worth to you?

    #48347

    First can I just clarify how we can work this – just so I know it’s going to do the job? Perhaps there could be some other good suggestions?

    Auto VServer FW Rule Script

    GOAL: To create a script which would effectively auto generate corresponding firewall rules from Zero Shell port forwarding Virtual Server rules.

    Currently with Zeroshell, firewall rules need to be added separately when each virtual server (NAT) rule is created. Because of this – if a Zero Shell administrator is dealing with a situation where there are 100’s of Virtual Server rules, or a customer that is not confident to generate and manage their own firewall rules – there is a lot of duplicated work to do, plus lots of opportunity for mistakes to cause problems.

    Auto generating FW rules would remove a significant amount of work, and thus – this is the goal of this script.

    We have split the script in to three phases. SETUP, IMPLEMENTATION and TEST & SET.

    SETUP PHASE

    1) Setup Script runs from command line (of course GUI would be a bonus)

    2) Script looks for a chain called ‘vserver’ if not exist, creates it. Default policy on this chain is ALLOW all.

    3) Script creates new rules for INPUT, FORWARD and sets all traffic from ETH0 to be filtered by our new vserver chain.

    4) If INPUT & FORWARD have default rule as ACCEPT, these are changed to DENY.

    All traffic should now be filtered by the new vserver chain, which we set to ALLOW all – so everything should still work. The firewall is still effectively disabled at this point. Setup is complete.

    IMPLEMENTATION PHASE

    5) Script then examines all vserver entries and creates firewall rules for them, placing these into the ‘vserver’ chain.

    6) After the final vserver generated rule, there needs to be a way to send any traffic that does not match the generated rules someplace else so it can be ‘post processed’ (another chain?) this is also set to default ACCEPT.

    7) Now we have all our rules in place, none of them are actually ‘active’ because we have default ‘ACCEPT’ policies set.

    User should be able to manually view all firewall rules in the vserver chain, and double check them. Implementation completed.

    TEST & SET PHASE

    8) A separate ‘test & set’ script is run which basically changes the default ACCEPT policies for vserver and post process chains to DENY. After 30 secs this script reverts vserver default policies back to ‘ACCEPT’ and presents the user with an option to ‘apply changes’ (permanent) or ‘retest’.

    Would it also be possible to turn the script around and automatically create rules for going the other way? So from the vserver to ETH0? In which case would be be talking about generating & populating two chains – vserver_in & vserver_out?

    I always thought the ‘RELATED’ filter option was supposed to get around this (as ZS is statefull) but this doesn’t seem to work. If you have an ‘internal’ web server on 192.168.0.5, and you want an outside web client to connect to it via the ZS ETH0 IP of 99.22.33.1 – you first need to create a rule allowing port 80 from ETH0 to the web server, but you also need to create a rule allowing traffic to pass from the webserver, back to the client.

    I thought ‘RELATED’ did away with the need to do this – for some reason, you have to create rules going the other way also.

    Anyway – how does this spec look? Reasonable? Possible? Useful!?

    Jeff

    #48348

    zevlag
    Member

    Jeff,

    This looks very possible.

    I think best would be probably to leave the functionality of zeroshell pretty much as it is, as such we would just add a chain that gets processed after any rules added via ZS firewall manager, for VSERVERS. That way, you can still do administration and, override of vserver rules if desired.

    I will also make some of the requirements you’ve listed optional via a config section at the top of the script, (ie chain POLICY) that way this script would be more reusable by the community.

    I would want to discuss some of the specifics with you. ie. I don’t have the problem you do with having to create rules for return traffic, but with the possibility to vary iptables rules so much, that could be just a rules difference.

    I want the output of this command on your current live box.

    echo FILTER; iptables -L -v -t filter; echo NAT; iptables -L -v -t nat; echo MANGLE; iptables -L -v -t mangle; 

    You can PM this to me if you’d like.

    #48349

    Fantastic – by the way – with regards to the bounty – is Paypal OK? Plus – preferred currency?

    Also I think it’s right that I send Fulvio a little something also as perhaps he might want to look over this and that’s his time if he chooses to do that. If not, well he deserves it anyway!

    I will get the output stuff. I will set up a clean system again just to make sure I’ve not screwed something up on one box.

    Cheers,

    Jeff

    #48350

    zevlag
    Member

    Paypal is great, preferred currency is US Dollars.

    Are you ok with me releasing all code under GPL?

    #48351

    OK I have recreated a ZS ‘simple basic’ setup:

    INPUT – DEFAULT: DENY

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp dpt:443

    OUTPUT – DEFAULT: DENY

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp spt:443

    FORWARD – DEFAULT: DENY

    (No rules)

    So (as far as I am aware!) this is a simple setup where you allow management of the box from any interface via HTTPS, and everything else is blocked, even if you have added in a Virtual Server.

    In my example here, the external interface is ETH0 – network 192.168.0.0

    I now want to add a virtual server, the physical (REAL) server for which is on ETH1 – network 192.168.254.0. I want to be able to remote desktop in to this server from ETH0.

    So first of all I create a virtual server:

    INTERFACE/IP: ETH0 / 192.168.0.252
    PROTOCOL: TCP
    LOCAL PORT: 3389
    REAL SERVER: 192.168.254.2:3389

    Great this is added – however, I can not get through. The reason for this is that I have still to create a rule through the firewall for this Virtual Server to work. If I had 100 Virtual Servers, then I need to create 100 rules. Actually, I have to create 200 rules, as you will see.

    So rather than to mess up FORWARD with all my virtual server rules, I create a new chain called vserver.

    Next I make sure that all forwarding traffic goes to this (I’m not using this box for anything else)

    FORWARD – DEFAULT: DENY

    vserver all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0

    This sends everything to chain vserver.

    Now I create my rule in vserver:

    VSERVER

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 192.168.254.2 state NEW,RELATED,ESTABLISHED tcp dpt:3389

    I do this… try to connect, and nothing. I use a packet sniffer, and notice that for some reason packets are not coming back through the firewall, even though, as we are using STATE, they should be related.

    The only way I can get remote desktop to work, is to create a second rule, allowing traffic from the server out again:

    ACCEPT tcp opt — in * out * 192.168.254.2 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp spt:3389

    So my final vserver chain now looks like this:

    VSERVER

    ACCEPT tcp opt — in * out * 0.0.0.0/0 -> 192.168.254.2 state NEW,RELATED,ESTABLISHED tcp dpt:3389

    ACCEPT tcp opt — in * out * 192.168.254.2 -> 0.0.0.0/0 state NEW,RELATED,ESTABLISHED tcp spt:3389

    Thus – this example shows that when you create a vserver rule, not only do you also have to create an additional rule for it in the firewall, but you actually have to add TWO.

    For people with 100’s of virtual servers (in a hosting environment) this is a huge resource drain, and makes life extremely complicated.

    We are now hoping to create a script which will ‘read’ vserver rules and create both sets of firewall rules for them in a special chain called vserver, as in the above example. This will save a huge amount of time/work.

    Jeff

    #48352

    DoubleD
    Member

    Hi, sorry to bump a thread as old as this, but i was wondering if this feature was created in the end :roll:. It clearly didn’t make it into any release of Zeroshell but perhaps i can download it somewhere and insert it manually?

    I’m very interested in this feature 😯

    Thanks in advance!

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.