From: Lonnie A. <li...@lo...> - 2019-09-17 14:04:27
|
Hi Michael, Thanks for the detailed description. I think your over estimating the complexity of maintaining iptables custom rules for local WireGuard traffic (per custom_wg_lan_input() in another email). It really is not that difficult considering only a very small subset of iptables syntax is required. From how I understand your setup, you have a structured WireGuard mesh of clients, which not all should be allowed to access the server's internals within the WireGuard mesh. This is a somewhat unique setup, but possibly will become more common. As such we need to first understand what firewalling is required ... specifically rules limiting local WireGuard traffic. That is why I suggest you start with custom rules to solve your problem, at least at first. If you find that your custom rules limiting local WireGuard traffic need constant maintenance, note we already have an AIF wireguard-vpn plugin which is automatically enabled and the plugin configuration is passed via the "WireGuard VPN Configuration" sub-tab. The "Firewall Options:" are passed to the wireguard-vpn plugin. ... or If the uniqueness of this problem does not justify cluttering-up the "WireGuard VPN Configuration", new AIF wireguard-vpn plugin config variable options could be added and edited as how other "Firewall Plugins:" are configured. Possibly something like: -- # Limit WireGuard WG->Local access # # Note: The default policy is to allow all WG->Local traffic # unless WIREGUARD_VPN_HOST_OPEN_xxx is defined, then # the default policy is to deny all WG->Local traffic. # # Syntax: # "host1,host2~port1,port2 host3,host4~port3,port4 ..." # # Example: (allow SSH traffic, deny all other) # WIREGUARD_VPN_HOST_OPEN_TCP="0/0~22" # # Example: (deny HTTP/HTTPS traffic, allow all other) # WIREGUARD_VPN_HOST_DENY_TCP="0/0~80,443" # ------------------------------------------------------------------------------ WIREGUARD_VPN_HOST_OPEN_TCP="" WIREGUARD_VPN_HOST_OPEN_UDP="" WIREGUARD_VPN_HOST_DENY_TCP="" WIREGUARD_VPN_HOST_DENY_UDP="" -- Personally I find using a custom rule just as simple, but that is me. Lonnie > On Sep 16, 2019, at 6:27 PM, Michael Knill <mic...@ip...> wrote: > > Hi Devs > > Just wondering if I could have a bit of a discussion about the Astlinux firewall and the firewall configuration. > > With the recent increase in hacking attempts that I am seeing on my systems, I'm having to get more serious about security and I'm finding that the firewall tab and resulting iptables rules are not quite as granular as I would like. As I am planning on changing my architecture to being VPN based, this was highlighted recently with the need to add custom rules for VPN’s. > > Now yes I agree that it would be good to learn iptables and adding custom rules but this will be a considerable learning curve for me and certainly my support staff. > > So I'm just wondering if there has been or could be a consideration to extend the granularity of the current firewall tab? > Here are some of my thoughts: > • Could we add an additional Zone called VPN > • Could we separate the Rules Action into three parts: Action (NAT, Pass, Deny etc), Source Zone (EXT, LAN, DMZ, VPN) & Destination Zone (EXT, LAN, DMZ, VPN, Local) > • Could we pull out some of the Firewall options and create some default Zone to Zone rules > • Maybe look at building out the use of netset rules for Geoblocking etc. > > I'm beginning to have a few partners concerned about the security of Astlinux and its going to be more and more difficult to defend as time goes on. I know that Astlinux has the functionality and tools available to meet most security requirements however they just need to be more accessible to the average network person such as myself. I really don't want to get to the stage where I am putting a firewall in front of the system purely to appease my partners or customers or because its easier. > > Yes there is probably quite a bit of work here and some big changes but as I have invested heavily into Astlinux being the core of my business, I'm prepared to contribute financially if necessary. > > I apologise if I have stirred up a hornets nest as it was certainly not my intention. It is the fact that I believe heavily in this product (and so have many of my partners that are now recommending us) that I am looking to the future of where it is heading. > > I look forward to your comments. > > Regards > Michael Knill > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |