You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
219 lines
13 KiB
219 lines
13 KiB
= Iptables !
|
|
Apostolos rootApostolos@swarmlab.io
|
|
// Metadata:
|
|
:description: Intro and Install
|
|
:keywords: sec, tcpdump
|
|
:data-uri:
|
|
:toc: right
|
|
:toc-title: Πίνακας περιεχομένων
|
|
:toclevels: 4
|
|
:source-highlighter: highlight
|
|
:icons: font
|
|
:sectnums:
|
|
|
|
include::header.adoc[]
|
|
|
|
|
|
{empty} +
|
|
|
|
|
|
[[cheat-Docker]]
|
|
== Install swarmlab-sec (Home PC)
|
|
|
|
HowTo: See http://docs.swarmlab.io/lab/sec/sec.adoc.html
|
|
|
|
|
|
.NOTE
|
|
[NOTE]
|
|
====
|
|
Assuming you're already logged in
|
|
====
|
|
|
|
|
|
|
|
== iptables
|
|
|
|
|
|
**iptables** is a command line utility for configuring Linux kernel **firewall** implemented within the https://en.wikipedia.org/wiki/Netfilter[Netfilter] project. The term ''iptables'' is also commonly used to refer to this kernel-level firewall. It can be configured directly with iptables, or by using one of the many
|
|
|
|
https://en.wikipedia.org/wiki/Iptables[More: wikipedia]
|
|
|
|
- Console tools
|
|
|
|
and
|
|
|
|
- Graphical front-ends.
|
|
|
|
''iptables'' is used for https://en.wikipedia.org/wiki/IPv4[IPv4] and ''ip6tables'' is used for ihttps://en.wikipedia.org/wiki/IPv6[IPv6]. Both ''iptables'' and ''ip6tables'' have the same syntax, but some options are specific to either IPv4 or IPv6.
|
|
|
|
|
|
=== Installation
|
|
|
|
The Swarmlab.io kernel is compiled with iptables support.
|
|
|
|
|
|
=== Front-ends
|
|
|
|
==== Console
|
|
|
|
- Shorewall, High-level tool for configuring Netfilter.
|
|
|
|
You describe your firewall/gateway requirements using entries in a set of configuration files.
|
|
|
|
http://www.shorewall.net/[shorewall]
|
|
|
|
- Arno's Secure firewall for both single and multi-homed machines.
|
|
|
|
Very easy to configure, handy to manage and highly customizable. Supports: NAT and SNAT, port forwarding, ADSL ethernet modems with both static and dynamically assigned IPs, MAC address filtering, stealth port scan detection, DMZ and DMZ-2-LAN forwarding, protection against SYN/ICMP flooding, extensive user definable logging with rate limiting to prevent log flooding, all IP protocols and VPNs such as IPsec, plugin support to add extra features.|
|
|
|
|
http://rocky.eld.leidenuniv.nl/[arno-iptables-firewall]
|
|
|
|
- FireHOL Language to express firewalling rules, not just a script that produces some kind of a firewall. It makes building even sophisticated firewalls easy - the way you want it.
|
|
|
|
http://firehol.sourceforge.net
|
|
|
|
- firewalld (firewall-cmd) Daemon and console interface for configuring network and firewall zones as well as setting up and configuring firewall rules.
|
|
|
|
https://firewalld.org[firewalld]
|
|
|
|
==== Graphical
|
|
|
|
* {{App|Firewall Builder|GUI firewall configuration and management tool that supports iptables (netfilter), ipfilter, pf, ipfw, Cisco PIX (FWSM, ASA) and Cisco routers extended access lists. The program runs on Linux, FreeBSD, OpenBSD, Windows and macOS and can manage both local and remote firewalls.|http://fwbuilder.sourceforge.net/|{{Pkg|fwbuilder}}}}
|
|
* {{App|[[Wikipedia:firewalld|firewalld]] (firewall-config)|Daemon and graphical interface for configuring network and firewall zones as well as setting up and configuring firewall rules.|https://firewalld.org/|{{Pkg|firewalld}}}}
|
|
* {{App|[[Uncomplicated_Firewall#Gufw|Gufw]]|GTK-based front-end to {{Pkg|ufw}} which happens to be a CLI front-end to iptables (gufw->ufw->iptables), is super easy and super simple to use.|https://gufw.org/|{{Pkg|gufw}}}}
|
|
* {{App|[[PeerGuardian Linux|PeerGuardian]] GUI (pglgui)|Privacy oriented firewall application. It blocks connections to and from hosts specified in huge block lists (thousands or millions of IP ranges).|https://sourceforge.net/projects/peerguardian/|{{AUR|pgl}}}}
|
|
* {{App|FireStarter|High-level GUI Iptables firewall for Linux systems|http://www.fs-security.com/|{{AUR|firestarter}}}}
|
|
|
|
== Basic concepts
|
|
|
|
iptables is used to inspect, modify, forward, redirect, and/or drop IP packets. The code for filtering IP packets is already built into the kernel and is organized into a collection of ''tables'', each with a specific purpose. The tables are made up of a set of predefined ''chains'', and the chains contain rules which are traversed in order. Each rule consists of a predicate of potential matches and a corresponding action (called a ''target'') which is executed if the predicate is true; i.e. the conditions are matched. If the IP packet reaches the end of a built-in chain, including an empty chain, then the chain's ''policy'' target determines the final destination of the IP packet. iptables is the user utility which allows you to work with these chains/rules. Most new users find the complexities of linux IP routing quite daunting, but, in practice, the most common use cases (NAT and/or basic Internet firewall) are considerably less complex.
|
|
|
|
The key to understanding how iptables works is [https://www.frozentux.net/iptables-tutorial/images/tables_traverse.jpg this chart]. The lowercase word on top is the table and the upper case word below is the chain. Every IP packet that comes in ''on any network interface'' passes through this flow chart from top to bottom. A common source of confusion is that packets entering from, say, an internal interface are handled differently than packets from an Internet-facing interface. All interfaces are handled the same way; it's up to you to define rules that treat them differently. Of course some packets are intended for local processes, hence come in from the top of the chart and stop at <Local Process>, while other packets are generated by local processes; hence start at <Local Process> and proceed downward through the flowchart. A detailed explanation of how this flow chart works can be found [https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES here].
|
|
|
|
In the vast majority of use cases you won't need to use the '''raw''', '''mangle''', or '''security''' tables at all. Consequently, the following chart depicts a simplified network packet flow through ''iptables'':
|
|
|
|
[source,bash]
|
|
----
|
|
|
|
XXXXXXXXXXXXXXXXXX
|
|
XXX Network XXX
|
|
XXXXXXXXXXXXXXXXXX
|
|
+
|
|
|
|
|
v
|
|
+-------------+ +------------------+
|
|
|table: filter| <---+ | table: nat |
|
|
|chain: INPUT | | | chain: PREROUTING|
|
|
+-----+-------+ | +--------+---------+
|
|
| | |
|
|
v | v
|
|
[local process] | **************** +--------------+
|
|
| +---------+ Routing decision +------> |table: filter |
|
|
v **************** |chain: FORWARD|
|
|
**************** +------+-------+
|
|
Routing decision |
|
|
**************** |
|
|
| |
|
|
v **************** |
|
|
+-------------+ +------> Routing decision <---------------+
|
|
|table: nat | | ****************
|
|
|chain: OUTPUT| | +
|
|
+-----+-------+ | |
|
|
| | v
|
|
v | +-------------------+
|
|
+--------------+ | | table: nat |
|
|
|table: filter | +----+ | chain: POSTROUTING|
|
|
|chain: OUTPUT | +--------+----------+
|
|
+--------------+ |
|
|
v
|
|
XXXXXXXXXXXXXXXXXX
|
|
XXX Network XXX
|
|
XXXXXXXXXXXXXXXXXX
|
|
----
|
|
|
|
=== Table
|
|
|
|
iptables contains five tables:
|
|
|
|
# {{ic|raw}} is used only for configuring packets so that they are exempt from connection tracking.
|
|
# {{ic|filter}} is the default table, and is where all the actions typically associated with a firewall take place.
|
|
# {{ic|nat}} is used for [[Wikipedia:Network address translation|network address translation]] (e.g. port forwarding).
|
|
# {{ic|mangle}} is used for specialized packet alterations.
|
|
# {{ic|security}} is used for [[Mandatory Access Control]] networking rules (e.g. SELinux -- see [http://lwn.net/Articles/267140/ this article] for more details).
|
|
|
|
In most common use cases you will only use two of these: '''filter''' and '''nat'''. The other tables are aimed at complex configurations involving multiple routers and routing decisions and are in any case beyond the scope of these introductory remarks.
|
|
|
|
=== Chains
|
|
|
|
Tables consist of ''chains'', which are lists of rules which are followed in order. The default table, {{ic|filter}}, contains three built-in chains: {{ic|INPUT}}, {{ic|OUTPUT}} and {{ic|FORWARD}} which are activated at different points of the packet filtering process, as illustrated in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg flow chart]. The nat table includes {{ic|PREROUTING}}, {{ic|POSTROUTING}}, and {{ic|OUTPUT}} chains.
|
|
|
|
See {{man|8|iptables}} for a description of built-in chains in other tables.
|
|
|
|
By default, none of the chains contain any rules. It is up to you to append rules to the chains that you want to use. Chains ''do'' have a default policy, which is generally set to {{ic|ACCEPT}}, but can be reset to {{ic|DROP}}, if you want to be sure that nothing slips through your ruleset. The default policy always applies at the end of a chain only. Hence, the packet has to pass through all existing rules in the chain before the default policy is applied.
|
|
|
|
User-defined chains can be added to make rulesets more efficient or more easily modifiable. See [[Simple stateful firewall]] for an example of how user-defined chains are used.
|
|
|
|
=== Rules
|
|
|
|
Packet filtering is based on ''rules'', which are specified by multiple ''matches'' (conditions the packet must satisfy so that the rule can be applied), and one ''target'' (action taken when the packet matches all conditions). The typical things a rule might match on are what interface the packet came in on (e.g eth0 or eth1), what type of packet it is (ICMP, TCP, or UDP), or the destination port of the packet.
|
|
|
|
Targets are specified using the {{ic|-j}} or {{ic|--jump}} option. Targets can be either user-defined chains (i.e. if these conditions are matched, jump to the following user-defined chain and continue processing there), one of the special built-in targets, or a target extension. Built-in targets are {{ic|ACCEPT}}, {{ic|DROP}}, {{ic|QUEUE}} and {{ic|RETURN}}, target extensions are, for example, {{ic|REJECT}} and {{ic|LOG}}. If the target is a built-in target, the fate of the packet is decided immediately and processing of the packet in current table is stopped. If the target is a user-defined chain and the fate of the packet is not decided by this second chain, it will be filtered against the remaining rules of the original chain. Target extensions can be either ''terminating'' (as built-in targets) or ''non-terminating'' (as user-defined chains), see {{man|8|iptables-extensions}} for details.
|
|
|
|
=== Traversing Chains
|
|
|
|
A network packet received on any interface traverses the traffic control chains of tables in the order shown in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg flow chart]. The first routing decision involves deciding if the final destination of the packet is the local machine (in which case the packet traverses through the {{ic|INPUT}} chains) or elsewhere (in which case the packet traverses through the {{ic|FORWARD}} chains). Subsequent routing decisions involve deciding what interface to assign to an outgoing packet. At each chain in the path, every rule in that chain is evaluated in order and whenever a rule matches, the corresponding target/jump action is executed. The 3 most commonly used targets are {{ic|ACCEPT}}, {{ic|DROP}}, and jump to a user-defined chain. While built-in chains can have default policies, user-defined chains can not. If every rule in a chain that you jumped fails to provide a complete match, the packet is dropped back into the calling chain as illustrated [http://www.frozentux.net/iptables-tutorial/images/table_subtraverse.jpg here]. If at any time a complete match is achieved for a rule with a {{ic|DROP}} target, the packet is dropped and no further processing is done. If a packet is {{ic|ACCEPT}}ed within a chain, it will be {{ic|ACCEPT}}ed in all superset chains also and it will not traverse any of the superset chains any further. However, be aware that the packet will continue to traverse all other chains in other tables in the normal fashion.
|
|
|
|
=== Modules
|
|
|
|
There are many modules which can be used to extend iptables such as connlimit, conntrack, limit and recent. These modules add extra functionality to allow complex filtering rules.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[appendix]
|
|
== How to use tcpdump
|
|
|
|
|
|
This exercise will show you how to isolate traffic in various ways—from IP, to port, to protocol, to application-layer traffic—to make sure you find exactly what you need as quickly as possible.
|
|
|
|
https://danielmiessler.com/study/tcpdump[Origin]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
:hardbreaks:
|
|
|
|
{empty} +
|
|
{empty} +
|
|
{empty}
|
|
|
|
:!hardbreaks:
|
|
|
|
'''
|
|
|
|
.Reminder
|
|
[NOTE]
|
|
====
|
|
:hardbreaks:
|
|
Caminante, no hay camino,
|
|
se hace camino al andar.
|
|
|
|
Wanderer, there is no path,
|
|
the path is made by walking.
|
|
|
|
*Antonio Machado* Campos de Castilla
|
|
====
|
|
|