Difference between pages "Creating VMs" and "IPTables"

From Wikislax
(Difference between pages)
Jump to: navigation, search
(Creating a PV VM)
 
(Iptables Filtering)
 
Line 1: Line 1:
 
{{RightTOC}}
 
{{RightTOC}}
  
== the xl tool ==
+
Packet filtering affords opening access only to these services you have decided to open. The TCP or UDP packets include a piece of information called the port number, that is used to identify the type of service. Secure ports were defined as SSL counterparts of the native ports but were superseded by [https://en.wikipedia.org/wiki/Transport_Layer_Security TLS] and are now deprecated due to security weaknesses in the SSL protocol. SSL should not be used any longer. Instead, use TLS. Current version is v1.2.
  
There is a variety of tools and commands to handle virtual machines. Here we will use the Xen '''xl''' command.
+
{| {{thead}}
 +
|-
 +
! {{chead}} width="100" | Protocol
 +
! {{chead}} | Port #
 +
! {{chead}} | Secure Protocol
 +
! {{chead}} | Secure Port #
 +
! {{chead}} | Service
 +
|-
 +
|SMTP||25||SMTPS||465||Mail exchange
 +
|-
 +
|HTTP||80||HTTPS||443||Web browsing
 +
|-
 +
|POP3||110||POP3S||995||Mail retrieval
 +
|-
 +
|NTTP||119||NTTPS||563||News exchange
 +
|-
 +
|IMAP||143||IMAPS||993||Mail retrieval
 +
|-
 +
|LDAP||389||LDAPS||636||Ldap Directory
 +
|}
  
* '''xl create ''file''''' affords creating a virtual machine based on the configuration in file ''file''. A one-starting sequential domain id is created.
+
<br clear=all>
  
* '''xl destroy ''domid''''' affords destroying a virtual machine with domain id ''domid''. Of course using the system in the VM will be a preferred method to terminate.
+
On server side, the services are provided by applications that may have vulnerabilities and be attacked. Examples of attacks are buffer overflow or format string attacks, that afford getting full access on the target machine by crafting special strings sent to it. An attacker could then obtain any information present there or modify or destroy the system.
  
* '''xl help''' affords getting more information on other xm commands.
+
To reduce the number of possible attacks, the number of services authorized, or who can access the system, must be restricted. This is known as packet filtering. It is only an aspect of security (obviously, the applications on the server side must also be secured ...), but it is important. <u>Never *** ever *** connect to the network a computer not protected by a packet filter !</u>
  
Xen supports paravirtualisation and hardware virtualization. Both can be used at the same time on a single Xen system.
+
To illustrate, let's configure our two-interfaces computer to be its own firewall. '''eth0''' is the Internet interface, it uses network 192.168.0.x, the gateway is an ADSL router/switch at 192.168.0.254. '''eth1''' is the (Intranet) interface to the internal network 192.168.1.x.
  
== Creating a PV VM ==
+
== Iptables Filtering ==
  
* in paravirtualization (PV) guest operating systems are modified so they are able to interlock with Xen without emulation or virtual emulated hardware. Xen PV guest kernels exist for Linux, NetBSD, FreeBSD, OpenSolaris and Novell Netware. Upstream kernel.org Linux kernels since Linux 2.6.24 include Xen PV guest (domU) support based on the Linux pvops framework, so every upstream Linux kernel can be automatically used as Xen PV guest kernel without any additional patches or modifications.
+
Since Linux 2.4, packet filtering is effected inside the kernel, and configuration effected by the '''iptables''' user-space program. In addition to rules for incoming and outgoing packets, iptables affords defining rules for routing between the interfaces. The '''iptables''' command affords entering the rules '''one by one'''. Using a script affords entering all the rules. '''iptable -L -v''' affords viewing the current rules.
  
Paravirtualization requires storing the kernel to boot in the dom0 filesystem, and populating the system in a virtual partition. The kernel generated must be able to manage [http://wiki.qemu.org/download/qemu-doc.html#QEMU-PC-System-emulator the QEMU devices] and include the .config file [http://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs#Configuring_the_kernel domU options]. Here is a minimal example of such a [{{SERVER}}/wikislax/download/config-domU .config domU] file. The swap partition and VM filesystem can be created as below. Don't forget to update the root device in fstab :
+
For more information, see the [http://www.netfilter.org/ netfilter] official site. This site has links to various documents, including a simple introduction to packet filtering in this [http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html HOWTO].
  
# dd if=/dev/zero of=pv-sl12.swap bs=1024k count=1024
+
In Slackware, the script used is <tt>'''/etc/rc.d/rc.firewall'''</tt>. It is called automatically when the system starts or stops, using commands <tt>'''./rc.firewall start'''</tt> or <tt>'''./rc.firewall stop'''</tt>.
# mkswap pv-sl12.swap
 
# dd if=/dev/zero of=pv-sl12.img bs=1024k count=8192
 
  # mkfs -t ext3 pv-sl12.img
 
# mkdir /tmp/loop
 
# mount -o loop pv-sl12.img /tmp/loop
 
# cp -ax /mnt/sl12/{bin,dev,etc,lib,root,sbin,usr,var} /tmp/loop
 
# mkdir /tmp/loop/{home,proc,opt,sys,tmp}
 
# chmod 777 /tmp/loop/tmp
 
# vi /tmp/loop/etc/fstab
 
# umount /tmp/loop
 
  
Then a PV config file needs to be created. Samples are available from the /etc/xen directory. Here is an [{{SERVER}}/wikislax/download/sl12 example] running in a X window for slackware 12.1 (32 bits). The main config options to modify are :
+
#! /bin/sh
 +
#
 +
# startup script for local packet filter
 +
#
 +
fw_start () {
 +
echo "Loading packet filter rules"
  
# Kernel image file in dom0 filesystem
+
The flush command affords deleting all the active nat and filtering rules:
kernel = "/boot/vmlinuz-3.4.2-domU"
 
# Not using any optional ramdisk
 
#ramdisk = "/boot/initrd.gz"
 
# Initial memory allocation (in megabytes) for the new domain.
 
memory = 2048
 
# A name for the new domain. All domains have to have different names,
 
name = "sl12"
 
# Number of virtual CPUs
 
vcpus = 2
 
# Define network interfaces
 
vif = [ ' ' ]
 
# Define disk devices. Note the device names xvda and xvdb
 
disk = [ 'file:/mnt/xen/sl12.img,xvda1,w', 'file:/mnt/xen/sl12.swap,xvdb,w' ]
 
# Define frame buffer device. Use sdl to view virtual machine in a window
 
vfb = [ 'sdl=1' ]
 
# Set root device.
 
root = "/dev/xvda1 ro"
 
# Window resolution additional parameters
 
extra = "xen-fbfront.video=16,1280,768"
 
  
The VM can then be launched with '''xl create ''file''''' :
+
# flush old rules
 +
iptables -t nat --flush
 +
iptables -flush
  
root@inner:/etc/xen# xl create sl12
+
The -P option affords defining the default policy. A good practise is to forbid by default everything not authorized. This is done here for packets incoming, outgoing, and routed between the interfaces:
Parsing config from sl12
 
root@inner:/etc/xen#
 
  
== Creating a HVM ==
+
# drop by default
 +
iptables -P INPUT DROP
 +
iptables -P FORWARD DROP
 +
iptables -P OUTPUT DROP
  
* in full hardware virtualization (HVM) guests require CPU virtualization extensions from the host CPU (Intel VT-x, AMD-V). Xen uses a modified version of Qemu to emulate full PC hardware, including BIOS, IDE disk controller, VGA graphic adapter, USB controller, network adapter etc for HVM guests. CPU virtualization extensions are used to boost performance of the emulation. Fully virtualized guests do not require kernel support, so for example Windows operating systems can be used as Xen HVM guest. Fully virtualized guests are usually slower than paravirtualized guests, because of the required emulation.
+
Connections already established are authorized to continue:
  
Full hardware virtualization requires only a disk image to execute in. Then a HV config file needs to be created. Samples are available from the /etc/xen directory. Here is an [{{SERVER}}/wikislax/download/win7 example] running in a X window for Windows 7. The main config options to modify are :
+
# accept packets that are part of previously OK'ed sessions
 +
iptables -A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
 +
iptables -A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
 +
iptables -A FORWARD -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
  
# Initial memory allocation (in megabytes) for the new domain.
+
The -A option affords adding a rule. Here all the packets on the loopback interface are accepted:
memory = 2048
 
# A name for the new domain. All domains have to have different names,
 
name = "win7"
 
# Number of virtual CPUs
 
vcpus = 4
 
# Define network interfaces
 
vif = [ 'type=ioemu, bridge=br0' ]
 
# Define disk devices. Note the device names xvda and xvdb
 
disk = [ 'file:/mnt/xen/win7.img,hda,w', 'file:/mnt/xen/win7.iso,hdc:cdrom,r' ]
 
# enable SDL library for graphics, default = 0
 
sdl=1
 
# enable VNC library for graphics, default = 1
 
vnc=0
 
# set VNC display number, default = domid
 
vncdisplay=7
 
  
The VM can then be launched with '''xl create ''file''''' :
+
# INBOUND POLICY
 +
 +
# pass all traffic for network 127.0.0.0/8 on loopback interface
 +
iptables -A INPUT -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
  
  root@inner:/etc/xen# xl create win7
+
Addresses of RFC 1918 private networks are not routable on the Internet. So packets with such addresses are not expected on the internal network. However as anti-spoofing is ensured by Internet box we do not need to introduce anti-spoofing rules here:
  Parsing config from win7
+
  root@inner:/etc/xen#
+
  # anti-spoofing done by Internet box so not needed here
 +
  # iptables -A INPUT -s 10.0.0.0/8 -j LOG --log-prefix "INPUT spoofed IP "
 +
  # iptables -A INPUT -s 10.0.0.0/8 -j DROP
 +
# . . .
  
== A little screen shot ==
+
The protocols corresponding to services offered or used externally are accepted:
  
The 3 VMs displayed on this slackware 13.37 dom0 are slackware 12.1, windows 7 and windows 8.
+
# services SMTP HTTP HTTPS
 +
# iptables -A INPUT -p tcp -j ACCEPT --dport 25 -m conntrack --ctstate NEW
 +
iptables -A INPUT -p tcp -j ACCEPT --dport 80 -m conntrack --ctstate NEW
 +
# iptables -A INPUT -p tcp -j ACCEPT --dport 143 -m conntrack --ctstate NEW
 +
iptables -A INPUT -p tcp -j ACCEPT --dport 443 -m conntrack --ctstate NEW
  
[[file:Screenshot.png]]
+
The protocols corresponding to services offered on the local network are accepted:
 +
 
 +
  # services on local network FTP DNS BOOTP NNTP SUBMIT VNC
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 20 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 21 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 53 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 53 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 69 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 119 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 587 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  # iptables -A INPUT -p tcp -j ACCEPT --dport 5900:5912 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
 
 +
We accept X-Window traffic on the local network:
 +
 
 +
  # SSH-tunnelled X-Window output appears as input on interface lo
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 177 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 6000:6063 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -i lo -p tcp -j ACCEPT --dport 6000:6063 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
 
 +
We accept NFS on the local network and fix the NFS ports:
 +
 
 +
  # NFS ports
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
 
 +
We accept samba traffic on the local network:
 +
 
 +
  # samba ports
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 135 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 135 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 137 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 137 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 138 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 139 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p udp -j ACCEPT --dport 445 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
  iptables -A INPUT -p tcp -j ACCEPT --dport 445 -m conntrack --ctstate NEW -s 192.168.53.0/24
 +
 
 +
Broadcast traffic is also OK:
 +
 
 +
  # broadcast traffic
 +
  iptables -A INPUT -p udp -s 0.0.0.0 -sport 67:68 -d 255.255.255.255 -j ACCEPT
 +
 
 +
We accept pings on the local network:
 +
 
 +
  # accept some icmp packets
 +
  iptables -A INPUT -p icmp --icmp-type echo-request -s 192.168.53.0/24 -j ACCEPT
 +
  iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
 +
  iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
 +
 
 +
We could log anything not accepted above:
 +
 
 +
# log anything not accepted above
 +
# iptables -A INPUT -j LOG --log-prefix "INPUT bad traffic "
 +
 
 +
We accept all outbound packets, which would for example afford using a network scanner. In a production environment, there would be a stricter policy:
 +
 
 +
# OUTBOUND POLICY
 +
 +
# accept all outbound packets
 +
iptables -A OUTPUT -j ACCEPT
 +
}
 +
 +
After the fw_start() function ends, the fw_stop() function is defined to authorize everything:
 +
 
 +
fw_stop () {
 +
  echo "Unloading all packet filter rules"
 +
  iptables -t nat --flush
 +
  iptables -flush
 +
 +
# accept by default
 +
  iptables -P INPUT ACCEPT
 +
  iptables -P FORWARD ACCEPT
 +
  iptables -P OUTPUT ACCEPT
 +
  }
 +
 +
case "$1" in
 +
‘start’)
 +
  fw_start
 +
  ;;
 +
’stop’)
 +
  fw_stop
 +
  ;;
 +
’restart’)
 +
  fw_start
 +
  ;;
 +
*)
 +
  echo "usage $0 start | stop | restart"
 +
 
 +
== Testing the firewall ==
 +
 
 +
Use '''nmap -sU hostname''' (UDP) and '''nmap -sT hostname''' (TCP) to make sure what ports are visible locally and do the same from the outside.
 +
 
 +
== Download example ==
 +
 
 +
[{{SERVER}}/wikislax/download/rc.firewall Download file rc.firewall]
  
 
<br/>
 
<br/>
  
{{pFoot|[[Using Grub2]]|[[Main Page]]|[[OpenSSL]]}}
+
{{pFoot|[[Configuration files]]|[[Main Page]]|[[X11 configuration]]}}

Revision as of 13:22, 26 March 2026

Packet filtering affords opening access only to these services you have decided to open. The TCP or UDP packets include a piece of information called the port number, that is used to identify the type of service. Secure ports were defined as SSL counterparts of the native ports but were superseded by TLS and are now deprecated due to security weaknesses in the SSL protocol. SSL should not be used any longer. Instead, use TLS. Current version is v1.2.

Protocol Port # Secure Protocol Secure Port # Service
SMTP 25 SMTPS 465 Mail exchange
HTTP 80 HTTPS 443 Web browsing
POP3 110 POP3S 995 Mail retrieval
NTTP 119 NTTPS 563 News exchange
IMAP 143 IMAPS 993 Mail retrieval
LDAP 389 LDAPS 636 Ldap Directory


On server side, the services are provided by applications that may have vulnerabilities and be attacked. Examples of attacks are buffer overflow or format string attacks, that afford getting full access on the target machine by crafting special strings sent to it. An attacker could then obtain any information present there or modify or destroy the system.

To reduce the number of possible attacks, the number of services authorized, or who can access the system, must be restricted. This is known as packet filtering. It is only an aspect of security (obviously, the applications on the server side must also be secured ...), but it is important. Never *** ever *** connect to the network a computer not protected by a packet filter !

To illustrate, let's configure our two-interfaces computer to be its own firewall. eth0 is the Internet interface, it uses network 192.168.0.x, the gateway is an ADSL router/switch at 192.168.0.254. eth1 is the (Intranet) interface to the internal network 192.168.1.x.

Iptables Filtering

Since Linux 2.4, packet filtering is effected inside the kernel, and configuration effected by the iptables user-space program. In addition to rules for incoming and outgoing packets, iptables affords defining rules for routing between the interfaces. The iptables command affords entering the rules one by one. Using a script affords entering all the rules. iptable -L -v affords viewing the current rules.

For more information, see the netfilter official site. This site has links to various documents, including a simple introduction to packet filtering in this HOWTO.

In Slackware, the script used is /etc/rc.d/rc.firewall. It is called automatically when the system starts or stops, using commands ./rc.firewall start or ./rc.firewall stop.

#! /bin/sh
#
# startup script for local packet filter
#
fw_start () {
echo "Loading packet filter rules"

The flush command affords deleting all the active nat and filtering rules:

# flush old rules
iptables -t nat --flush
iptables -flush

The -P option affords defining the default policy. A good practise is to forbid by default everything not authorized. This is done here for packets incoming, outgoing, and routed between the interfaces:

# drop by default
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

Connections already established are authorized to continue:

# accept packets that are part of previously OK'ed sessions
iptables -A INPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED
iptables -A FORWARD -j ACCEPT -m conntrack --ctstate ESTABLISHED,RELATED 

The -A option affords adding a rule. Here all the packets on the loopback interface are accepted:

# INBOUND POLICY

# pass all traffic for network 127.0.0.0/8 on loopback interface
iptables -A INPUT -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT

Addresses of RFC 1918 private networks are not routable on the Internet. So packets with such addresses are not expected on the internal network. However as anti-spoofing is ensured by Internet box we do not need to introduce anti-spoofing rules here:

# anti-spoofing done by Internet box so not needed here
# iptables -A INPUT -s 10.0.0.0/8 -j LOG --log-prefix "INPUT spoofed IP "
# iptables -A INPUT -s 10.0.0.0/8 -j DROP
# . . .

The protocols corresponding to services offered or used externally are accepted:

# services SMTP HTTP HTTPS
# iptables -A INPUT -p tcp -j ACCEPT --dport 25 -m conntrack --ctstate NEW
iptables -A INPUT -p tcp -j ACCEPT --dport 80 -m conntrack --ctstate NEW
# iptables -A INPUT -p tcp -j ACCEPT --dport 143 -m conntrack --ctstate NEW
iptables -A INPUT -p tcp -j ACCEPT --dport 443 -m conntrack --ctstate NEW

The protocols corresponding to services offered on the local network are accepted:

 # services on local network FTP DNS BOOTP NNTP SUBMIT VNC
 iptables -A INPUT -p tcp -j ACCEPT --dport 20 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 21 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p udp -j ACCEPT --dport 53 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 53 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p udp -j ACCEPT --dport 69 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 119 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 587 -m conntrack --ctstate NEW -s 192.168.53.0/24
 # iptables -A INPUT -p tcp -j ACCEPT --dport 5900:5912 -m conntrack --ctstate NEW -s 192.168.53.0/24

We accept X-Window traffic on the local network:

 # SSH-tunnelled X-Window output appears as input on interface lo
 iptables -A INPUT -p udp -j ACCEPT --dport 177 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 6000:6063 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -i lo -p tcp -j ACCEPT --dport 6000:6063 -m conntrack --ctstate NEW -s 192.168.53.0/24

We accept NFS on the local network and fix the NFS ports:

 # NFS ports
 iptables -A INPUT -p udp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 111 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p udp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 2049 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p udp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 32764:32769 -m conntrack --ctstate NEW -s 192.168.53.0/24

We accept samba traffic on the local network:

 # samba ports
 iptables -A INPUT -p udp -j ACCEPT --dport 135 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 135 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p udp -j ACCEPT --dport 137 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 137 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p udp -j ACCEPT --dport 138 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 139 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p udp -j ACCEPT --dport 445 -m conntrack --ctstate NEW -s 192.168.53.0/24
 iptables -A INPUT -p tcp -j ACCEPT --dport 445 -m conntrack --ctstate NEW -s 192.168.53.0/24

Broadcast traffic is also OK:

 # broadcast traffic
 iptables -A INPUT -p udp -s 0.0.0.0 -sport 67:68 -d 255.255.255.255 -j ACCEPT

We accept pings on the local network:

 # accept some icmp packets
 iptables -A INPUT -p icmp --icmp-type echo-request -s 192.168.53.0/24 -j ACCEPT
 iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
 iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

We could log anything not accepted above:

# log anything not accepted above
# iptables -A INPUT -j LOG --log-prefix "INPUT bad traffic "

We accept all outbound packets, which would for example afford using a network scanner. In a production environment, there would be a stricter policy:

# OUTBOUND POLICY

# accept all outbound packets
iptables -A OUTPUT -j ACCEPT
}

After the fw_start() function ends, the fw_stop() function is defined to authorize everything:

fw_stop () {
  echo "Unloading all packet filter rules"
  iptables -t nat --flush
  iptables -flush

# accept by default
  iptables -P INPUT ACCEPT
  iptables -P FORWARD ACCEPT
  iptables -P OUTPUT ACCEPT
  }

case "$1" in
‘start’)
  fw_start
  ;;
’stop’)
  fw_stop
  ;;
’restart’)
  fw_start
  ;;
*)
  echo "usage $0 start | stop | restart"

Testing the firewall

Use nmap -sU hostname (UDP) and nmap -sT hostname (TCP) to make sure what ports are visible locally and do the same from the outside.

Download example

Download file rc.firewall


Configuration files Main Page X11 configuration