Zero-To-Awall: Difference between revisions

From Alpine Linux
Line 15: Line 15:
Since recent versions of awall it is also possible to use yaml instead of json but this is out of the scope of this howto.
Since recent versions of awall it is also possible to use yaml instead of json but this is out of the scope of this howto.


== Creating base ==
== Creating the base ==


Creating zones depends on the function of your firewall. Is it installed on a endpoint (server) or will it act as a router and filter/forward.
Creating zones depends on the function of your firewall. Is it installed on a endpoint (server) or will it act as a router and filter/forward.

Revision as of 22:20, 2 October 2017

Awall howto for dummies

This howto is aimed at users with no (or little) experience with iptables and other firewall frameworks (like Shorewall).

This howto is going to be split into 4 parts.

  1. Defining our base json file which holds our zones and base policies.
  2. Creating service policies.
  3. Using aliases and custom services.
  4. enabling and testing policies.

NOTE: please be aware that all configuration files are stored as JSON files. JSON is not a human friendly standard, for instance it does not support comments so you will have to move them outside of the json structure. Beginners should use a decent text editor with JSON highlight support which will make your life easier. Since recent versions of awall it is also possible to use yaml instead of json but this is out of the scope of this howto.

Creating the base

Creating zones depends on the function of your firewall. Is it installed on a endpoint (server) or will it act as a router and filter/forward. For this howto we assume you are going to setup a router and use NAT to forward services (ports) to different hosts on your network.

For each interface on router we will setup a zone and assign it a zone name. We do this by creating the following file: /etc/awall/private/base.json

{
  "description": "Base zones and policies",

  "zone": {
    "WAN": { "iface": "eth0" },
    "LAN": { "iface": "eth1" },
    "VPN": { "iface": "tun+" }
  },

  "policy": [
     { "in": "VPN", "action": "accept" },
     { "out": "VPN", "action": "accept" },
     { "in": "LAN", "action": "accept" },
     { "out": "LAN", "action": "accept" },
     { "in": "_fw", "action": "accept" },
     { "in": "_fw", "out":  "WAN" , "action": "accept" },
     { "in": "WAN", "action": "drop" }
  ],

  "snat": [ { "out": "WAN" } ],

  "clamp-mss": [ { "out": "WAN" } ]

}

Lets break this down into sections

description

The description is here just for reference and will be used by awall list.

zone

This is where our zones are defined. Zones are defined based on a interface and assigned a name to be used in your policies. In our example you can see that we have two real interfaces eth0 and eth1 and one or more virtual interfaces tun+ (the plus sign stands for any digit like tun0 tun1 and so on). In case you are installing awall on an endpoint (a server) then you will most probably not have the eth1 interfaces and can leave it out.

policy

These are our main policies. It will tell our firewall what to do with when a packet enters or leaves on of the zones (interfaces). You will notice a special _fw name which means the internal firewall itself (the local machine) which means the packet does not leave the firewall via another interface but should use one of the local services.

snat

Apply source nat for outgoing packets. This is only needed if your firewall acts as a router and traffic behind the router needs a modified source address (translate from local ip to public ip).

clamp-mss

https://github.com/alpinelinux/awall#mss-clamping-rules