@ -0,0 +1,5 @@ |
|||||
|
name: swarmlab_sec-iptables |
||||
|
title: swarmlab_sec-iptables |
||||
|
version: docs |
||||
|
nav: |
||||
|
- modules/ROOT/nav.adoc |
After Width: | Height: | Size: 8.0 KiB |
After Width: | Height: | Size: 80 KiB |
@ -0,0 +1 @@ |
|||||
|
* xref:index.adoc[iptables] |
@ -0,0 +1,217 @@ |
|||||
|
= SSH Tunneling! |
||||
|
|
||||
|
image::ROOT:swarmlab.png[swarmlab,150,float=right] |
||||
|
|
||||
|
This tutorial demonstrates: *a.* howto setup a SSH tunneling *b.* howto use it |
||||
|
|
||||
|
|
||||
|
|
||||
|
***SSH Tunneling***, is the ability to use ssh to create a bi-directional encrypted network connection between machines over which data can be exchanged, typically TCP/IP. |
||||
|
|
||||
|
|
||||
|
|
||||
|
[NOTE] |
||||
|
==== |
||||
|
SSH is a standard for secure remote logins and file transfers over untrusted networks. It also provides a way to secure the data traffic of any given application using port forwarding, basically tunneling any TCP/IP port over SSH. This means that the application data traffic is directed to flow inside an encrypted SSH connection so that it cannot be eavesdropped or intercepted while it is in transit. SSH tunneling enables adding network security to legacy applications that do not natively support encryption. |
||||
|
==== |
||||
|
|
||||
|
image::ROOT:ssh-tunneling-1366x416-WPhEwBvP.png[SSH tunneling] |
||||
|
|
||||
|
== Local Port Forwarding |
||||
|
|
||||
|
|
||||
|
.local port forwarding |
||||
|
[source,bash] |
||||
|
---- |
||||
|
ssh -nNT -L 8000:localhost:3306 user@192.168.89.5 |
||||
|
---- |
||||
|
|
||||
|
The above command sets up an ssh tunnel between your machine and the server, and forwards all traffic from localhost:3306 to localhost:8000 (on your machine). |
||||
|
|
||||
|
So now you could connect to MySQL running on your server via localhost on port 8000 on your machine. |
||||
|
|
||||
|
|
||||
|
== Remote Port Forwarding |
||||
|
|
||||
|
.remote port forwarding |
||||
|
[source,bash] |
||||
|
---- |
||||
|
ssh -nNT -R 4000:localhost:3000 user@192.168.89.5 |
||||
|
---- |
||||
|
|
||||
|
The above command sets up an ssh tunnel between your machine and the server, and forwards all traffic from localhost:3000 (on your machine) to localhost:4000 (in the context of the server). |
||||
|
|
||||
|
So now you can connect to the locally running service on port 3000 on the server on port 4000 |
||||
|
|
||||
|
|
||||
|
== SSH Command |
||||
|
|
||||
|
|
||||
|
Practically every Linux system includes the ssh command. This command is used to start the SSH client program that enables secure connection to the SSH server on a remote machine. The ssh command is used from logging into the remote machine, transferring files between the two machines, and for executing commands on the remote machine. |
||||
|
|
||||
|
|
||||
|
=== Connect to server |
||||
|
|
||||
|
.connect |
||||
|
[source,bash] |
||||
|
---- |
||||
|
ssh user@192.168.89.5 |
||||
|
|
||||
|
The authenticity of host '192.168.89.5' cannot be established. |
||||
|
DSA key fingerprint is 04:48:30:31:b0:f3:5a:9b:01:9d:b3:a7:38:e2:b1:0c. |
||||
|
Are you sure you want to continue connecting (yes/no)? |
||||
|
---- |
||||
|
|
||||
|
Type yes to continue. This will add the server to your list of known hosts (~/.ssh/known_hosts) as seen in the following message: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
Warning: Permanently added '192.168.89.5' (DSA) to the list of known hosts. |
||||
|
---- |
||||
|
|
||||
|
Each server has a host key, and the above question related to verifying and saving the host key, so that next time you connect to the server, it can verify that it actually is the same server. |
||||
|
|
||||
|
|
||||
|
=== Executing remote commands on the server |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
ssh user@192.168.89.5 /bin/bash -c "ls -al" |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
== sshd_config - SSH Server Configuration |
||||
|
|
||||
|
The OpenSSH server reads a configuration file when it is started. Usually this file is /etc/ssh/sshd_config, but the location can be changed using the -f command line option when starting sshd. |
||||
|
|
||||
|
=== Cryptographic policy |
||||
|
|
||||
|
- Symmetric algorithms for encrypting the bulk of transferred data are configured using the Ciphers option. A good value is aes128-ctr,aes192-ctr,aes256-ctr. |
||||
|
|
||||
|
- Host key algorithms are selected by the HostKeyAlgorithms option. A good value is ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss. |
||||
|
|
||||
|
- Key exchange algorithms are selected by the KexAlgorithms option. recommend ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256. |
||||
|
|
||||
|
[NOTE] |
||||
|
==== |
||||
|
not recommend allowing diffie-hellman-group1-sha1, unless needed for compatibility. It uses a 768 bit prime number, which is too small by today's standards and may be breakable by intelligence agencies in real time. Using it could expose connections to man-in-the-middle attacks when faced with such adversaries. |
||||
|
==== |
||||
|
|
||||
|
=== Verbose logging |
||||
|
|
||||
|
It is strongly recommended that LogLevel be set to VERBOSE. This way, the key fingerprint for any SSH key used for login is logged. This information is important for SSH key management, especially in legacy environments. |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
LogLevel VERBOSE |
||||
|
---- |
||||
|
|
||||
|
=== Root login |
||||
|
|
||||
|
root access should generally go through a privileged access management system |
||||
|
|
||||
|
To disable passwords for root, but still allow key-based access without forced command, use: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
PermitRootLogin prohibit-password |
||||
|
---- |
||||
|
|
||||
|
To disable passwords and only allow key-based access with a forced command, use: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
PermitRootLogin forced-commands-only |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
=== Port forwarding |
||||
|
|
||||
|
Generally prevent port forwarding on servers, unless expressly needed for tunneling legacy applications. |
||||
|
There is substantial risk that users will use SSH tunneling to open backdoors into the organization through the firewall to get access to work machines from home. |
||||
|
|
||||
|
|
||||
|
=== Generate a key pair |
||||
|
|
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
ssh-keygen |
||||
|
---- |
||||
|
|
||||
|
Output: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
Generating public/private rsa key pair. |
||||
|
Enter file in which to save the key (/home/user/.ssh/id_rsa): |
||||
|
Created directory '/home/user/.ssh'. |
||||
|
Enter passphrase (empty for no passphrase): |
||||
|
Enter same passphrase again: |
||||
|
Your identification has been saved in /home/user/.ssh/id_rsa. |
||||
|
Your public key has been saved in /home/user/.ssh/id_rsa.pub. |
||||
|
The key fingerprint is: |
||||
|
8c:2a:ed:82:98:6d:12:0a:3a:ba:b2:1c:c0:25:be:5b |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
=== Install your public key |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
sh-copy-id -i ~/.ssh/id_rsa.pub UserName@RemoteServer |
||||
|
---- |
||||
|
|
||||
|
Output: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
UserName@RemoteServer's password: ******** |
||||
|
---- |
||||
|
|
||||
|
Now try logging into the machine, with "ssh 'username@remoteserver'", and check in: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
~/.ssh/authorized_keys |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
== run graphics applications remotely |
||||
|
|
||||
|
X11 forwarding needs to be enabled on both the client side and the server side. |
||||
|
|
||||
|
- On the client side, the -X (capital X) option to ssh enables X11 forwarding |
||||
|
|
||||
|
- On the server side, X11Forwarding yes must specified in /etc/ssh/sshd_config. |
||||
|
|
||||
|
- The xauth program must be installed on the server side. |
||||
|
|
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
ssh -X user@192.168.89.5 gimp |
||||
|
---- |
||||
|
|
||||
|
== Copy Files and Directories Between Two Systems |
||||
|
|
||||
|
=== Copy a file from a local to a remote system |
||||
|
|
||||
|
|
||||
|
To copy a file from a local to a remote system run the following command: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
scp file.txt user@192.168.89.5:/remote/directory |
||||
|
---- |
||||
|
|
||||
|
=== Copy a Remote File to a Local System using the scp ommand |
||||
|
|
||||
|
|
||||
|
To copy a file named file.txt from a remote server with IP 192.168.89.5 run the following command: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
scp user@192.168.89.5:/remote/file.txt /local/directory |
||||
|
---- |
||||
|
|
@ -0,0 +1,4 @@ |
|||||
|
antora --fetch /antora/site.yml |
||||
|
antora /antora/site.yml |
||||
|
ifconfig |
||||
|
http-server build/site -c-1 |
@ -0,0 +1,21 @@ |
|||||
|
site: |
||||
|
title: Swarmlab sec-iptables |
||||
|
url: http://docs.swarmlab.io/SwarmLab-HowTos/swarmlab/docs |
||||
|
start_page: swarmlab_sec-iptables::index.adoc |
||||
|
content: |
||||
|
sources: |
||||
|
- url: https://git.swarmlab.io:3000/docs/Documentation.git |
||||
|
branches: master |
||||
|
start_path: iptables |
||||
|
ui: |
||||
|
bundle: |
||||
|
url: https://git.swarmlab.io:3000/docs/docs/raw/branch/master/ui-bundle.zip |
||||
|
snapshot: true |
||||
|
supplemental_files: ./supplemental-ui |
||||
|
asciidoc: |
||||
|
attributes: |
||||
|
:plantuml-server-url: http://www.plantuml.com/plantuml |
||||
|
extensions: |
||||
|
- '@djencks/asciidoctor-mathjax' |
||||
|
- asciidoctor-plantuml |
||||
|
|
@ -0,0 +1,5 @@ |
|||||
|
name: swarmlab_sec-iptables |
||||
|
title: swarmlab_sec-iptables |
||||
|
version: docs |
||||
|
nav: |
||||
|
- modules/ROOT/nav.adoc |
After Width: | Height: | Size: 8.0 KiB |
After Width: | Height: | Size: 80 KiB |
@ -0,0 +1 @@ |
|||||
|
* xref:index.adoc[iptables] |
@ -0,0 +1,510 @@ |
|||||
|
= Iptables! |
||||
|
|
||||
|
image::ROOT:swarmlab.png[swarmlab,150,float=right] |
||||
|
|
||||
|
This tutorial demonstrates: *a.* howto setup iptables *b.* howto use it |
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
== 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 |
||||
|
|
||||
|
- Firewall Builder |
||||
|
|
||||
|
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[fwbuilder] |
||||
|
|
||||
|
- 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[firewalld] |
||||
|
|
||||
|
- FireStarter |
||||
|
|
||||
|
High-level GUI Iptables firewall for Linux systems |
||||
|
|
||||
|
http://www.fs-security.com[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. |
||||
|
|
||||
|
|
||||
|
.Understanding how iptables works |
||||
|
[NOTE] |
||||
|
==== |
||||
|
The key to understanding how iptables works is http://docs.swarmlab.io/lab/sec/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. |
||||
|
|
||||
|
|
||||
|
**All interfaces are handled the same way; it's up to you to define rules that treat them differently.** |
||||
|
|
||||
|
Some packets |
||||
|
|
||||
|
- are intended for local processes, hence come in from the top of the chart and stop at **Local Proces**, |
||||
|
|
||||
|
- while other packets are generated by local processes; hence start at **Local Process** and proceed downward through the flowchart. |
||||
|
|
||||
|
A detailed explanation http://docs.swarmlab.io/lab/sec/ex-3a_iptables-flow-chart.adoc.html[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: |
||||
|
|
||||
|
.Chains |
||||
|
[NOTE] |
||||
|
==== |
||||
|
Tables consist of **chains**, which are lists of rules which are followed in order. |
||||
|
==== |
||||
|
|
||||
|
==== Filter |
||||
|
|
||||
|
This is the default table. |
||||
|
|
||||
|
.Its built-in chains are: |
||||
|
[source,bash] |
||||
|
---- |
||||
|
Input: packets going to local sockets |
||||
|
Forward: packets routed through the server |
||||
|
Output: locally generated packets |
||||
|
---- |
||||
|
|
||||
|
==== Nat |
||||
|
|
||||
|
When a packet creates a new connection, this table is used. |
||||
|
|
||||
|
|
||||
|
.Its built-in chains are: |
||||
|
[source,bash] |
||||
|
---- |
||||
|
Prerouting: designating packets when they come in |
||||
|
Output: locally generated packets before routing takes place |
||||
|
Postrouting: altering packets on the way out |
||||
|
---- |
||||
|
|
||||
|
==== Mangle |
||||
|
|
||||
|
Used for special altering of packets. |
||||
|
|
||||
|
.Its built-in chains are: |
||||
|
[source,bash] |
||||
|
---- |
||||
|
Prerouting: incoming packets |
||||
|
Postrouting: outgoing packets |
||||
|
Output: locally generated packets that are being altered |
||||
|
Input: packets coming directly into the server |
||||
|
Forward: packets being routed through the server |
||||
|
---- |
||||
|
|
||||
|
==== Raw |
||||
|
|
||||
|
Primarily used for configuring exemptions from connection tracking. |
||||
|
|
||||
|
.Its built-in chains are: |
||||
|
[source,bash] |
||||
|
---- |
||||
|
Prerouting: packets that arrive by the network interface |
||||
|
Output: processes that are locally generated |
||||
|
---- |
||||
|
|
||||
|
==== Security |
||||
|
|
||||
|
Used for Mandatory Access Control (MAC) rules. After the filter table, the security table is accessed next. |
||||
|
|
||||
|
.Its built-in chains are: |
||||
|
[source,bash] |
||||
|
---- |
||||
|
Input: packets entering the server |
||||
|
Output: locally generated packets |
||||
|
Forward: packets passing through the server |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
|
||||
|
[NOTE] |
||||
|
==== |
||||
|
In most common use cases you will only use two of these: **filter** and **nat**. |
||||
|
==== |
||||
|
|
||||
|
|
||||
|
=== 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 **-j** or **--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. |
||||
|
|
||||
|
[NOTE] |
||||
|
==== |
||||
|
- Built-in targets are **ACCEPT**, **DROP**, **QUEUE** and **RETURN** |
||||
|
- target extensions are, for example, **REJECT** and **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) |
||||
|
|
||||
|
=== Traversing Chains |
||||
|
|
||||
|
A network packet received on any interface traverses the traffic control chains of tables in the order shown in the http://docs.swarmlab.io/lab/sec/tables_traverse.jpg[this 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 **INPUT chains** |
||||
|
|
||||
|
- or elsewhere (in which case the packet traverses through the **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 **ACCEPT**, **DROP**, and **jump** to a user-defined chain. |
||||
|
|
||||
|
[NOTE] |
||||
|
==== |
||||
|
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://docs.swarmlab.io/lab/sec/images/table_subtraverse.jpg[here^]. |
||||
|
|
||||
|
- If at any time a complete match is achieved for a rule with a **DROP** target, the packet is dropped and no further processing is done. |
||||
|
- If a packet is **ACCEPT**ed within a chain, it will be **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. |
||||
|
|
||||
|
|
||||
|
|
||||
|
== Usage |
||||
|
|
||||
|
=== Showing the current rules |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
# iptables -nvL |
||||
|
|
||||
|
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) |
||||
|
pkts bytes target prot opt in out source destination |
||||
|
|
||||
|
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) |
||||
|
pkts bytes target prot opt in out source destination |
||||
|
|
||||
|
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) |
||||
|
pkts bytes target prot opt in out source destination |
||||
|
---- |
||||
|
|
||||
|
If the output looks like the above, then there are no rules (i.e. nothing is blocked) in the default filter table |
||||
|
|
||||
|
|
||||
|
=== Resetting rules |
||||
|
|
||||
|
You can flush and reset iptables to default using these commands: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
# iptables -F |
||||
|
# iptables -X |
||||
|
# iptables -t nat -F |
||||
|
# iptables -t nat -X |
||||
|
# iptables -t mangle -F |
||||
|
# iptables -t mangle -X |
||||
|
# iptables -t raw -F |
||||
|
# iptables -t raw -X |
||||
|
# iptables -t security -F |
||||
|
# iptables -t security -X |
||||
|
# iptables -P INPUT ACCEPT |
||||
|
# iptables -P FORWARD ACCEPT |
||||
|
# iptables -P OUTPUT ACCEPT |
||||
|
---- |
||||
|
|
||||
|
The -F command with no arguments flushes all the chains in its current table. Similarly, -X deletes all empty non-default chains in a table. |
||||
|
|
||||
|
Individual chains may be flushed or deleted by following -F and -X with a [chain] argument. |
||||
|
|
||||
|
=== Editing rules |
||||
|
|
||||
|
Rules can be edited by |
||||
|
|
||||
|
- appending -A a rule to a chain, |
||||
|
|
||||
|
- inserting -I it at a specific position on the chain, |
||||
|
|
||||
|
- replacing -R an existing rule, |
||||
|
|
||||
|
- or deleting -D it. |
||||
|
|
||||
|
The first three commands are exemplified in the following. |
||||
|
|
||||
|
First of all, our computer is not a router (unless, of course, it is a router). We want to change the default policy on the FORWARD chain from ACCEPT to DROP. |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
# iptables -P FORWARD DROP |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
|
||||
|
=== Examples |
||||
|
|
||||
|
[NOTE] |
||||
|
==== |
||||
|
We are going to use Shorewall as an iptables configuration tool. |
||||
|
|
||||
|
See Appendix. |
||||
|
==== |
||||
|
|
||||
|
Here are some examples of "raw" iptables command lines. |
||||
|
|
||||
|
|
||||
|
==== Block Traffic by PortPermalink |
||||
|
|
||||
|
You may use a port to block all traffic coming in on a specific interface. |
||||
|
|
||||
|
For example: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
iptables -A INPUT -j DROP -p tcp --destination-port 110 -i eth0 |
||||
|
---- |
||||
|
|
||||
|
Let’s examine what each part of this command does: |
||||
|
|
||||
|
- **-A** will add or append the rule to the end of the chain. |
||||
|
|
||||
|
**INPUT** will add the rule to the table. |
||||
|
|
||||
|
**DROP** means the packets are discarded. |
||||
|
|
||||
|
- **-p tcp** means the rule will only drop TCP packets. |
||||
|
|
||||
|
- **--destination-port 110** filters packets targeted to port 110. |
||||
|
|
||||
|
- **-i eth0** means this rule will impact only packets arriving on the eth0 interface. |
||||
|
|
||||
|
|
||||
|
==== Drop Traffic |
||||
|
|
||||
|
In order to drop all incoming traffic from a specific IP address, use the iptables command with the following options: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
iptables -I INPUT -s 198.51.100.0 -j DROP |
||||
|
---- |
||||
|
|
||||
|
To remove these rules, use the **--delete** or **-D** option: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
iptables --delete INPUT -s 198.51.100.0 -j DROP |
||||
|
iptables -D INPUT -s 198.51.100.0 -j DROP |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
==== Block or Allow Traffic by Port Number |
||||
|
|
||||
|
One way to create a firewall is to block all traffic to the system and then allow traffic on certain ports. |
||||
|
|
||||
|
Below is a sample sequence of commands to illustrate the process: |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
||||
|
iptables -A INPUT -i lo -m comment --comment "Allow loopback connections" -j ACCEPT |
||||
|
iptables -A INPUT -p icmp -m comment --comment "Allow Ping to work as expected" -j ACCEPT |
||||
|
iptables -A INPUT -p tcp -m multiport --destination-ports 22,25,53,80,443,465,5222,5269,5280,8999:9003 -j ACCEPT |
||||
|
iptables -A INPUT -p udp -m multiport --destination-ports 53 -j ACCEPT |
||||
|
iptables -P INPUT DROP |
||||
|
iptables -P FORWARD DROP |
||||
|
---- |
||||
|
|
||||
|
Let’s break down the example above. |
||||
|
|
||||
|
The **first two** commands add or append rules to the **INPUT chain** in order to allow access on specific ports. |
||||
|
|
||||
|
The **-p tcp** and **-p udp** options specify either **UDP** or **TCP** packet types. |
||||
|
|
||||
|
The **-m** multiport function matches packets on the basis of their source or destination ports, and can accept the specification of up to 15 ports. |
||||
|
|
||||
|
Multiport also accepts **ranges such as 8999:9003** which counts as 2 of the 15 possible ports, but matches ports 8999, 9000, 9001, 9002, and 9003. |
||||
|
|
||||
|
The next command **allows all incoming** and **outgoing packets** that are associated with existing connections so that they will not be inadvertently blocked by the firewall. |
||||
|
|
||||
|
The final two commands use the **-P** option to describe the **default policy** for these chains. As a result, all packets processed by **INPUT** and **FORWARD** will be dropped by default. |
||||
|
|
||||
|
[NOTE] |
||||
|
==== |
||||
|
Note that the rules described above only control incoming packets, and do not limit outgoing connections. |
||||
|
==== |
||||
|
|
||||
|
=== More Examples |
||||
|
|
||||
|
[source,bash] |
||||
|
---- |
||||
|
# Allow all loopback (lo0) traffic and reject traffic |
||||
|
# to localhost that does not originate from lo0. |
||||
|
-A INPUT -i lo -j ACCEPT |
||||
|
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT |
||||
|
|
||||
|
# Allow ping. |
||||
|
-A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT |
||||
|
|
||||
|
# Allow SSH connections. |
||||
|
-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT |
||||
|
|
||||
|
# Allow HTTP and HTTPS connections from anywhere |
||||
|
# (the normal ports for web servers). |
||||
|
-A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT |
||||
|
-A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT |
||||
|
|
||||
|
# Allow inbound traffic from established connections. |
||||
|
# This includes ICMP error returns. |
||||
|
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
||||
|
|
||||
|
# Log what was incoming but denied (optional but useful). |
||||
|
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 7 |
||||
|
|
||||
|
# Reject all other inbound. |
||||
|
-A INPUT -j REJECT |
||||
|
|
||||
|
# Log any traffic that was sent to you |
||||
|
# for forwarding (optional but useful). |
||||
|
-A FORWARD -m limit --limit 5/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 7 |
||||
|
|
||||
|
# Reject all traffic forwarding. |
||||
|
-A FORWARD -j REJECT |
||||
|
---- |
||||
|
|
||||
|
|
||||
|
[appendix] |
||||
|
== How to use iptables |
||||
|
|
||||
|
|
||||
|
|
||||
|
Shorewall is not the easiest to use of the available iptables configuration tools but I believe that it is the most flexible and powerful. |
||||
|
|
||||
|
It can handle complex and fast changing network environments. |
||||
|
|
||||
|
It needs multiple configuration files, even for simple setups. |
||||
|
|
||||
|
Suitable for powerusers! - Most likely there are a lot of these among our Students :-) |
||||
|
|
||||
|
Shorewall is very popular! |
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
https://wiki.archlinux.org[Origin] |
||||
|
|
||||
|
|
@ -0,0 +1,4 @@ |
|||||
|
antora --fetch /antora/site.yml |
||||
|
antora /antora/site.yml |
||||
|
ifconfig |
||||
|
http-server build/site -c-1 |
@ -0,0 +1,21 @@ |
|||||
|
site: |
||||
|
title: Swarmlab sec-iptables |
||||
|
url: http://docs.swarmlab.io/SwarmLab-HowTos/swarmlab/docs |
||||
|
start_page: swarmlab_sec-iptables::index.adoc |
||||
|
content: |
||||
|
sources: |
||||
|
- url: https://git.swarmlab.io:3000/docs/Documentation.git |
||||
|
branches: master |
||||
|
start_path: iptables |
||||
|
ui: |
||||
|
bundle: |
||||
|
url: https://git.swarmlab.io:3000/docs/docs/raw/branch/master/ui-bundle.zip |
||||
|
snapshot: true |
||||
|
supplemental_files: ./supplemental-ui |
||||
|
asciidoc: |
||||
|
attributes: |
||||
|
:plantuml-server-url: http://www.plantuml.com/plantuml |
||||
|
extensions: |
||||
|
- '@djencks/asciidoctor-mathjax' |
||||
|
- asciidoctor-plantuml |
||||
|
|
Before Width: | Height: | Size: 162 KiB |
Before Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 54 KiB |
Before Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 63 KiB |
Before Width: | Height: | Size: 49 KiB |
Before Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 103 KiB |
Before Width: | Height: | Size: 707 KiB |
Before Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 49 KiB |