IPTables

Adapted from Quick HOWTO Ch14 Linux Firewalls Using iptables - Linux Home Networking

• Introduction
• Packet Processing in iptables
• Important Iptables Command Switch Operations
• Using User Defined Chains
• Saving Your iptables Scripts
• Fedora's iptables Rule Generator

• Recovering From A Lost Script

• Sample iptables Scripts

  • Basic Operating System Defense

  • Advanced iptables Initialization

  • Allowing DNS Access To Your Firewall

  • Allowing WWW And SSH Access To Your Firewall

  • Allowing Your Firewall To Access The Internet

  • Allow Your Home Network To Access The Firewall

  • Masquerading (Many to One NAT)

  • Port Forwarding Type NAT (DHCP DSL)

  • Static NAT

• Troubleshooting iptables

  • Checking The Firewall Logs

  • iptables Won't Start

• Conclusion

   

Introduction

Originally, the most popular firewall/NAT package running on Linux was ipchains, but it had a number of shortcomings. To rectify this, the Netfilter organization decided to create a new product called iptables.

iptables are the default firewall package for Linux ( ip-filter which was default in the past before the conflict due to change of the license is also used).  Both implement Stateful packet inspection. This means that the firewall keeps track of each connection passing through it and in certain cases will view the contents of data flows in an attempt to anticipate the next action of certain protocols. This is an important feature for FTP and DNS and some other TCP based services

On RHEL and SLES IPtables are installed by default and are implemented as a service (actually two services: one to IPv4 and one for IPv6). 

For IPv4, you can start, stop, and restart iptables after booting by using service command:

service iptables start
service iptables stop
service iptables restart

service iptables status

To get RC-scripts activated so that iptables were started by default, use the chkconfig command:

chkconfig iptables on

Packet Processing in iptables

All packets inspected by iptables pass through a sequence of built-in tables (queues) for processing. Each of these queues is dedicated to a particular type of packet activity and is controlled by an associated packet transformation/filtering chain.

There are three tables in total.

1. The first is the mangle table which is responsible for the alteration of quality of service bits in the TCP header.
2. The second table is the filter queue which is responsible for packet filtering. It has three built-in chains in which you can place your firewall policy rules. These are the:
   • Forward chain: Filters packets to servers protected by the firewall.
   • Input chain: Filters packets destined for the firewall.
   • Output chain: Filters packets originating from the firewall.
3. The third table is the NAT queue which is responsible for network address translation. It has two built-in chains; these are:
   • Pre-routing chain: NATs packets when the destination address of the packet needs to be changed.
   • Post-routing chain: NATs packets when the source address of the packet needs to be changed

FORWARD

INPUT

OUTPUT

PREROUTING

POSTROUTING

OUTPUT

PREROUTING
POSTROUTING
OUTPUT
INPUT
FORWARD

You need to specify the table and the chain for each firewall rule you create. There is an exception: Most rules are related to filtering, so iptables assumes that any chain that's defined without an associated table will be a part of the filter table. The filter table is therefore the default.

To help make this clearer, take a look at the way packets are handled by iptables.

The packet is first examined by your rules in the mangle table's PREROUTING chain, if any. It is then inspected by the rules in the NAT table's PREROUTING chain to see whether the packet requires DNAT. It is then routed.

If the packet is destined for a protected network, then it is filtered by the rules in the FORWARD chain of the filter table and, if necessary, the packet undergoes SNAT in the POSTROUTING chain before arriving at Network B. When the destination server decides to reply, the packet undergoes the same sequence of steps. Both the FORWARD and POSTROUTING chains may be configured to implement quality of service (QoS) features in their mangle tables, but this is not usually done in SOHO environments.

If the packet is destined for the firewall itself, then it passes through the mangle table of the INPUT chain, if configured, before being filtered by the rules in the INPUT chain of the filter table before. If it successfully passes these tests then it is processed by the intended application on the firewall.

At some point, the firewall needs to reply. This reply is routed and inspected by the rules in the OUTPUT chain of the mangle table, if any. Next, the rules in the OUTPUT chain of the NAT table determine whether DNAT is required and the rules in the OUTPUT chain of the filter table are then inspected to help restrict unauthorized packets. Finally, before the packet is sent back to the Internet, SNAT and QoS mangling is done by the POSTROUTING chain

It is now time to discuss the ways in which you add rules to these chains.

Targets And Jumps

Each firewall rule inspects each IP packet and then tries to identify it as the target of some sort of operation. Once a target is identified, the packet needs to jump over to it for further processing.

--log-prefix "string"

--reject-with qualifier

icmp-port-unreachable (default)
icmp-net-unreachable
icmp-host-unreachable
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-prohibited
tcp-reset
echo-reply

--to-destination ipaddress

--to-source <address>[-<address>][:<port>-<port>]

[--to-ports <port>[-<port>]]

Important Iptables Command Switch Operations

Each line of an iptables script not only has a jump, but they also have a number of command line options that are used to append rules to chains that match your defined packet characteristics, such the source IP address and TCP port. There are also options that can be used to just clear a chain so you can start all over again.

In this command switches example

iptables -A INPUT -s 0/0 -i eth0 -d 192.168.1.1  -p TCP -j ACCEPT

iptables is being configured to allow the firewall to accept TCP packets coming in on interface eth0 from any IP address destined for the firewall's IP address of 192.168.1.1. The 0/0 representation of an IP address means any.

In this example:

iptables -A FORWARD -s 0/0 -i eth0 -d 192.168.1.58 -o eth1 -p TCP \
         --sport 1024:65535 --dport 80 -j ACCEPT

iptables is being configured to allow the firewall to accept TCP packets for routing when they enter on interface eth0 from any IP address and are destined for an IP address of 192.168.1.58 that is reachable via interface eth1. The source port is in the range 1024 to 65535 and the destination port is port 80 (www/http).

In this example:

iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT  -p icmp --icmp-type echo-reply   -j ACCEPT

iptables is being configured to allow the firewall to send ICMP echo-requests (pings) and in turn, accept the expected ICMP echo-replies.

Consider another example

iptables -A INPUT -p icmp --icmp-type echo-request \
         -m limit --limit 1/s -i eth0 -j ACCEPT

The limit feature in iptables specifies the maximum average number of matches to allow per second. You can specify time intervals in the format /second, /minute, /hour, or /day, or you can use abbreviations so that 3/second is the same as 3/s.

In this example, ICMP echo requests are restricted to no more than one per second. When tuned correctly, this feature allows you to filter unusually high volumes of traffic that characterize denial of service (DOS) attacks and Internet worms.

iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT

You can expand on the limit feature of iptables to reduce your vulnerability to certain types of denial of service attack. Here a defense for SYN flood attacks was created by limiting the acceptance of TCP segments with the SYN bit set to no more than five per second.

This is an expansion on the previous example:

iptables -A FORWARD -s 0/0 -i eth0 -d 192.168.1.58 -o eth1 -p TCP \
         --sport 1024:65535 -m multiport --dports 80,443 -j ACCEPT
 
iptables -A FORWARD -d 0/0 -o eth0 -s 192.168.1.58 -i eth1 -p TCP \
         -m state --state ESTABLISHED -j ACCEPT

Here iptables is being configured to allow the firewall to accept TCP packets to be routed when they enter on interface eth0 from any IP address destined for IP address of 192.168.1.58 that is reachable via interface eth1. The source port is in the range 1024 to 65535 and the destination ports are port 80 (www/http) and 443 (https). The return packets from 192.168.1.58 are allowed to be accepted too. Instead of stating the source and destination ports, you can simply allow packets related to established connections using the -m state and --state ESTABLISHED options.

Using User Defined Chains

As you may remember, you can configure iptables to have user-defined chains. This feature is frequently used to help streamline the processing of packets. For example, instead of using a single, built-in chain for all protocols, you can use the chain to determine the protocol type for the packet and then hand off the actual final processing to a user-defined, protocol-specific chain in the filter table. In other words, you can replace a long chain with a stubby main chain pointing to multiple stubby chains, thereby shortening the total length of all chains the packet has to pass through. For example

iptables -A INPUT -i eth0  -d 206.229.110.2 -j fast-input-queue
iptables -A OUTPUT -o eth0 -s 206.229.110.2 -j fast-output-queue

iptables -A fast-input-queue  -p icmp -j icmp-queue-in
iptables -A fast-output-queue -p icmp -j icmp-queue-out

iptables -A icmp-queue-out -p icmp --icmp-type echo-request \
         -m state --state NEW -j ACCEPT

iptables -A icmp-queue-in -p icmp --icmp-type echo-reply -j ACCEPT

Here six queues help assist in improving processing speed.

Saving Your iptables Scripts

The service iptables-save command permanently saves the iptables configuration in the /etc/sysconfig/iptables file. When the system reboots, the iptables-restore program reads the configuration and makes it the active configuration.

The format of the /etc/sysconfig/iptables file is slightly different from that of the scripts shown in this chapter. The initialization of built-in chains is automatic and the string "iptables" is omitted from the rule statements.

Here is a sample /etc/sysconfig/iptables configuration that allows ICMP, IPSec (ESP and AH packets), already established connections, and inbound SSH.

[root@bigboy tmp]# cat /etc/sysconfig/iptables
# Generated by iptables-save v1.2.9 on Mon Nov 8 11:00:07 2004 
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [144:12748]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 255 -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Mon Nov 8 11:00:07 2004
[root@bigboy tmp]#

It is never a good idea to edit this script directly because it is always overwritten by the save command and it doesn't save any comments at all, which can also make it extremely difficult to follow.

For these reasons, you're better off writing and applying a customized script and then using the service iptables-save command to make the changes permanent.

Fedora's iptables Rule Generator

Fedora comes with a program called lokkit that you can use to generate a very rudimentary firewall rule set. It prompts for the level of security and then gives you the option of doing simple customizations. It is a good place for beginners to start on a test system so that they can see a general rule structure.

Like the service iptables save command, lokkit saves the firewall rules in a new /etc/sysconfig/iptables file for use on the next reboot.

Once you have become familiar with the iptables syntax, it's best to write scripts that you can comment and then save it to /etc/sysconfig/iptables. It makes them much more manageable and readable.

Recovering From A Lost Script

Sometimes the script you created to generate iptables rules may get corrupted or lost, or you might inherit a new system from an administer and cannot find the original script used to protect it. In these situations, you can use the iptables-save and iptables-restore commands to assist you with the continued management of the server.

Unlike the service iptables save command, which actually saves a permanent copy of the firewall's active configuration in the /etc/sysconfig/iptables file, iptables-save displays the active configuration to the screen in /etc/sysconfig/iptables format. If you redirect the iptables-save screen output to a file with the > symbol, then you can edit the output and reload the updated rules when they meet your new criteria with the iptables-restore command.

This example exports the iptables-save output to a text file named firewall-config.

[root@bigboy tmp]# iptables-save > firewall-config
[root@bigboy tmp]# cat firewall-config
# Generated by iptables-save v1.2.9 on Mon Nov 8 11:00:07 2004
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [144:12748]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type 255 -j ACCEPT
-A RH-Firewall-1-INPUT -p esp -j ACCEPT
-A RH-Firewall-1-INPUT -p ah -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Mon Nov 8 11:00:07 2004
[root@bigboy tmp]#

After editing the firewall-config file with the commands you need, you can reload it into the active firewall rule set with the iptables-restore command.

[root@bigboy tmp]# iptables-restore < firewall-config

Finally, you should permanently save the active configuration so that it will be loaded automatically when the system reboots:

[root@bigboy tmp]# service iptables save

If desired, you can eventually convert this firewall-config file into a regular iptables script so that it becomes more easily recognizable and manageable.

Loading Kernel Modules Needed By iptables

The iptables application requires you to load certain kernel modules to activate some of its functions. Whenever any type of NAT is required, the iptable_nat module needs to be loaded. The ip_conntrack_ftp module needs to be added for FTP support and should always be loaded with the ip_conntrack module which tracks TCP connection states. As most scripts probably will keep track of connection states, the ip_conntrack module will be needed in any case. The ip_nat_ftp module also needs to be loaded for FTP servers behind a NAT firewall.

Unfortunately, the /etc/sysconfig/iptables file doesn't support the loading of modules, so you'll have to add the statements to your /etc/rc.local file which is run at the end of every reboot.

The script samples in this chapter include these statements only as a reminder to place them in the /etc/rc.local file

# File: /etc/rc.local

# Module to track the state of connections
modprobe ip_conntrack

# Load the iptables active FTP module, requires ip_conntrack
modprobe ip_conntrack_ftp
  
# Load iptables NAT module when required
modprobe iptable_nat
 
# Module required for active an FTP server using NAT
modprobe ip_nat_ftp

Sample iptables Scripts

This section provides some sample scripts you can use to get iptables working for you. Pay special attention to the logging example at the end.

The basic initialization script snippet should also be included in all your scripts to ensure the correct initialization of your chains should you decide to restart your script after startup. This chapter also includes other snippets that will help you get basic functionality. It should be a good guide to get you started.

Note: Once you feel more confident, you can use Appendix II "Codes, Scripts, and Configurations", to find detailed scripts. The appendix shows you how to allow your firewall to:

• Be used as a Linux Web, mail and DNS server
• Be the NAT router for your home network
• Prevent various types of attacks using corrupted TCP, UDP and ICMP packets.
• Provide outbound passive FTP access from the firewall

There are also simpler code snippets in the Appendix II "Codes, Scripts, and Configurations", for Inbound and outbound FTP connections to and from your firewall

Basic Operating System Defense

You can do several things before employing your firewall script to improve the resilience of your firewall to attack. For example, the Linux operating system has a number of built-in protection mechanisms that you should activate by modifying the system kernel parameters in the /proc filesystem via the /etc/sysctl.conf file. Using of /etc/sysctl.conf to modify kernel parameters is explained in more detail in , Appendix I "Miscellaneous Linux Topics".

Here is a sample configuration:

# File: /etc/sysctl.conf
 
#---------------------------------------------------------------
# Disable routing triangulation. Respond to queries out
# the same interface, not another. Helps to maintain state
# Also protects against IP spoofing
#---------------------------------------------------------------
 
net/ipv4/conf/all/rp_filter = 1
 
 
#---------------------------------------------------------------
# Enable logging of packets with malformed IP addresses
#---------------------------------------------------------------
 
net/ipv4/conf/all/log_martians = 1
 
 
#---------------------------------------------------------------
# Disable redirects
#---------------------------------------------------------------
 
net/ipv4/conf/all/send_redirects = 0
 
 
#---------------------------------------------------------------
# Disable source routed packets
#---------------------------------------------------------------
 
net/ipv4/conf/all/accept_source_route = 0
 
 
#---------------------------------------------------------------
# Disable acceptance of ICMP redirects
#---------------------------------------------------------------
 
net/ipv4/conf/all/accept_redirects = 0
 
 
#---------------------------------------------------------------
# Turn on protection from Denial of Service (DOS) attacks
#---------------------------------------------------------------
 
net/ipv4/tcp_syncookies = 1
 
 
#---------------------------------------------------------------
# Disable responding to ping broadcasts
#---------------------------------------------------------------
 
net/ipv4/icmp_echo_ignore_broadcasts = 1
 
#---------------------------------------------------------------
# Enable IP routing. Required if your firewall is protecting a
# network, NAT included
#---------------------------------------------------------------

net/ipv4/ip_forward = 1

Advanced iptables Initialization

You may also want to add some more advanced initialization steps to your script, including checks for Internet traffic from RFC1918 private addresses. The sample script snippet below outlines how to do this. More complex initializations would include checks for attacks using invalid TCP flags and directed broadcasts which are beyond the scope of this book.

The script also uses multiple user-defined chains to make the script shorter and faster as the chains can be repeatedly accessed. This removes the need to repeat the same statements over and over again.

You can take even more precautions to further protect your network. The complete firewall script in Appendix II "Codes, Scripts, and Configurations", outlines most of them.

#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=
#
# Define networks: NOTE!! You may want to put these "EXTERNAL"
# definitions at the top of your script.
#
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=
 
EXTERNAL_INT="eth0"            # External Internet interface
EXTERNAL_IP="97.158.253.25"    # Internet Interface IP address
 
#---------------------------------------------------------------
# Initialize our user-defined chains
#---------------------------------------------------------------
 
iptables -N valid-src
iptables -N valid-dst
 
#---------------------------------------------------------------
# Verify valid source and destination addresses for all packets
#---------------------------------------------------------------
 
iptables -A INPUT   -i $EXTERNAL_INT -j valid-src
iptables -A FORWARD -i $EXTERNAL_INT -j valid-src
iptables -A OUTPUT  -o $EXTERNAL_INT -j valid-dst
iptables -A FORWARD -o $EXTERNAL_INT -j valid-dst
 
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
#
# Source and Destination Address Sanity Checks
#
# Drop packets from networks covered in RFC 1918 (private nets)
# Drop packets from external interface IP
#
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
 
iptables -A valid-src -s $10.0.0.0/8     -j DROP
iptables -A valid-src -s $172.16.0.0/12  -j DROP
iptables -A valid-src -s $192.168.0.0/16 -j DROP
iptables -A valid-src -s $224.0.0.0/4    -j DROP
iptables -A valid-src -s $240.0.0.0/5    -j DROP
iptables -A valid-src -s $127.0.0.0/8    -j DROP
iptables -A valid-src -s 0.0.0.0/8       -j DROP
iptables -A valid-src -d 255.255.255.255 -j DROP
iptables -A valid-src -s 169.254.0.0/16  -j DROP
iptables -A valid-src -s $EXTERNAL_IP    -j DROP
iptables -A valid-dst -d $224.0.0.0/4    -j DROP

Allowing DNS Access To Your Firewall

You'll almost certainly want your firewall to make DNS queries to the Internet. This is not because it is required for the basic functionality of the firewall, but because of Fedora Linux's yum RPM updater which will help to keep the server up to date with the latest security patches. The following statements will apply not only for firewalls acting as DNS clients but also for firewalls working in a caching or regular DNS server role.

#---------------------------------------------------------------
# Allow outbound DNS queries from the FW and the replies too
#
# - Interface eth0 is the internet interface
#
# Zone transfers use TCP and not UDP. Most home networks
# / websites using a single DNS server won't require TCP statements
#
#---------------------------------------------------------------
 
iptables -A OUTPUT -p udp -o eth0 --dport 53 --sport 1024:65535 \
         -j ACCEPT
 
iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024:65535 \
         -j ACCEPT

Allowing WWW And SSH Access To Your Firewall

This sample snippet is for a firewall that doubles as a web server that is managed remotely by its system administrator via secure shell (SSH) sessions. Inbound packets destined for ports 80 and 22 are allowed thereby making the first steps in establishing a connection. It isn't necessary to specify these ports for the return leg as outbound packets for all established connections are allowed. Connections initiated by persons logged into the Web server will be denied as outbound NEW connection packets aren't allowed.

#---------------------------------------------------------------
# Allow previously established connections
# - Interface eth0 is the internet interface
#---------------------------------------------------------------

iptables -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED \
  -j ACCEPT

#---------------------------------------------------------------
# Allow port 80 (www) and 22 (SSH) connections to the firewall
#---------------------------------------------------------------

iptables -A INPUT -p tcp -i eth0 --dport 22 --sport 1024:65535 \
  -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport 80 --sport 1024:65535 \
  -m state --state NEW -j ACCEPT

Allowing Your Firewall To Access The Internet

This iptables script enables a user on the firewall to use a Web browser to surf the Internet. HTTP traffic uses TCP port 80, and HTTPS uses port 443.

Note: HTTPS (secure HTTP) is used for credit card transactions frequently, as well as by RedHat Linux servers running up2date. FTP and HTTP are frequently used with yum.

#---------------------------------------------------------------
# Allow port 80 (www) and 443 (https) connections from the firewall
#---------------------------------------------------------------

iptables -A OUTPUT -j ACCEPT -m state \
  --state NEW,ESTABLISHED,RELATED -o eth0 -p tcp \
  -m multiport --dports 80,443 --sport 1024:65535
 
#---------------------------------------------------------------
# Allow previously established connections
# - Interface eth0 is the internet interface
#---------------------------------------------------------------

iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED  \
-i eth0 -p tcp

If you want all TCP traffic originating from the firewall to be accepted, then remove the line:

-m multiport --dports 80,443 --sport 1024:65535

Allow Your Home Network To Access The Firewall

In this example, eth1 is directly connected to a home network using IP addresses from the 192.168.1.0 network. All traffic between this network and the firewall is simplistically assumed to be trusted and allowed.

Further rules will be needed for the interface connected to the Internet to allow only specific ports, types of connections and possibly even remote servers to have access to your firewall and home network.

#---------------------------------------------------------------
# Allow all bidirectional traffic from your firewall to the
# protected network
# - Interface eth1 is the private network interface
#---------------------------------------------------------------

iptables -A INPUT   -j ACCEPT -p all -s 192.168.1.0/24 -i eth1
iptables -A OUTPUT  -j ACCEPT -p all -d 192.168.1.0/24 -o eth1

Masquerading (Many to One NAT)

Masquerading is another name for what many call many to one NAT. In other words, traffic from all devices on one or more protected networks will appear as if it originated from a single IP address on the Internet side of the firewall.

Note: The masquerade IP address always defaults to the IP address of the firewall's main interface. The advantage of this is that you never have to specify the NAT IP address. This makes it much easier to configure iptables NAT with DHCP.

You can configure many to one NAT to an IP alias, using the POSTROUTING and not the MASQUERADE statement. An example of this can be seen in the static NAT section that follows.

Keep in mind that iptables requires the iptables_nat module to be loaded with the modprobe command for the masquerade feature to work. Masquerading also depends on the Linux operating system being configured to support routing between the internet and private network interfaces of the firewall. This is done by enabling IP forwarding or routing by giving the file /proc/sys/net/ipv4/ip_forward the value 1 as opposed to the default disabled value of 0.

Once masquerading has been achieved using the POSTROUTING chain of the nat table, you will have to configure iptables to allow packets to flow between the two interfaces. To do this, use the FORWARD chain of the filter table. More specifically, packets related to NEW and ESTABLISHED connections will be allowed outbound to the Internet, but only packets related to ESTABLISHED connections will be allowed inbound. This helps to protect the home network from anyone trying to initiate connections from the Internet:

#---------------------------------------------------------------
# Load the NAT module
#
# Note: It is best to use the /etc/rc.local example in this
#       chapter. This value will not be retained in the
#       /etc/sysconfig/iptables file. Included only as a reminder.
#---------------------------------------------------------------
 
modprobe iptable_nat

#---------------------------------------------------------------
# Enable routing by modifying the ip_forward /proc filesystem file
#
# Note: It is best to use the /etc/sysctl.conf example in this
#       chapter. This value will not be retained in the
#       /etc/sysconfig/iptables file. Included only as a reminder.
#---------------------------------------------------------------
 
echo 1 > /proc/sys/net/ipv4/ip_forward
 
#---------------------------------------------------------------
# Allow masquerading
# - Interface eth0 is the internet interface
# - Interface eth1 is the private network interface
#---------------------------------------------------------------
 
iptables -A POSTROUTING -t nat -o eth0 -s 192.168.1.0/24 -d 0/0 \
         -j MASQUERADE
 
#---------------------------------------------------------------
# Prior to masquerading, the packets are routed via the filter
# table's FORWARD chain.
# Allowed outbound: New, established and related connections
# Allowed inbound : Established and related connections
#---------------------------------------------------------------
 
iptables -A FORWARD -t filter -o eth0 -m state \
         --state NEW,ESTABLISHED,RELATED -j ACCEPT
 
iptables -A FORWARD -t filter -i eth0 -m state \
         --state ESTABLISHED,RELATED -j ACCEPT

Note: If you configure your firewall to do masquerading, then if should be the used as the default gateway for all your servers on the network.

Port Forwarding Type NAT (DHCP DSL)

In many cases home users may get a single DHCP public IP address from their ISPs. If a Linux firewall is also your interface to the Internet and you want to host a Web site on one of the NAT protected home servers, then you will have to use port forwarding. Here the combination of the firewall's single IP address, the remote server's IP address, and the source/destination port of the traffic can be used to uniquely identify a traffic flow. All traffic that matches a particular combination of these factors may then be forwarded to a single server on the private network.

Port forwarding is handled by the PREROUTING chain of the nat table. As in masquerading, the iptables_nat module has to be loaded and routing has to be enabled for port forwarding to work. Routing too must be allowed in iptables with the FORWARD chain, this includes all NEW inbound connections from the Internet matching the port forwarding port plus all future packets related to the ESTABLISHED connection in both directions:

#---------------------------------------------------------------
# Load the NAT module
#
# Note: It is best to use the /etc/rc.local example in this
#       chapter. This value will not be retained in the
#       /etc/sysconfig/iptables file. Included only as a reminder.
#---------------------------------------------------------------
 
modprobe iptable_nat

#---------------------------------------------------------------
# Get the IP address of the Internet interface eth0 (linux only)
#
# You'll have to use a different expression to get the IP address
# for other operating systems which have a different ifconfig output
# or enter the IP address manually in the PREROUTING statement
#
# This is best when your firewall gets its IP address using DHCP.
# The external IP address could just be hard coded ("typed in
# normally")
#---------------------------------------------------------------
 
external_int="eth0"
external_ip="`ifconfig $external_int | grep 'inet addr' | \
                       awk '{print $2}' | sed -e 's/.*://'`"
#---------------------------------------------------------------
# Enable routing by modifying the ip_forward /proc filesystem file
#
# Note: It is best to use the /etc/sysctl.conf example in this
#       chapter. This value will not be retained in the
#       /etc/sysconfig/iptables file. Included only as a reminder.
#---------------------------------------------------------------
 
echo 1 > /proc/sys/net/ipv4/ip_forward
 
#---------------------------------------------------------------
# Allow port forwarding for traffic destined to port 80 of the
# firewall's IP address to be forwarded to port 8080 on server
# 192.168.1.200
#
# - Interface eth0 is the internet interface
# - Interface eth1 is the private network interface
#---------------------------------------------------------------
 
iptables -t nat -A PREROUTING -p tcp -i eth0 -d $external_ip \
     --dport 80 --sport 1024:65535 -j DNAT --to 192.168.1.200:8080
 
#---------------------------------------------------------------
# After DNAT, the packets are routed via the filter table's
# FORWARD chain.
# Connections on port 80 to the target machine on the private
# network must be allowed.
#---------------------------------------------------------------
 
iptables -A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.1.200 \
    --dport 8080 --sport 1024:65535 -m state --state NEW -j ACCEPT
 
iptables -A FORWARD -t filter -o eth0 -m state \
         --state NEW,ESTABLISHED,RELATED -j ACCEPT
 
iptables -A FORWARD -t filter -i eth0 -m state \
         --state ESTABLISHED,RELATED -j ACCEPT

Static NAT

In this example, all traffic to a particular public IP address, not just to a particular port, is translated to a single server on the protected subnet. Because the firewall has more than one IP address, I can't recommend MASQUERADE; it will force masquerading as the IP address of the primary interface and not as any of the alias IP addresses the firewall may have. Instead, use SNAT to specify the alias IP address to be used for connections initiated by all other servers in the protected network.

Note: Although the nat table NATs all traffic to the target servers (192.168.1.100 to 102), only connections on ports 80,443 and 22 are allowed through by the FORWARD chain. Also notice how you have to specify a separate -m multiport option whenever you need to match multiple non-sequential ports for both source and destination.

In this example the firewall:

• Uses one to one NAT to make the server 192.168.1.100 on your home network appear on the Internet as IP addresses 97.158.253.26.
• Creates a many to one NAT for the 192.168.1.0 home network in which all the servers appear on the Internet as IP address 97.158.253.29. This is different from masquerading

You will have to create alias IP addresses for each of these Internet IPs for one to one NAT to work.

#---------------------------------------------------------------
# Load the NAT module
#
# Note: It is best to use the /etc/rc.local example in this
#       chapter. This value will not be retained in the
#       /etc/sysconfig/iptables file. Included only as a reminder.
#---------------------------------------------------------------
 
modprobe iptable_nat
 
#---------------------------------------------------------------
# Enable routing by modifying the ip_forward /proc filesystem file
#
# Note: It is best to use the /etc/sysctl.conf example in this
#       chapter. This value will not be retained in the
#       /etc/sysconfig/iptables file. Included only as a reminder.
#---------------------------------------------------------------
 
echo 1 > /proc/sys/net/ipv4/ip_forward
 
#---------------------------------------------------------------
# NAT ALL traffic:
###########
# REMEMBER to create aliases for all the internet IP addresses below
###########
#
# TO:             FROM:           MAP TO SERVER:
# 97.158.253.26    Anywhere        192.168.1.100 (1:1 NAT - Inbound)
# Anywhere        192.168.1.100   97.158.253.26 (1:1 NAT - Outbound)
# Anywhere        192.168.1.0/24  97.158.253.29 (FW IP)
#
# SNAT is used to NAT all other outbound connections initiated
# from the protected network to appear to come from
# IP address 97.158.253.29
#
# POSTROUTING:
#   NATs source IP addresses. Frequently used to NAT connections from
#   your home network to the Internet
#
# PREROUTING:
#   NATs destination IP addresses. Frequently used to NAT
#   connections from the Internet to your home network
#
# - Interface eth0 is the internet interface
# - Interface eth1 is the private network interface
#---------------------------------------------------------------
 
# PREROUTING statements for 1:1 NAT
# (Connections originating from the Internet)

iptables -t nat -A PREROUTING -d 97.158.253.26 -i eth0 \
        -j DNAT --to-destination 192.168.1.100

# POSTROUTING statements for 1:1 NAT
# (Connections originating from the home network servers)

iptables -t nat -A POSTROUTING -s 192.168.1.100 -o eth0 \
         -j SNAT --to-source 97.158.253.26
 
# POSTROUTING statements for Many:1 NAT
# (Connections originating from the entire home network)

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 \
         -j SNAT -o eth0 --to-source 97.158.253.29

# Allow forwarding to each of the servers configured for 1:1 NAT
# (For connections originating from the Internet. Notice how you
# use the real IP addresses here)
 
iptables -A FORWARD -p tcp -i eth0 -o eth1 -d 192.168.1.100 \
    -m multiport --dports 80,443,22 \
    -m state --state NEW -j ACCEPT
 
 
# Allow forwarding for all New and Established SNAT connections
# originating on the home network AND already established
# DNAT connections
 
iptables -A FORWARD -t filter -o eth0 -m state \
         --state NEW,ESTABLISHED,RELATED -j ACCEPT
 
# Allow forwarding for all 1:1 NAT connections originating on
# the Internet that have already passed through the NEW forwarding
# statements above
 
iptables -A FORWARD -t filter -i eth0 -m state \
         --state ESTABLISHED,RELATED -j ACCEPT

Troubleshooting iptables

A number of tools are at your disposal for troubleshooting iptables firewall scripts. One of the best methods is to log all dropped packets to the /var/log/messages file.

Checking The Firewall Logs

You track packets passing through the iptables list of rules using the LOG target. You should be aware that the LOG target:

• Logs all traffic that matches the iptables rule in which it is located.
• Automatically writes an entry to the /var/log/messages file and then executes the next rule.

If you want to log only unwanted traffic, therefore, you have to add a matching rule with a DROP target immediately after the LOG rule. If you don't, you'll find yourself logging both desired and unwanted traffic with no way of discerning between the two, because by default iptables doesn't state why the packet was logged in its log message.

This example logs a summary of failed packets to the file /var/log/messages. You can use the contents of this file to determine which TCP/UDP ports you need to open to provide access to specific traffic that is currently stopped.

#---------------------------------------------------------------
# Log and drop all other packets to file /var/log/messages
# Without this we could be crawling around in the dark
#---------------------------------------------------------------
 
iptables -A OUTPUT -j LOG
iptables -A INPUT -j LOG
iptables -A FORWARD -j LOG
 
iptables -A OUTPUT -j DROP
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP

Here are some examples of the output of this file:

• Firewall denies replies to DNS queries (UDP port 53) destined to server 192.168.1.102 on the home network.

Feb 23 20:33:50 bigboy kernel: IN=wlan0 OUT= MAC=00:06:25:09:69:80:00:a0:c5:e1:3e:88:08:00 SRC=192.42.93.30 DST=192.168.1.102 LEN=220 TOS=0x00 PREC=0x00 TTL=54 ID=30485 PROTO=UDP SPT=53 DPT=32820 LEN=200

• Firewall denies Windows NetBIOS traffic (UDP port 138)

Feb 23 20:43:08 bigboy kernel: IN=wlan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:06:25:09:6a:b5:08:00 SRC=192.168.1.100 DST=192.168.1.255 LEN=241 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=221

• Firewall denies Network Time Protocol (NTP UDP port 123)

Feb 23 20:58:48 bigboy kernel: IN= OUT=wlan0 SRC=192.168.1.102 DST=207.200.81.113 LEN=76 TOS=0x10 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=123 DPT=123 LEN=56

The traffic in all these examples isn't destined for the firewall; Therefore, you should check your INPUT, OUTPUT, FORWARD, and NAT related statements. If the firewall's IP address is involved, then you should focus on the INPUT and OUTPUT statements

If nothing shows up in the logs, then follow the steps in Chapter 4, "Simple Network Troubleshooting", to determine whether the data is reaching your firewall at all and, if it is not, the location on your network that could be causing the problem.

As a general rule, you won't be able to access the public NAT IP addresses from servers on your home network. Basic NAT testing requires you to ask a friend to try to connect to your home network from the Internet.

You can then use the logging output in /var/log/messages to make sure that the translations are occurring correctly and iptables isn't dropping the packets after translation occurs.

iptables Won't Start

The iptables startup script expects to find the /etc/sysconfig/iptables before it starts. If none exists, then symptoms include the firewall status always being stopped and the /etc/init.d/iptables script running without the typical [OK] or [FAILED] messages.

If you have just installed iptables and have never applied a policy, then you will face this problem. Unfortunately, running the service iptables save command before restarting won't help either. You have to create this file.

[root@bigboy tmp]# service iptables start
[root@bigboy tmp]#

[root@bigboy tmp]# touch /etc/sysconfig/iptables
[root@bigboy tmp]# chmod 600 /etc/sysconfig/iptables

[root@bigboy tmp]# service iptables start
Applying iptables firewall rules: [  OK  ]
[root@bigboy tmp]#

Conclusion

A firewall is a critical part of any establishment that connects to an unprotected network such as the Internet, but a firewall is never sufficient. Web site security involves not just protection from corrupted packets or maliciously overwhelming volumes of traffic, but also involves daily data backups to help recovery from device failures, regular application patching, enforced password policies, restricted and monitored physical access to your servers, reliable power and cooling, secured cabling, redundant hardware, and, probably most importantly, well trained and motivated employees. Security should be viewed as anything that contributes to the desired risk-free functioning of your site, and it is well worth the money to invest in and learn from a book that specializes in the topic.

Retrieved from "http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables"

NEWS CONTENTS

• 20210124 : 25 Useful IPtable Firewall Rules Every Linux Administrator Should Know by Marin Todorov ( Mar 01, 2016 , www.tecmint.com )
• 20181012 : How to Install Iptables on CentOS 7 ( Oct 12, 2018 , linuxize.com )
• 20181002 : 16 iptables tips and tricks for sysadmins Opensource.com ( Oct 02, 2018 , opensource.com )
• 20151205 : How to configure and Install Config Server Firewall & Login failure Daemon ( How to configure and Install Config Server Firewall & Login failure Daemon, Dec 05, 2015 )
• 20151205 : How to open a port on a Centos 5 server ( How to open a port on a Centos 5 server, )
• 20151205 : 10 quick tips to make Linux networking easier 10 Things TechRepublic.com ( 10 quick tips to make Linux networking easier 10 Things TechRepublic.com, )
• 20151205 : OSNews.com ( OSNews.com, )

Old News ;-)

[Jan 24, 2021] 25 Useful IPtable Firewall Rules Every Linux Administrator Should Know by Marin Todorov

Mar 01, 2016 | www.tecmint.com

Managing network traffic is one of the toughest jobs a system administrators has to deal with. He must configure the firewall in such a way that it will meet the system and users requirements for both incoming and outgoing connections, without leaving the system vulnerable to attacks.

This is where iptables come in handy. Iptables is a Linux command line firewall that allows system administrators to manage incoming and outgoing traffic via a set of configurable table rules.

Iptables uses a set of tables which have chains that contain set of built-in or user defined rules. Thanks to them a system administrator can properly filter the network traffic of his system.

Per iptables manual, there are currently 3 types of tables:

1. FILTER – this is the default table, which contains the built in chains for:
   1. INPUT – packages destined for local sockets
   2. FORWARD – packets routed through the system
   3. OUTPUT – packets generated locally
2. NAT – a table that is consulted when a packet tries to create a new connection. It has the following built-in:
   1. PREROUTING – used for altering a packet as soon as it's received
   2. OUTPUT – used for altering locally generated packets
   3. POSTROUTING – used for altering packets as they are about to go out
3. MANGLE – this table is used for packet altering. Until kernel version 2.4 this table had only two chains, but they are now 5:
   1. PREROUTING – for altering incoming connections
   2. OUTPUT – for altering locally generated packets
   3. INPUT – for incoming packets
   4. POSTROUTING – for altering packets as they are about to go out
   5. FORWARD – for packets routed through the box

In this article, you will see some useful commands that will help you manage your Linux box firewall through iptables. For the purpose of this article, I will start with simpler commands and go to more complex to the end.

First, you should know how to manage iptables service in different Linux distributions. This is fairly easy:

On SystemD based Linux Distributions

------------ On Cent/RHEL 7 and Fedora 22+ ------------
# systemctl start iptables
# systemctl stop iptables
# systemctl restart iptables

On SysVinit based Linux Distributions

------------ On Cent/RHEL 6/5 and Fedora ------------
# /etc/init.d/iptables start 
# /etc/init.d/iptables stop
# /etc/init.d/iptables restart

2. Check all IPtables Firewall Rules

If you want to check your existing rules, use the following command:

# iptables -L -n -v

This should return output similar to the one below:

Chain INPUT (policy ACCEPT 1129K packets, 415M bytes)
 pkts bytes target prot opt in out source destination 
 0 0 ACCEPT tcp -- lxcbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
 0 0 ACCEPT udp -- lxcbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
 0 0 ACCEPT tcp -- lxcbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
 0 0 ACCEPT udp -- lxcbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source destination 
 0 0 ACCEPT all -- * lxcbr0 0.0.0.0/0 0.0.0.0/0 
 0 0 ACCEPT all -- lxcbr0 * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 354K packets, 185M bytes)
 pkts bytes target prot opt in out source destination

If you prefer to check the rules for a specific table, you can use the -t option followed by the table which you want to check. For example, to check the rules in the NAT table, you can use:

# iptables -t nat -L -v -n

3. Block Specific IP Address in IPtables Firewall

If you find an unusual or abusive activity from an IP address you can block that IP address with the following rule:

# iptables -A INPUT -s xxx.xxx.xxx.xxx -j DROP

Where you need to change "xxx.xxx.xxx.xxx" with the actual IP address. Be very careful when running this command as you can accidentally block your own IP address. The -A option appends the rule in the end of the selected chain.

In case you only want to block TCP traffic from that IP address, you can use the -p option that specifies the protocol. That way the command will look like this:

# iptables -A INPUT -p tcp -s xxx.xxx.xxx.xxx -j DROP

4. Unblock IP Address in IPtables Firewall

If you have decided that you no longer want to block requests from specific IP address, you can delete the blocking rule with the following command:

# iptables -D INPUT -s xxx.xxx.xxx.xxx -j DROP

The -D option deletes one or more rules from the selected chain. If you prefer to use the longer option you can use --delete .

5. Block Specific Port on IPtables Firewall

Sometimes you may want to block incoming or outgoing connections on a specific port. It's a good security measure and you should really think on that matter when setting up your firewall.

To block outgoing connections on a specific port use:

# iptables -A OUTPUT -p tcp --dport xxx -j DROP

To allow incoming connections use:

# iptables -A INPUT -p tcp --dport xxx -j ACCEPT

In both examples change "xxx" with the actual port you wish to allow. If you want to block UDP traffic instead of TCP , simply change "tcp" with "udp" in the above iptables rule.

6. Allow Multiple Ports on IPtables using Multiport

You can allow multiple ports at once, by using multiport , below you can find such rule for both incoming and outgoing connections:

# iptables -A INPUT  -p tcp -m multiport --dports 22,80,443 -j ACCEPT
# iptables -A OUTPUT -p tcp -m multiport --sports 22,80,443 -j ACCEPT

7. Allow Specific Network Range on Particular Port on IPtables

You may want to limit certain connections on specific port to a given network. Let's say you want to allow outgoing connections on port 22 to network 192.168.100.0/24 .

You can do it with this command:

# iptables -A OUTPUT -p tcp -d 192.168.100.0/24 --dport 22 -j ACCEPT

8. Block Facebook on IPtables Firewall

Some employers like to block access to Facebook to their employees. Below is an example how to block traffic to Facebook.

Note : If you are a system administrator and need to apply these rules, keep in mind that your colleagues may stop talking to you :)

First find the IP addresses used by Facebook:

# host facebook.com 
facebook.com has address 66.220.156.68

# whois 66.220.156.68 | grep CIDR
CIDR: 66.220.144.0/20

You can then block that Facebook network with:

# iptables -A OUTPUT -p tcp -d 66.220.144.0/20 -j DROP

Keep in mind that the IP address range used by Facebook may vary in your country.

9. Setup Port Forwarding in IPtables

Sometimes you may want to forward one service's traffic to another port. You can achieve this with the following command:

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j REDIRECT --to-port 2525

The above command forwards all incoming traffic on network interface eth0 , from port 25 to port 2525 . You may change the ports with the ones you need.

10. Block Network Flood on Apache Port with IPtables

Sometimes IP addresses may requests too many connections towards web ports on your website. This can cause number of issues and to prevent such problems, you can use the following rule:

# iptables -A INPUT -p tcp --dport 80 -m limit --limit 100/minute --limit-burst 200 -j ACCEPT

The above command limits the incoming connections from per minute to 100 and sets a limit burst to 200 . You can edit the limit and limit-burst to your own specific requirements.

11. Block Incoming Ping Requests on IPtables

Some system administrators like to block incoming ping requests due to security concerns. While the threat is not that big, it's good to know how to block such request:

# iptables -A INPUT -p icmp -i eth0 -j DROP

12. Allow loopback Access

Loopback access (access from 127.0.0.1 ) is important and you should always leave it active:

# iptables -A INPUT -i lo -j ACCEPT
# iptables -A OUTPUT -o lo -j ACCEPT

13. Keep a Log of Dropped Network Packets on IPtables

If you want to log the dropped packets on network interface eth0 , you can use the following command:

# iptables -A INPUT -i eth0 -j LOG --log-prefix "IPtables dropped packets:"

You can change the value after "--log-prefix" with something by your choice. The messages are logged in /var/log/messages and you can search for them with:

# grep "IPtables dropped packets:" /var/log/messages

14. Block Access to Specific MAC Address on IPtables

You can block access to your system from specific MAC address by using:

# iptables -A INPUT -m mac --mac-source 00:00:00:00:00:00 -j DROP

Of course, you will need to change "00:00:00:00:00:00" with the actual MAC address that you want to block.

15. Limit the Number of Concurrent Connections per IP Address

If you don't want to have too many concurrent connection established from single IP address on given port you can use the command below:

# iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECT

The above command allows no more than 3 connections per client. Of course, you can change the port number to match different service. Also the --connlimit-above should be changed to match your requirement.

16. Search within IPtables Rule

Once you have defined your iptables rules, you will want to search from time to time and may need to alter them. An easy way to search within your rules is to use:

# iptables -L $table -v -n | grep $string

In the above example, you will need to change $table with the actual table within which you wish to search and $string with the actual string for which you are looking for.

Here is an example:

# iptables -L INPUT -v -n | grep 192.168.0.100

17. Define New IPTables Chain

With iptables, you can define your own chain and store custom rules in it. To define a chain, use:

# iptables -N custom-filter

Now you can check if your new filter is there:

# iptables -L

Sample Output

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain custom-filter (0 references)
target prot opt source destination

18. Flush IPtables Firewall Chains or Rules

If you want to flush your firewall chains, you can use:

# iptables -F

You can flush chains from specific table with:

# iptables -t nat -F

You can change "nat" with the actual table which chains you wish to flush.

19. Save IPtables Rules to a File

If you want to save your firewall rules, you can use the iptables-save command. You can use the following to save and store your rules in a file:

# iptables-save > ~/iptables.rules

It's up to you where will you store the file and how you will name it.

20. Restore IPtables Rules from a File

If you want to restore a list of iptables rules, you can use iptables-restore . The command looks like this:

# iptables-restore < ~/iptables.rules

Of course the path to your rules file might be different.

21. Setup IPtables Rules for PCI Compliance

Some system administrators might be required to configure their servers to be PCI compiliant. There are many requirements by different PCI compliance vendors, but there are few common ones.

In many of the cases, you will need to have more than one IP address. You will need to apply the rules below for the site's IP address. Be extra careful when using the rules below and use them only if you are sure what you are doing:

# iptables -I INPUT -d SITE -p tcp -m multiport --dports 21,25,110,143,465,587,993,995 -j DROP

If you use cPanel or similar control panel, you may need to block it's' ports as well. Here is an example:

# iptables -I in_sg -d DEDI_IP -p tcp -m multiport --dports  2082,2083,2095,2096,2525,2086,2087 -j DROP

Note : To make sure you meet your PCI vendor's requirements, check their report carefully and apply the required rules. In some cases you may need to block UDP traffic on certain ports as well.

22. Allow Established and Related Connections

As the network traffic is separate on incoming and outgoing, you will want to allow established and related incoming traffic. For incoming connections do it with:

# iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

For outgoing use:

# iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

23. Drop Invalid Packets in IPtables

It's possible to have some network packets marked as invalid. Some people may prefer to log those packages, but others prefer to drop them. To drop invalid the packets, you can use:

# iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

24. Block Connection on Network Interface

Some systems may have more than one network interface. You can limit the access to that network interface or block connections from certain IP address.

For example:

# iptables -A INPUT -i eth0 -s xxx.xxx.xxx.xxx -j DROP

Change "xxx.xxx.xxx.xxx" with the actual IP address (or network) that you wish to block.

25. Disable Outgoing Mails through IPTables

If your system should not be sending any emails, you can block outgoing ports on SMTP ports. For example you can use this:

# iptables -A OUTPUT -p tcp --dports 25,465,587 -j REJECT

Conclusion

Iptables is a powerful firewall that you can easily benefit from. It is vital for every system administrator to learn at least the basics of iptables . If you want to find more detailed information about iptables and its options it is highly recommend to read it's manual:

# man iptables

If you think we should add more commands to this list, please share them with us, by submitting them in the comment section below. Tags Iptables

[Oct 12, 2018] How to Install Iptables on CentOS 7

Oct 12, 2018 | linuxize.com

Starting with CentOS 7, FirewallD replaces iptables as the default firewall management tool.

FirewallD is a complete firewall solution that can be controlled with a command-line utility called firewall-cmd. If you are more comfortable with the Iptables command line syntax, then you can disable FirewallD and go back to the classic iptables setup.

This tutorial will show you how to disable the FirewallD service and install iptables.

Prerequisites

Before starting with the tutorial, make sure you are logged in as a user with sudo privileges .

Disable FirewallD

To disable the FirewallD on your CentOS 7 system , follow these steps:

1. Type the following command to stop the FirewallD service:

   sudo systemctl stop firewalld
   

   Copy
2. Disable the FirewallD service to start automatically on system boot:

   sudo systemctl disable firewalld
   

   Copy
3. Mask the FirewallD service to prevent it from being started by another services:

   sudo systemctl mask --now firewalld
   

   Copy

Install and Enable Iptables

Perform the following steps to install Iptables on a CentOS 7 system:

1. Run the following command to install the iptables-service package from the CentOS repositories:

   sudo yum install iptables-services
   

   Copy
2. Once the package is installed start the Iptables service:

   sudo systemctl start iptables
   sudo systemctl start iptables6
   

   Copy
3. Enable the Iptables service to start automatically on system boot:

   sudo systemctl enable iptables
   sudo systemctl enable iptables6
   

   Copy
4. Check the iptables service status with:

   sudo systemctl status iptables
   sudo systemctl status iptables6
   

   Copy
5. To can check the current iptables rules use the following commands:

   sudo iptables -nvL
   sudo iptables6 -nvL
   

   Copy

   By default only the SSH port 22 is open. The output should look something like this:

   Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target     prot opt in     out     source               destination         
    5400 6736K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
       0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
       2   148 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
       3   180 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
       0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
   
   Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target     prot opt in     out     source               destination         
       0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
   
   Chain OUTPUT (policy ACCEPT 4298 packets, 295K bytes)
    pkts bytes target     prot opt in     out     source               destination
   

   Copy

At this point, you have successfully enabled the iptables service and you can start building your firewall. The changes will persist after reboot.

Conclusion

In this tutorial, you learned how to disable the FirewallD service and install iptables.

If you have any question or remarks, please leave a comment below.

[Oct 02, 2018] 16 iptables tips and tricks for sysadmins Opensource.com

Oct 02, 2018 | opensource.com

Avoid locking yourself out

Scenario: You are going to make changes to the iptables policy rules on your company's primary server. You want to avoid locking yourself -- and potentially everybody else -- out. (This costs time and money and causes your phone to ring off the wall.)

Tip #1: Take a backup of your iptables configuration before you start working on it.

Back up your configuration with the command:

/sbin/iptables-save > /root/iptables-works

Tip #2: Even better, include a timestamp in the filename.

Add the timestamp with the command:

/sbin/iptables-save > /root/iptables-works-`date +%F`

You get a file with a name like:

/root/iptables-works-2018-09-11

If you do something that prevents your system from working, you can quickly restore it:

/sbin/iptables-restore < /root/iptables-works-2018-09-11

Tip #3: Every time you create a backup copy of the iptables policy, create a link to the file with 'latest' in the name.

ln –s /root/iptables-works-`date +%F` /root/iptables-works-latest

Tip #4: Put specific rules at the top of the policy and generic rules at the bottom.

Avoid generic rules like this at the top of the policy rules:

iptables -A INPUT -p tcp --dport 22 -j DROP

The more criteria you specify in the rule, the less chance you will have of locking yourself out. Instead of the very generic rule above, use something like this:

iptables -A INPUT -p tcp --dport 22 –s 10.0.0.0/8 –d 192.168.100.101 -j DROP

This rule appends ( -A ) to the INPUT chain a rule that will DROP any packets originating from the CIDR block 10.0.0.0/8 on TCP ( -p tcp ) port 22 ( --dport 22 ) destined for IP address 192.168.100.101 ( -d 192.168.100.101 ).

There are plenty of ways you can be more specific. For example, using -i eth0 will limit the processing to a single NIC in your server. This way, the filtering actions will not apply the rule to eth1 .

Tip #5: Whitelist your IP address at the top of your policy rules.

This is a very effective method of not locking yourself out. Everybody else, not so much.

iptables -I INPUT -s <your IP> -j ACCEPT

You need to put this as the first rule for it to work properly. Remember, -I inserts it as the first rule; -A appends it to the end of the list.

Tip #6: Know and understand all the rules in your current policy.

Not making a mistake in the first place is half the battle. If you understand the inner workings behind your iptables policy, it will make your life easier. Draw a flowchart if you must. Also remember: What the policy does and what it is supposed to do can be two different things.

Set up a workstation firewall policy

Scenario: You want to set up a workstation with a restrictive firewall policy.

Tip #1: Set the default policy as DROP. # Set a default policy of DROP
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0] Tip #2: Allow users the minimum amount of services needed to get their work done.

The iptables rules need to allow the workstation to get an IP address, netmask, and other important information via DHCP ( -p udp --dport 67:68 --sport 67:68 ). For remote management, the rules need to allow inbound SSH ( --dport 22 ), outbound mail ( --dport 25 ), DNS ( --dport 53 ), outbound ping ( -p icmp ), Network Time Protocol ( --dport 123 --sport 123 ), and outbound HTTP ( --dport 80 ) and HTTPS ( --dport 443 ).

# Set a default policy of DROP
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

# Accept any related or established connections
-I INPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow all traffic on the loopback interface
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

# Allow outbound DHCP request
-A OUTPUT –o eth0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT

# Allow inbound SSH
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT

# Allow outbound email
-A OUTPUT -i eth0 -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT

# Outbound DNS lookups
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT

# Outbound PING requests
-A OUTPUT –o eth0 -p icmp -j ACCEPT

# Outbound Network Time Protocol (NTP) requests
-A OUTPUT –o eth0 -p udp --dport 123 --sport 123 -j ACCEPT

# Outbound HTTP
-A OUTPUT -o eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT

COMMIT

Restrict an IP address range

Scenario: The CEO of your company thinks the employees are spending too much time on Facebook and not getting any work done. The CEO tells the CIO to do something about the employees wasting time on Facebook. The CIO tells the CISO to do something about employees wasting time on Facebook. Eventually, you are told the employees are wasting too much time on Facebook, and you have to do something about it. You decide to block all access to Facebook. First, find out Facebook's IP address by using the host and whois commands.

host -t a www.facebook.com
www.facebook.com is an alias for star.c10r.facebook.com.
star.c10r.facebook.com has address 31.13.65.17
whois 31.13.65.17 | grep inetnum
inetnum: 31.13.64.0 - 31.13.127.255

Then convert that range to CIDR notation by using the CIDR to IPv4 Conversion page. You get 31.13.64.0/18 . To prevent outgoing access to www.facebook.com , enter:

iptables -A OUTPUT -p tcp -i eth0 –o eth1 –d 31.13.64.0/18 -j DROP

Regulate by time

Scenario: The backlash from the company's employees over denying access to Facebook access causes the CEO to relent a little (that and his administrative assistant's reminding him that she keeps HIS Facebook page up-to-date). The CEO decides to allow access to Facebook.com only at lunchtime (12PM to 1PM). Assuming the default policy is DROP, use iptables' time features to open up access.

iptables –A OUTPUT -p tcp -m multiport --dport http,https -i eth0 -o eth1 -m time --timestart 12:00 --timestart 12:00 –timestop 13:00 –d
31.13.64.0/18 -j ACCEPT

This command sets the policy to allow ( -j ACCEPT ) http and https ( -m multiport --dport http,https ) between noon ( --timestart 12:00 ) and 13PM ( --timestop 13:00 ) to Facebook.com ( –d 31.13.64.0/18 ).

Regulate by time -- Take 2

Scenario: During planned downtime for system maintenance, you need to deny all TCP and UDP traffic between the hours of 2AM and 3AM so maintenance tasks won't be disrupted by incoming traffic. This will take two iptables rules:

iptables -A INPUT -p tcp -m time --timestart 02:00 --timestop 03:00 -j DROP
iptables -A INPUT -p udp -m time --timestart 02:00 --timestop 03:00 -j DROP

With these rules, TCP and UDP traffic ( -p tcp and -p udp ) are denied ( -j DROP ) between the hours of 2AM ( --timestart 02:00 ) and 3AM ( --timestop 03:00 ) on input ( -A INPUT ).

Limit connections with iptables

Scenario: Your internet-connected web servers are under attack by bad actors from around the world attempting to DoS (Denial of Service) them. To mitigate these attacks, you restrict the number of connections a single IP address can have to your web server:

iptables –A INPUT –p tcp –syn -m multiport -–dport http,https –m connlimit -–connlimit-above 20 –j REJECT -–reject-with-tcp-reset

Let's look at what this rule does. If a host makes more than 20 ( -–connlimit-above 20 ) new connections ( –p tcp –syn ) in a minute to the web servers ( -–dport http,https ), reject the new connection ( –j REJECT ) and tell the connecting host you are rejecting the connection ( -–reject-with-tcp-reset ).

Monitor iptables rules

Scenario: Since iptables operates on a "first match wins" basis as packets traverse the rules in a chain, frequently matched rules should be near the top of the policy and less frequently matched rules should be near the bottom. How do you know which rules are traversed the most or the least so they can be ordered nearer the top or the bottom?

Tip #1: See how many times each rule has been hit.

Use this command:

iptables -L -v -n –line-numbers

The command will list all the rules in the chain ( -L ). Since no chain was specified, all the chains will be listed with verbose output ( -v ) showing packet and byte counters in numeric format ( -n ) with line numbers at the beginning of each rule corresponding to that rule's position in the chain.

Using the packet and bytes counts, you can order the most frequently traversed rules to the top and the least frequently traversed rules towards the bottom.

Tip #2: Remove unnecessary rules.

Which rules aren't getting any matches at all? These would be good candidates for removal from the policy. You can find that out with this command:

iptables -nvL | grep -v "0     0"

Note: that's not a tab between the zeros; there are five spaces between the zeros.

Tip #3: Monitor what's going on.

You would like to monitor what's going on with iptables in real time, like with top . Use this command to monitor the activity of iptables activity dynamically and show only the rules that are actively being traversed:

watch --interval=5 'iptables -nvL | grep -v "0     0"'

watch runs 'iptables -nvL | grep -v "0 0"' every five seconds and displays the first screen of its output. This allows you to watch the packet and byte counts change over time.

Report on iptables

Scenario: Your manager thinks this iptables firewall stuff is just great, but a daily activity report would be even better. Sometimes it's more important to write a report than to do the work.

Use the packet filter/firewall/IDS log analyzer FWLogwatch to create reports based on the iptables firewall logs. FWLogwatch supports many log formats and offers many analysis options. It generates daily and monthly summaries of the log files, allowing the security administrator to free up substantial time, maintain better control over network security, and reduce unnoticed attacks.

Here is sample output from FWLogwatch:

fwlogwatch.png More than just ACCEPT and DROP

We've covered many facets of iptables, all the way from making sure you don't lock yourself out when working with iptables to monitoring iptables to visualizing the activity of an iptables firewall. These will get you started down the path to realizing even more iptables tips and tricks.

[Dec 05, 2015] How to configure and Install Config Server Firewall & Login failure Daemon

I use Config Server Firewall (CFG) and Login Failure deamon (LFD) because they are easy to set up and provide additional features like suspicious file reporting and system monitoring.

Istimsak

Other then the features and how simple it looks to configure, what inspired you blog about CSF? What made CFS stand out to you.

Leo G > Istimsak

Lots of features, go through the features page on the csf website, One I personally like is change to any file you are notified immediately.

How to open a port on a Centos 5 server

04-15-2009

swamprat

I would like to use tightvnc to connect from my windows xp box to the centos 5 box.

How do I check to see if ports 5800 and 5900 are open and if not how can I open them so I can connect from windows to centos.

Thanks

MensaWater

There are really 2 questions here:

1. Is anything LISTENING on the ports you mention? You can find that out with

    "lsof -i :<port_no>" 

2. The other is the one you asked. CentOS by default uses iptables as a firewall and by default only allows outbound traffic.

You can run "iptables -L" to see if it is on or off.

If it is "off" then you'll usually only see 3 items in the list such as:
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

If it is "on" you'll see a lot more output like:
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

You can stop iptables by running: service iptables stop
You can start it by running: service iptables start.

I'd suggest stopping iptables then starting the vnc service and do the lsof check I mentioned. Then do your attempt to attach from XP. If it works then restart iptables and check again.

You can add the ports to iptables generally by following this procedure:

First verify iptables is running with iptables -L and that its last entry is to vlock icmp.

1) iptables -D RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
### Deletes the icmp rule

2) iptables -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 5800 -j ACCEPT
### Opens TCP port 5800 for inbound connections.

3) iptables -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 5900 -j ACCEPT
### Opens TCP port 5900 for inbound connections.

4) iptables -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
### Readds the icmp rule as last rule.

5) iptables-save >/etc/sysconfig/iptables
### Saves to file read on iptables start.

Also you probably want to add port 5800 and 5900 to /etc/services file if they're not already there.

maresmasb

Just one additional note: You are running a virtual CentOS via VMware on a Windows box, so make sure that you have the VMware network settings work correctly to access the virtual system from your host, before trying to hunt down a problem in CentOS that happens outside of it.

r3sistance

If you can SSH to the server, use an SSH tunnel, bypasses the firewall but keeps things more secure and locked up, also gets around certain weaknesses in VNC. For example, all VNC sessions use a different port for each session, so you would need to open/close the ports as needed by vnc-server for the vnc sessions to be connectable, the other thing to think about is if your vnc sessions are encrypted or not.

10 quick tips to make Linux networking easier 10 Things TechRepublic.com

You can't assume that just because you are using Linux, you are secure. You still need some security. And the best security you can have with Linux is iptables. The only problem with iptables is that it can be challenging (especially for the new user). Fortunately, there are outstanding graphical front ends for iptables. One of the best is Firestarter. This front end makes employing iptables a simple process, so you won't keep bypassing security out of fear of the learning curve.

OSNews.com

iptables: the Linux Firewall Administration Program

Linked by Eugenia Loli-Queru on 2005-11-27 22:10:21 UTC

This chapter covers the iptables firewall administration program used to build a Netfilter firewall. For those of you who are familiar with or accustomed to the older ipfwadm and ipchains programs used with the IPFW technology, iptables will look very similar to those programs. However, it is much more feature-rich and flexible, and it is very different on subtle levels.

Filter filter on the wall ...

moleskine (2.04) on 2005-11-27 23:32:47 UTC

... Who's the geekiest of the all? This looks extremely useful - a web article with some real meat in it for a change - and I've downloaded the printer-friendly version for study later. However, I wonder how many folks other than IT professionals really get to grips with IP tables when there are excellent programs like Shoreline (Shorewall) that do it all for you (or IPCop and the like on dedicated boxes)? I guess a little knowledge could be a dangerous thing if you make mistakes with DIY scripts around basic security like a good firewall.<

Shameless plug...

defile (1.21) on 2005-11-27 23:46:38 UTC

If you're looking to manage iptables rulesets without the learning curve of rolling your own (or even if you fully comprehend iptables, but want an easy method to manage them), check out

http://www.killerwall.net/

It is a distro agnostic tool that may simplify your life. In spite of the lack of a GUI, it's still extremely easy to configure and deploy. Some key features include:

1). It scales well. It can be used as a host based firewall or a multi-homed, multiple network NAT bastion host. It can autoconfigure itself (or you can do it manually) for either situation based on your network configuration.

2). It's fast. For what it does, it generates a high performance, lean ruleset.

3). It defaults to all ports closed to inbound, unsolicited packets, but it's stateful, so it allows replies for data you've sent to come back in.

4). If you want ports opened or forwarded, it's easy to do. Even if you do have ports opened, remote hosts will be unable actively TCP finger print your firewall or forwarded hosts.

5). It has an ACL feature that you can configure to allow only certain hosts or networks access to ports or protocols. The ACL rulesets can be manipulated independently of the baseline firewall ruleset.

6). It's easy to use.

If you like what you've read so far, I recommend the CVS version at:

http://www.killerwall.net/download/killerwall.0.99-CVS-03Jan05-0552...

Read the README included the tarball, it explains what to do in detail.

By Anonymous (IP: 24.126.56.---) on 2005-11-28 01:07:06 UTC

but how does IPTables compare to OpenBSD's PF? I really don't use Linux so I'm not familiar with anything Linux related. Some insight into the similarities/differences would be greatly appreciated.

Obviously, I'm looking for answers from people that are experienced in both IPTables and OpenBSD's PF.

Thanks!

By Anonymous (IP: 68.121.110.---) on 2005-11-28 01:19:36 UTC in reply to "Just curious..."

I use both-- admin several redhat oracle dbs. IMHO, iptables is primative compare to pf on OpenBSD and FreeBSD. Just read the fine docs to get a understaning of the different features.

By Milo_Hoffman (1.63) on 2005-11-28 01:25:29 UTC

I used to use OpenBSD on our firewalls for years. I really love pf. It's syntax always made 100x more sense to me than IPtables. Its much easier to read.

However, IPtables in Linux does have some advantages over pf. For one it's quite a bit faster than pf. And the big one for me and the reason I moved to using a Linux firewall is that iptables can use external modules to handle work for special applications. There are external modules in Linux for making things that normally can't be NATed very well work much better like FTP, VoIP, and IPsec etc.

Having spent so much time learning about how to manage a firewall using pf really helped in picking up iptables. Of course even iptables is not all that hard compared to ipchains which Linux used to use back when I first started using openbsd.

RE: PF vs IPTables

By Anonymous (IP: 71.248.4.---) on 2005-11-28 01:50:25 UTC in reply to "PF vs IPTables"

I'd love to see more than anecdotal evidence suggesting iptables is faster than PF. There was a paper _years_ ago that compared iptables, ipfilter and PF; at the time, iptables was marginally faster because it wasn't tracking states properly.

I don't see any advantage to the netfilter modules, with the possible exception of L7 filtering. There is a built-in ftp proxy, QoS support (for VoIP), and IPsec filtering native to PF. Not to mention a lot of other features that Linux/iptables can't touch... pfsync (stateful synchronization), sasyncd (IPsec SA synchronization), etc.

-jd

By Anonymous (IP: 130.102.0.---) on 2005-11-28 02:05:01 UTC

www.iptablesrocks.org

Expensive book

By Richard James (1.30) on 2005-11-28 02:28:34 UTC

$44.99 USD
Only covers Linux Firewalls. Maybe they should have had some advanced routing or maybe it does but the cover says firewalls.

RE: Expensive book

By Anonymous (IP: 69.193.158.---) on 2005-11-28 04:41:23 UTC in reply to "Expensive book"

I wouldn't buy it if it did have advanced routing topics. http://lartc.org/largc is all I need.

Firetable

By Anonymous (IP: 84.35.75.---) on 2005-11-28 08:39:47 UTC

An advanced script I wrote to handle iptables firewalls in a very easy way:

http://projects.leisink.org/index.php?page=firetable

RE: Just curious...

By Anonymous (IP: 128.240.229.---) on 2005-11-28 09:46:24 UTC in reply to "Just curious..."

Coming from the other side, as someone with experience of iptables, I'd like to see a comparison with BSD's pf, as I've heard good things about it.

RE: Just curious...

By Anonymous (IP: 62.89.180.---) on 2005-11-28 10:05:44 UTC in reply to "Just curious..."

Except the functionality provided by netfilter extension modules pf is at least equal.

I prefer pf over netfilter because of its better human readable ruleset file. It's much more straight then a iptables command.

And i don't know a tool like pftop for linux. May be someone will show of one?!

polarizers 2 cent
http://www.codixx.de/polarizer.html

RE[2]: PF vs IPTables

By Anonymous (IP: 60.225.104.---) on 2005-11-28 11:58:03 UTC in reply to "RE: PF vs IPTables"

OpenBSD is about security over anything else, so a slight
performance loss for more security features is to be
expected.

I don't mind using either IPTables or PF. They do the
job I need them to do.

RE: PF vs IPTables

By Anonymous (IP: 87.227.18.---) on 2005-11-28 12:10:25 UTC

Just a little correction to this thread:

pf hasn't got an internal FTP proxy. It defers FTP to an external "module" (a separate program) called ftp-proxy.

While I don't know anything about the relative speed of the two, I think there were some major speedups in pf's favor in the OpenBSD 3.7 timeframe, at least for some operations. Ref. e.g.:
http://www.openbsd.org/faq/pf/tables.html

RE[2]: Just curious...

By Anonymous (IP: 219.89.189.---) on 2005-11-29 08:04:06 UTC in reply to "RE: Just curious..."

you may like to check out iptraf

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Quick HOWTO Ch14 Linux Firewalls Using iptables - Linux Home Networking
• iptables Howto - Fedora Unity Project
• RedHat | HowtoForge - Linux Howtos and ...
• IptablesHowTo - Community Ubuntu Documentation
• iptables - Debian Wiki
• 25 Most Frequently Used Linux IPTables Rules Examples
• 42.8. Firewalls

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: October 13, 2018