]> git.proxmox.com Git - pve-docs.git/blobdiff - pve-firewall.adoc
fixup: s/devies/devices/
[pve-docs.git] / pve-firewall.adoc
index 154c907db1ef82c32cfb6f54c07fca8fc9e78789..07813344860213b086ee43b619e1ab44ddfefcc2 100644 (file)
@@ -1,7 +1,8 @@
+[[chapter_pve_firewall]]
 ifdef::manvolnum[]
-PVE({manvolnum})
-================
-include::attributes.txt[]
+pve-firewall(8)
+===============
+:pve-toplevel:
 
 NAME
 ----
@@ -9,7 +10,7 @@ NAME
 pve-firewall - PVE Firewall Daemon
 
 
-SYNOPSYS
+SYNOPSIS
 --------
 
 include::pve-firewall.8-synopsis.adoc[]
@@ -18,21 +19,23 @@ include::pve-firewall.8-synopsis.adoc[]
 DESCRIPTION
 -----------
 endif::manvolnum[]
-
 ifndef::manvolnum[]
 {pve} Firewall
 ==============
-include::attributes.txt[]
+:pve-toplevel:
 endif::manvolnum[]
+ifdef::wiki[]
+:title: Firewall
+endif::wiki[]
 
-Proxmox VE Firewall provides an easy way to protect your IT
+{pve} Firewall provides an easy way to protect your IT
 infrastructure. You can setup firewall rules for all hosts
 inside a cluster, or define rules for virtual machines and
 containers. Features like firewall macros, security groups, IP sets
-and aliases helps to make that task easier.
+and aliases help to make that task easier.
 
 While all configuration is stored on the cluster file system, the
-`iptables`-based firewall runs on each cluster node, and thus provides
+`iptables`-based firewall service runs on each cluster node, and thus provides
 full isolation between virtual machines. The distributed nature of
 this system also provides much higher bandwidth than a central
 firewall solution.
@@ -67,16 +70,17 @@ file system. So those files are automatically distributed to all
 cluster nodes, and the `pve-firewall` service updates the underlying
 `iptables` rules automatically on changes.
 
-You can configure anything using the GUI (i.e. Datacenter -> Firewall,
-or on a Node -> Firewall), or you can edit the configuration files
+You can configure anything using the GUI (i.e. *Datacenter* -> *Firewall*,
+or on a *Node* -> *Firewall*), or you can edit the configuration files
 directly using your preferred editor.
 
-Firewall configuration files contains sections of key-value
+Firewall configuration files contain sections of key-value
 pairs. Lines beginning with a `#` and blank lines are considered
-comments. Sections starts with a header line containing the section
+comments. Sections start with a header line containing the section
 name enclosed in `[` and `]`.
 
 
+[[pve_firewall_cluster_wide_setup]]
 Cluster Wide Setup
 ~~~~~~~~~~~~~~~~~~
 
@@ -139,7 +143,8 @@ To simplify that task, you can instead create an IPSet called
 firewall rules to access the GUI from remote.
 
 
-Host specific Configuration
+[[pve_firewall_host_specific_configuration]]
+Host Specific Configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Host related configuration is read from:
@@ -160,8 +165,8 @@ include::pve-firewall-host-opts.adoc[]
 
 This sections contains host specific firewall rules.
 
-
-VM/Container configuration
+[[pve_firewall_vm_container_configuration]]
+VM/Container Configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 VM firewall configuration is read from:
@@ -196,10 +201,6 @@ Each virtual network device has its own firewall enable flag. So you
 can selectively enable the firewall for each interface. This is
 required in addition to the general firewall `enable` option.
 
-The firewall requires a special network device setup, so you need to
-restart the VM/container after enabling the firewall on a network
-interface.
-
 
 Firewall Rules
 --------------
@@ -230,8 +231,8 @@ Here are some examples:
 IN SSH(ACCEPT) -i net0
 IN SSH(ACCEPT) -i net0 # a comment
 IN SSH(ACCEPT) -i net0 -source 192.168.2.192 # only allow SSH from 192.168.2.192
-IN SSH(ACCEPT) -i net0 -source 10.0.0.1-10.0.0.10 # accept SSH for ip range
-IN SSH(ACCEPT) -i net0 -source 10.0.0.1,10.0.0.2,10.0.0.3 #accept ssh for ip list
+IN SSH(ACCEPT) -i net0 -source 10.0.0.1-10.0.0.10 # accept SSH for IP range
+IN SSH(ACCEPT) -i net0 -source 10.0.0.1,10.0.0.2,10.0.0.3 #accept ssh for IP list
 IN SSH(ACCEPT) -i net0 -source +mynetgroup # accept ssh for ipset mynetgroup
 IN SSH(ACCEPT) -i net0 -source myserveralias #accept ssh for alias myserveralias
 
@@ -242,6 +243,7 @@ OUT ACCEPT # accept all outgoing packages
 ----
 
 
+[[pve_firewall_security_groups]]
 Security Groups
 ---------------
 
@@ -266,7 +268,7 @@ Then, you can add this group to a VM's firewall
 GROUP webserver
 ----
 
-
+[[pve_firewall_ip_aliases]]
 IP Aliases
 ----------
 
@@ -276,7 +278,8 @@ name. You can then refer to those names:
 * inside IP set definitions
 * in `source` and `dest` properties of firewall rules
 
-Standard IP alias `local_network`
+
+Standard IP Alias `local_network`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This alias is automatically defined. Please use the following command
@@ -300,9 +303,10 @@ explicitly assign the local IP address
 ----
 #  /etc/pve/firewall/cluster.fw
 [ALIASES]
-local_network 1.2.3.4 # use the single ip address
+local_network 1.2.3.4 # use the single IP address
 ----
 
+[[pve_firewall_ip_sets]]
 IP Sets
 -------
 
@@ -315,11 +319,12 @@ set.
 
  IN HTTP(ACCEPT) -source +management
 
+
 Standard IP set `management`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This IP set applies only to host firewalls (not VM firewalls).  Those
-ips are allowed to do normal management tasks (PVE GUI, VNC, SPICE,
+IPs are allowed to do normal management tasks (PVE GUI, VNC, SPICE,
 SSH).
 
 The local cluster network is automatically added to this IP set (alias
@@ -338,7 +343,7 @@ communication. (multicast,ssh,...)
 Standard IP set `blacklist`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Traffic from these ips is dropped by every host's and VM's firewall.
+Traffic from these IPs is dropped by every host's and VM's firewall.
 
 ----
 # /etc/pve/firewall/cluster.fw
@@ -349,7 +354,7 @@ Traffic from these ips is dropped by every host's and VM's firewall.
 ----
 
 
-[[ipfilter-section]]
+[[pve_firewall_ipfilter_section]]
 Standard IP set `ipfilter-net*`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -359,7 +364,7 @@ with a source IP not matching its interface's corresponding ipfilter set will
 be dropped.
 
 For containers with configured IP addresses these sets, if they exist (or are
-activated via the general `IP Filter` option in the VM's firewall's 'options'
+activated via the general `IP Filter` option in the VM's firewall's *options*
 tab), implicitly contain the associated IP addresses.
 
 For both virtual machines and containers they also implicitly contain the
@@ -399,6 +404,44 @@ If you want to see the generated iptables rules you can use:
 
  # iptables-save
 
+Logging of firewall rules
+-------------------------
+
+By default, logging of traffic filtered by the firewall rules is disabled. To
+enable logging for the default firewall rules, the log-level for incommig and
+outgoing traffic has to be set in the firewall `Options` tab for the host and/or
+the VM/CT firewall.
+Logging of dropped packets is rate limited to 1 packet per second in order to
+reduce output to the log file.
+Further, only some dropped or rejected packets are logged for the standard rules.
+
+// TODO: describe standard/default rules and note which of them get logged
+
+In order to log packets filtered by user-defined firewall rules, it is possible
+to set a log-level parameter for each rule individually.
+This allows to log in a fine grained manner and independent of the log-level
+defined for the standard rules in the firewall `Options`.
+
+The log level for the rule can also be set via the firewall configuration file by
+appending a `-log <loglevel>` to the selected rule.
+Here, `<loglevel>` is one of the following flags:
+`nolog, emerg, alert, crit, err, warning, notice, info, debug`
+
+For example, the following two are ident:
+
+----
+IN REJECT -p icmp -log nolog
+IN REJECT -p icmp
+----
+
+whereas
+
+----
+IN REJECT -p icmp -log debug
+----
+
+produces a log output flagged with the `debug` level.
+
 
 Tips and Tricks
 ---------------
@@ -455,68 +498,6 @@ NFQUEUE=0
 ----
 
 
-Avoiding `link-local` Addresses on `tap` and `veth` Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-With IPv6 enabled by default every interface gets a MAC-derived link local
-address. However, most devices on a typical {pve} setup are connected to a
-bridge and so the bridge is the only interface which really needs one.
-
-To disable a link local address on an interface you can set the interface's
-`disable_ipv6` sysconf variable. Despite the name, this does not prevent IPv6
-traffic from passing through the interface when routing or bridging, so the
-only noticeable effect will be the removal of the link local address.
-
-The easiest method of achieving this setting for all newly started VMs is to
-set it for the `default` interface configuration and enabling it explicitly on
-the interfaces which need it. This is also the case for other settings such as
-`forwarding`, `accept_ra` or `autoconf`.
-
-Here's a possible setup:
-----
-# /etc/sysconf.d/90-ipv6.conf
-
-net.ipv6.conf.default.forwarding = 0
-net.ipv6.conf.default.proxy_ndp = 0
-net.ipv6.conf.default.autoconf = 0
-net.ipv6.conf.default.disable_ipv6 = 1
-net.ipv6.conf.default.accept_ra = 0
-
-net.ipv6.conf.lo.disable_ipv6 = 0
-----
-
-----
-# /etc/network/interfaces
-(...)
-# Dual stack:
-iface vmbr0 inet static
-    address 1.2.3.4
-    netmask 255.255.255.128
-    gateway 1.2.3.5
-iface vmbr0 inet6 static
-    address fc00::31
-    netmask 16
-    gateway fc00::1
-    accept_ra 0
-    pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6
-
-# With IPv6-only 'pre-up' is too early and 'up' is too late.
-# Work around this by creating the bridge manually
-iface vmbr1 inet manual
-    pre-up ip link add $IFACE type bridge
-    up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6
-iface vmbr1 inet6 static
-    address fc00:b:3::1
-    netmask 96
-    bridge_ports none
-    bridge_stp off
-    bridge_fd 0
-    bridge_vlan_aware yes
-    accept_ra 0
-(...)
-----
-
-
 Notes on IPv6
 -------------
 
@@ -528,10 +509,10 @@ address are used. By default the `NDP` option is enabled on both host and VM
 level to allow neighbor discovery (NDP) packets to be sent and received.
 
 Beside neighbor discovery NDP is also used for a couple of other things, like
-autoconfiguration and advertising routers.
+auto-configuration and advertising routers.
 
 By default VMs are allowed to send out router solicitation messages (to query
-for a router), and to receive router advetisement packets. This allows them to
+for a router), and to receive router advertisement packets. This allows them to
 use stateless auto configuration. On the other hand VMs cannot advertise
 themselves as routers unless the ``Allow Router Advertisement'' (`radv: 1`) option
 is set.
@@ -540,18 +521,18 @@ As for the link local addresses required for NDP, there's also an ``IP Filter''
 (`ipfilter: 1`) option which can be enabled which has the same effect as adding
 an `ipfilter-net*` ipset for each of the VM's network interfaces containing the
 corresponding link local addresses.  (See the
-<<ipfilter-section,Standard IP set `ipfilter-net*`>> section for details.)
+<<pve_firewall_ipfilter_section,Standard IP set `ipfilter-net*`>> section for details.)
 
 
-Ports used by Proxmox VE
-------------------------
+Ports used by {pve}
+-------------------
 
 * Web interface: 8006
 * VNC Web console: 5900-5999
 * SPICE proxy: 3128
 * sshd (used for cluster actions): 22
 * rpcbind: 111
-*  corosync multicast (if you run a cluster): 5404, 5405 UDP
+* corosync multicast (if you run a cluster): 5404, 5405 UDP
 
 
 ifdef::manvolnum[]