Podrška #13998: IPTABLES Firewall Example - ocean - ubuntu - bring.out redmine

Akcije

Copy link

Podrška #13998

Zatvoren

IPTABLES Firewall Example - ocean

Dodano od Ernad Husremović prije oko 18 godina. Izmjenjeno prije više od 17 godina.

Status:

Zatvoreno

Prioritet:

Normalan

Odgovorna osoba:

Ernad Husremović

Kategorija:

iptables

Početak:

17.04.2008

Završetak:

% završeno:

Procjena vremena:

Opis

OCEAN PARK SOFTWARE CONSULTING
serving the Internet since 1992

IPTABLES Firewall Example

Red Hat Linux firewall using iptables #
Created: October 2002
Last Revised: August 2006 #
Authors: Dennis G. Allard (allard@oceanpark.com) and Don Cohen (don@isis.cs3-inc.com) #
This script works on on servers running Red Hat 7.3, 8.0, 9.0, and
RHEL ES 3 and 4. Variants of this script are in active use on
many servers. #
No warranty is implied. Use at your own risk!!

Using this script
----------------- #
I save this file as /etc/sysconfig/iptables-precursor
and then source it and run iptables-save to create
/etc/sysconfig/iptables, which is an input file
consumed by the script /etc/rc.d/init.d/iptables,
which in turn makes use of the script /sbin/iptables-restore. #
Before mucking with setting up iptables, you should
disconnect the machine from the internet. Examine
and understand the current set of iptables rules
before you reconnect to the internet. #
To configure the set of iptables rules: #
/etc/rc.d/init.d/iptables stop
source /etc/sysconfig/iptables-precursor #
To save the current set of iptables rules for use at next reboot:
iptables-save > /etc/sysconfig/iptables
To dynamically restart iptables after modifying /etc/sysconfig/iptables: #
/etc/rc.d/init.d/iptables restart #
Note that /etc/rc.d/init.d/iptables is a script. You can read it to
gain understanding of how iptables uses iptables-restore to restore
iptables firewall rules at reboot. #
To examine the current set of rules in effect: #
/etc/rc.d/init.d/iptables status #
However, I prefer to show the current set of rules via: #
iptables -nvL -t filter
iptables -nvL -t nat #
or #
iptables -vL -t filter
iptables -vL -t nat # #
To configure iptables to be used at next system reboot:
chkconfig --add iptables #
To see if iptables is currently configured to start at boot, do:
chkconfig --list iptables #
(You might have to do chkconfig --del ipchains to remove ipchains) #
The rest of this file is derived from my old ipchains script. #

A word about routing
--------------------
Note that this web page does not discuss routing decisions. Routing
(see the 'ifconfig' and 'route' commands) decides which interface an
incoming packet will be delivered to, i.e. if a given packet will be
'input' to this machine or be 'forwarded' to some interface for
delivery to another machine, say on an internal network. You should
have your routing configured before you attempt to configure your
firewall. #
Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the
Destination or Source IP addresses of a packet and, in this way, interact
with routing decisions. See section below: 'More about NAT and routing'. #

The network
----------- #
This firewall is running on a gateway machine having multiple ethernet
interfaces, a public one, eth0, which is a DSL connection to an ISP,
and one or more internal ones, including eth1, which is assigned to
192.168.0.1, an IP number on my internal private network. My public
network has static IP numbers depicted below as x.y.z.... Actual
IP numbers would, of course, be a sequence of four octets. For this
script, I assume that the firewall is running on the same machine
having the interfaces configued with my public IPs. For this reason,
most of the rules below are INPUT rules. Were I to route some of my public
static IP numbers to interfaces on one or more machines inside the
firewall on the internal network, I would modify certain rules to be
FORWARD rules instead of INPUT rules. I show some examples below of
FORWARD rules. Finally, the script is just for a single server IP,
hence all of the "/32" network masks below. A more realistic situation
would involve using IP ranges and their corresponding network masks. #
The gateway at my ISP is x.y.z.1. I run a few web servers on
x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m. #
Using this file in a more complex network would require some
modifications. Particular attention would need to be given to using
the right the IP numbers and interfaces, among other things. :-) #

Preliminaries
------------- #
To permit machines internal to the network to be able to
send IP packets to the outside world, enable IP Forwarding: #
echo 1 > /proc/sys/net/ipv4/ip_forward #
Prevent SYN floods from consuming memory resources: #
echo 1 > /proc/sys/net/ipv4/tcp_syncookies #
I place the above echo commands into /etc/rc.d/rc.local
so that they will be executed at boot time. #

The basic idea of this firewall
------------------------------- #
Provide rules that are applied in the following order: #
ACCEPT all UDP packets for certain UDP services #
Currently the only UDP connections I accept are to my secure DNS
server, tinydns. For an explanation of why tinydns is secure, see:
http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699. #
DENY all other UDP packets. #
ACCEPT SYN packets just for certain TCP services #
SYN packets are specified via the -syn flag in the input
rules defined below. Note that certain services can be
further filtered by xinetd. #
DENY all other TCP SYN packets. #
ACCEPT all other TCP packets that are part of existing connections #
DENY all other TCP packets. #
In other words, we allow any TCP packet through that is part of an
established TCP connection, but we are very selective in just which
connections we permit to be made to start off with. #
A brief explanation of SYN packets goes as follows. TCP connections
are initiated via a hand shaking protocol between the client and server
programs at either end of the connection. The very first TCP packet
is sent by the client to the server and is called a SYN packet,
because it has the SYN flag set to 1 in the TCP packet header. We
only allow SYN packets for the specific servers running on specific
ports of specific hosts. Subsequently, we only permit further TCP
packets in that are determined to be part of a connection whose
initial SYN packet was already accepted and responded to by one of our
servers. This is done via 'Stateful Packet Inspection' provided by the
netfilter functionality added to linux as of kernel 2.4. By stopping all
other packets in their tracks, we limit attempts to attack our internal
network.
There are subtle ways that Denial of Service attacks can be performed
if an attacker is able to somehow gain access to a machine inside our
network or otherwise hijack a connection. However, even in such
cases, current research is leading to ways to greatly limit the effect
of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html. #
For detailed background reading about iptables, please refer to:
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html #

begin oceanpark.com firewall rules (using iptables)
---------------------------------------------------

Here we go...

Configure default policies (-P), meaning default rule to apply if no
more specific rule below is applicable. These rules apply if a more specific rule below
is not applicable. Defaults are to DROP anything sent to firewall or internal
network, permit anything going out. #
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Flush (-F) all specific rules #
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat

The rest of this file contains specific rules that are applied in the order
listed. If none applies, then the above policy rules are used.

Forward all packets from eth1 (internal network) to eth0 (the internet). #
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Forward packets that are part of existing and related connections from eth0 to eth1. #
iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Permit packets in to firewall itself that are part of existing and related connections. #
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Note, in the above two rules, a connection becomes ESTABLISHED in the
iptables PREROUTING chain upon receipt of a SYNACK packet that is a
response to a previously sent SYN packet. The SYNACK packet itself is
considered to be part of the established connection, so no special
rule is needed to allow the SYNACK packet itself.

Allow all inputs to firewall from the internal network and local interfaces #
iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

Enable SNAT functionality on eth0 #
SNAT (Source NAT) is used to map private source IP numbers of
interfaces on the internal LAN to one of my public static IP numbers.
SNAT performs this mapping when a client running on one of the
internal hosts (x.y.z.c) initiates a TCP connection (SYN) through
eth0. #
iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT --to-source x.y.z.c

Alternative to SNAT -- MASQUERADE #
If your firewall has a dynamic IP number because it connects to the
internet itself via DHCP, then you probably cannot predict what the IP
number is of your firewall's interface connected to the internet. In
this case, you need a rule like the following that assigns the (an) IP
number associated with eth0 to outgoing connections without you needing
to know in advance (at time of writing this rule) what that IP number is: #
iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE #
Note that the above SNAT and MASQUERADE rules are applicable
independent of how a host on the internal network is assigned its own
internal IP number. The host could be assigned a static IP number on
an internal nonpublic network (e.g. 10. or 192.168.) or it could be
itself assigned a dynamic IP number from your own DHCP server running
on the firewall, or it could even have a public static IP number.
However, it seems unlikely that one would want to assign a public IP
number to a host and then proceed to hide that number from the public. #

Deny any packet coming in on the public internet interface eth0
which has a spoofed source address from our local networks: #
iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP
iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH:
(SMTP connections are further audited by our SMTP server) #
iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 80 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 443 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT

Notice that the above rules are all INPUT rules. My current network
does not require me to make use of FORWARD rules, since I run all
publicly accessible servers directly on my firewall machine. But I
promised above in the description of my network to give examples of
rules used when there are servers running on machines on the internal
network. Following are examples of FORWARD rules I would use if I ran
mail, web, and ssh servers on machines on the internal network inside
the firewall. #
iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 --destination-port 25 --syn -j ACCEPT
iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 80 --syn -j ACCEPT
iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 --destination-port 443 --syn -j ACCEPT
iptables -A FORWARD -p tcp -s 0/0 -d 0/0 --destination-port 22 --syn -j ACCEPT #
The first three of the above four rules would be used if my routing
delivered packets having destination IP x.y.z.m, port 25, or IP
x.y.z.w, port 80 or 443, to an interface connected to my internal
network (i.e. the packet was being FORWARDed). The fourth of the above
four rules is similar but operates on any destination IP, port 22.
The difference between an INPUT rule and a FORWARD rule is that an
INPUT rule applies to packets that are 'input' to this machine (the
machine on which these iptables firewall rules are installed), whereas
a FORWARD rule applies to packets that are being 'fowarded', i.e. to
packets that are passing through this machine to some other machine,
such as a machine on my internal network.
If I ran my mail server on an internal machine, I would no longer
need my previous INPUT rule for x.y.z.m and would use the above
FORWARD rule instead. #

Begin Caveat, More about NAT and routing
The above talk of routing is independent of the rules defined here.
I.e., routing is determined by ifconfig, route, et. al. I have not
yet seen any very good explanation of how to setup the static routing
table (what you see as output from the `route` command). I will not
attempt to remedy that lacuna at this time. If you know of some
good documenation that completely and accurately explains the
semantics of the ifconfig and route commands, i.e., explains what
affect each has such that I can reliably predict what the output
of `route` will be after executing a sequence of ifconfig and
route commands, then please do let me know.
What can be done by IPTABLES rules that has the 'feel' of routing is
DNAT (Destintion NAT) and SNAT (Source NAT). DNAT and SNAT rules are,
respectively, mechnisms to map the incoming destination IP number and
outgoing source IP number to different IP numbers. For example, SNAT
can be used to map an internal source IP number to any one of your
external public IP numbers so that a workstation on your internal
network will appear to servers on the internet to which it connects to
have a source IP number equal to the mapped public IP number.
DNAT goes the other way. It is a mechanism used typically to map
public destination IP numbers to internal private IP numbers. (In
fact, DNAT could also map public to public or private to private or
private to public, but that is left as an exercise for the reader).
So, for example, if you run a mail server on a machine configured with
an internal IP number but wish to expose that service to the external
world via a public IP number, DNAT is for you.
Now, DNAT and SNAT are not routing but can interact with routing.
Routing decides whether a packet is going to be INPUT to this machine
or be FORWARDed to another machine. That decision is done by routing.
Once that decision is made, and only then, are the IPTABLES filtering
rules (FORWARD and INPUT rules) applied to a given packet. On the
other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING
rule. It is now time for you to read the following Packet Filtering
HOWTO section:
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html
which states:
It's common to want to do Network Address Translation (see the
NAT HOWTO) and packet filtering. The good news is that they mix
extremely well. [editor- The NAT HOWTO can be found at:
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html]
You design your packet filtering completely ignoring any NAT you
are doing. The sources and destinations seen by the packet filter
will be the `real' sources and destinations. For example, if you
are doing DNAT to send any connections to 1.2.3.4 port 80 through
to 10.1.1.1 port 8080, the packet filter would see packets going
to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80.
Similarly, you can ignore masquerading: packets will seem to come
from their real internal IP addresses (say 10.1.1.1), and replies
will seem to go back there.
Hence, INPUT/FORWARD rules would operate on destination IP numbers
after a DNAT rule is applied. But if you don't have any DNAT rules,
then INPUT/FORWARD would apply to the IP numbers as they are in the
incoming packet.
INPUT or FORWARD would be needed purely depending on whether your
routing would cause the packet to stay on the machine where the
firewall is installed or be forwarded to another machine. THAT
decision is done by routing and not by DNAT or SNAT or anything
else in this firewall script.
It is perfectly possible for the machine having the firewall to have
both public and internal IPs configured and/or for some packets to be
INPUT and others to be FORWARDed.
DNAT is done by a PREROUTING rule, so you should think of things as
proceeding in the following order:
1. apply PREROUTING DNAT rules (if any) to map destination IP
2. apply routing decisions (see ifconfig et. al.)
3a. apply INPUT rules to packets having a destination IP on this machine
3b. apply FORWARD rules to packets having a destination IP elsewhere
4. apply POSTROUTING SNAT rules (if any) to map source IP
(3a and 3b can be done in either order since they apply to a mutually
exclusive set of packets)
I think that's correct.
End Caveat, More about NAT and routing #

Sometimes I run older versions of SSH on port 2200: #
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 2200 --syn -j ACCEPT

For imapd via stunnel (instead of xinetd-based imapd): #
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 993 --syn -j ACCEPT

For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it): #
#iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 143 --syn -j ACCEPT

For DHCP server: #
iptables -A INPUT -i eth1 -p tcp --sport 68 --dport 67 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --sport 68 --dport 67 -j ACCEPT

For LDAP clients: #
#iptables A INPUT -p tcp -s 0/0 -d 0/0 --destination-port 389 -syn -j ACCEPT
#dga worry about LDAP later (after I decode LDAP documentation (-;)

DNS queries: #
Permit responses from our ISP's DNS server. When a client running on our
host makes a DNS query, the outgoing query is allowed since we permit all
outgoing packets. The reply will be a UDP connection back to the high
numbered client port from which the query was made. So we only need to
permit UDP packets from our ISP's DNS servers back to high numbered ports: #
#iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT #
But since we trust our ISP DNS Server not not have been hacked and we may
not be sure what our client IP range is, we loosen this to: #
iptables -A INPUT -p udp -s <ISP DNS server IP>/32 --source-port 53 -d 0/0 -j ACCEPT

Running a caching DNS Server #
We need to permit querying a remote DNS server. Since I am running
a caching DNS server on x.y.z.d that makes requests for DNS lookups
to external DNS servers, those servers send back responses via UDP to
the high numbered client port on x.y.z.d where the caching server listens.
I could of course increase security by running the dns cache on its own
machine/IP and restricting to just that machine/IP. #
iptables -A INPUT -p udp -s 0/0 --source-port 53 -d x.y.z.d/32 --destination-port 1024:65535 -j ACCEPT

Running a DNS server (tinydns) #
When we run a DNS server, we have to accept UDP from anywhere to port 53 #
iptables -A INPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT

Running a Master DNS Server to update slave DNS servers #
You may have your server colocated at an ISP and may arrange to have your
ISP provide your primary and secondary DNS with the ISP DNS servers slaving
off of your master DNS server. This has the advantage of letting you be
in full control of the DNS zone files yet keeping the DNS servers exposed
to the public outside of your network. To achieve this, in addition to
permitting vanilla DNS responses from the ISP DNS serves, you also need
to allow TCP connections from the ISP Master DNS Server: #
Allow DNS zone transfers via TCP from ISP Master DNS server: #
iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 --destination-port 53 --syn -j ACCEPT

For some other custom server running here listening on port <port number>: #
iptables -A INPUT -p tcp -s 0/0 -d 0/0 --destination-port <port number> --syn -j ACCEPT

For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf):
(for public file transfers we use scp, sftp, and related SSH file transfer tools) #
iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 20 --syn -j ACCEPT
iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 --destination-port 21 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 20 --syn -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 --destination-port 21 --syn -j ACCEPT

For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c): #
iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 139 --syn -j ACCEPT
iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 --destination-port 137 -j ACCEPT

#
#Special cable modem rules. I used to have a third ethernet card,
#eth2, attached to a separate ISP via a cable modem and used the rules
#shown below to cause a specific Windows machine on my internal network
#(192.168.0.128) to send traffic out via DSL and get it back via cable.
#This violates ingres filtering rules but seems to work. It was neat
#since my cable modem had higher inbound bandwidth and it permitted
#me to do downloads without impacting my DSL inbound bandwidth.
#I no longer have that third interface, so no longer use this technique. #
#iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP
#iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP
#iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT --to-source 68.65.209.39