From: Lonnie A. <li...@lo...> - 2019-09-17 22:10:54
|
Michael, OK, I'll add the new AIF wireguard-vpn plugin config variables outlined below. Others might find them useful as well. Give me a day or two. Lonnie > On Sep 17, 2019, at 4:56 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie > > Yes maybe I am overestimating the complexity and it should be a set and forget in most instances e.g. SSH port, 5060 and RTP ports. > That being said however, I am certainly interested in your plugin option below as an alternative to custom rules as I begin to use Wireguard more and more often. > > Thanks again. > > Regards > Michael Knill > > On 18/9/19, 12:04 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > 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 > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |