LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 02-04-2011, 11:22 PM   #1
ewsmith
Member
 
Registered: Oct 2010
Location: Weesatche, Texas
Distribution: Slackware
Posts: 72

Rep: Reputation: 7
iptables config - second opinions needed


the title says it all. im on slackware 13.1.
any opinions on improving my config will be greatly appreciated.

Code:
#!/bin/bash

#######################################
#        Specific DROP Rules          #
#######################################
iptables -A INPUT -p tcp -m state --state NEW -j LOG
iptables -A INPUT -p tcp -m state --state NEW -j DROP
iptables -A INPUT -m state --state INVALID -j LOG
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -m state --state UNTRACKED -j LOG
iptables -A INPUT -m state --state UNTRACKED -j DROP

#######################################
#       Specific ACCEPT Rules         #
#######################################
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i wlan0 ACCEPT
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 ACCEPT

#######################################
#           Global Rules              #
#######################################
iptables -P INPUT -j DROP
iptables -P FORWARD -j DROP
iptables -P OUTPUT -j ACCEPT
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 02-05-2011, 01:13 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966
the very thing thing you do is log and drop ALL new TCP connections... that's just going to stop all tcp connections, regardless of the rest of the rules.
 
Old 02-05-2011, 05:46 AM   #3
xeleema
Member
 
Registered: Aug 2005
Location: D.i.t.h.o, Texas
Distribution: Slackware 13.x, rhel3/5, Solaris 8-10(sparc), HP-UX 11.x (pa-risc)
Posts: 987
Blog Entries: 4

Rep: Reputation: 249Reputation: 249Reputation: 249
Greetingz!

I think you'd benefit by using a wizard to generate the basic iptables script, then add your customizations.
Easy Firewall Generator for IPTables v1.17 (11may2005)

It does a pretty good job. I've attached an example of the results;
Code:
#!/bin/sh
#
# Generated iptables firewall script for the Linux 2.4 kernel
# Script generated by Easy Firewall Generator for IPTables 1.15
# copyright 2002 Timothy Scott Morizot
# 
# Redhat chkconfig comments - firewall applied early,
#                             removed late
# chkconfig: 2345 08 92
# description: This script applies or removes iptables firewall rules
# 
# This generator is primarily designed for RedHat installations,
# although it should be adaptable for others.
#
# It can be executed with the typical start and stop arguments.
# If used with stop, it will stop after flushing the firewall.
# The save and restore arguments will save or restore the rules
# from the /etc/sysconfig/iptables file.  The save and restore
# arguments are included to preserve compatibility with
# Redhat's or Fedora's init.d script if you prefer to use it.

# Redhat/Fedora installation instructions
#
# 1. Have the system link the iptables init.d startup script into run states
#    2, 3, and 5.
#    chkconfig --level 235 iptables on
#
# 2. Save this script and execute it to load the ruleset from this file.
#    You may need to run the dos2unix command on it to remove carraige returns.
#
# 3. To have it applied at startup, copy this script to
#    /etc/init.d/iptables.  It accepts stop, start, save, and restore
#    arguments.  (You may wish to save the existing one first.)
#    Alternatively, if you issue the 'service iptables save' command
#    the init.d script should save the rules and reload them at runtime.
#
# 4. For non-Redhat systems (or Redhat systems if you have a problem), you
#    may want to append the command to execute this script to rc.local.
#    rc.local is typically located in /etc and /etc/rc.d and is usually
#    the last thing executed on startup.  Simply add /path/to/script/script_name
#    on its own line in the rc.local file.

###############################################################################
# 
# Local Settings
#

# sysctl location.  If set, it will use sysctl to adjust the kernel parameters.
# If this is set to the empty string (or is unset), the use of sysctl
# is disabled.

SYSCTL="/sbin/sysctl -w" 

# To echo the value directly to the /proc file instead
# SYSCTL=""

# IPTables Location - adjust if needed

IPT="/sbin/iptables"
IPTS="/sbin/iptables-save"
IPTR="/sbin/iptables-restore"

# Internet Interface
INET_IFACE="eth0"
INET_ADDRESS="172.16.0.1"

# Localhost Interface

LO_IFACE="lo"
LO_IP="127.0.0.1"

# Save and Restore arguments handled here
if [ "$1" = "save" ]
then
	echo -n "Saving firewall to /etc/sysconfig/iptables ... "
	$IPTS > /etc/sysconfig/iptables
	echo "done"
	exit 0
elif [ "$1" = "restore" ]
then
	echo -n "Restoring firewall from /etc/sysconfig/iptables ... "
	$IPTR < /etc/sysconfig/iptables
	echo "done"
	exit 0
fi

###############################################################################
#
# Load Modules
#

echo "Loading kernel modules ..."

# You should uncomment the line below and run it the first time just to
# ensure all kernel module dependencies are OK.  There is no need to run
# every time, however.

# /sbin/depmod -a

# Unless you have kernel module auto-loading disabled, you should not
# need to manually load each of these modules.  Other than ip_tables,
# ip_conntrack, and some of the optional modules, I've left these
# commented by default.  Uncomment if you have any problems or if
# you have disabled module autoload.  Note that some modules must
# be loaded by another kernel module.

# core netfilter module
/sbin/modprobe ip_tables

# the stateful connection tracking module
/sbin/modprobe ip_conntrack

# filter table module
# /sbin/modprobe iptable_filter

# mangle table module
# /sbin/modprobe iptable_mangle

# nat table module
# /sbin/modprobe iptable_nat

# LOG target module
# /sbin/modprobe ipt_LOG

# This is used to limit the number of packets per sec/min/hr
# /sbin/modprobe ipt_limit

# masquerade target module
# /sbin/modprobe ipt_MASQUERADE

# filter using owner as part of the match
# /sbin/modprobe ipt_owner

# REJECT target drops the packet and returns an ICMP response.
# The response is configurable.  By default, connection refused.
# /sbin/modprobe ipt_REJECT

# This target allows packets to be marked in the mangle table
# /sbin/modprobe ipt_mark

# This target affects the TCP MSS
# /sbin/modprobe ipt_tcpmss

# This match allows multiple ports instead of a single port or range
# /sbin/modprobe multiport

# This match checks against the TCP flags
# /sbin/modprobe ipt_state

# This match catches packets with invalid flags
# /sbin/modprobe ipt_unclean

# The ftp nat module is required for non-PASV ftp support
/sbin/modprobe ip_nat_ftp

# the module for full ftp connection tracking
/sbin/modprobe ip_conntrack_ftp

# the module for full irc connection tracking
/sbin/modprobe ip_conntrack_irc


###############################################################################
#
# Kernel Parameter Configuration
#
# See http://ipsysctl-tutorial.frozentux.net/chunkyhtml/index.html
# for a detailed tutorial on sysctl and the various settings
# available.

# Required to enable IPv4 forwarding.
# Redhat users can try setting FORWARD_IPV4 in /etc/sysconfig/network to true
# Alternatively, it can be set in /etc/sysctl.conf
#if [ "$SYSCTL" = "" ]
#then
#    echo "1" > /proc/sys/net/ipv4/ip_forward
#else
#    $SYSCTL net.ipv4.ip_forward="1"
#fi

# This enables dynamic address hacking.
# This may help if you have a dynamic IP address \(e.g. slip, ppp, dhcp\).
#if [ "$SYSCTL" = "" ]
#then
#    echo "1" > /proc/sys/net/ipv4/ip_dynaddr
#else
#    $SYSCTL net.ipv4.ip_dynaddr="1"
#fi

# This enables SYN flood protection.
# The SYN cookies activation allows your system to accept an unlimited
# number of TCP connections while still trying to give reasonable
# service during a denial of service attack.
if [ "$SYSCTL" = "" ]
then
    echo "1" > /proc/sys/net/ipv4/tcp_syncookies
else
    $SYSCTL net.ipv4.tcp_syncookies="1"
fi

# This enables source validation by reversed path according to RFC1812.
# In other words, did the response packet originate from the same interface
# through which the source packet was sent?  It's recommended for single-homed
# systems and routers on stub networks.  Since those are the configurations
# this firewall is designed to support, I turn it on by default.
# Turn it off if you use multiple NICs connected to the same network.
if [ "$SYSCTL" = "" ]
then
    echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
else
    $SYSCTL net.ipv4.conf.all.rp_filter="1"
fi

# This option allows a subnet to be firewalled with a single IP address.
# It's used to build a DMZ.  Since that's not a focus of this firewall
# script, it's not enabled by default, but is included for reference.
# See: http://www.sjdjweis.com/linux/proxyarp/ 
#if [ "$SYSCTL" = "" ]
#then
#    echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#else
#    $SYSCTL net.ipv4.conf.all.proxy_arp="1"
#fi

# The following kernel settings were suggested by Alex Weeks. Thanks!

# This kernel parameter instructs the kernel to ignore all ICMP
# echo requests sent to the broadcast address.  This prevents
# a number of smurfs and similar DoS nasty attacks.
if [ "$SYSCTL" = "" ]
then
    echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
else
    $SYSCTL net.ipv4.icmp_echo_ignore_broadcasts="1"
fi

# This option can be used to accept or refuse source routed
# packets.  It is usually on by default, but is generally
# considered a security risk.  This option turns it off.
if [ "$SYSCTL" = "" ]
then
    echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
else
    $SYSCTL net.ipv4.conf.all.accept_source_route="0"
fi

# This option can disable ICMP redirects.  ICMP redirects
# are generally considered a security risk and shouldn't be
# needed by most systems using this generator.
#if [ "$SYSCTL" = "" ]
#then
#    echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
#else
#    $SYSCTL net.ipv4.conf.all.accept_redirects="0"
#fi

# However, we'll ensure the secure_redirects option is on instead.
# This option accepts only from gateways in the default gateways list.
if [ "$SYSCTL" = "" ]
then
    echo "1" > /proc/sys/net/ipv4/conf/all/secure_redirects
else
    $SYSCTL net.ipv4.conf.all.secure_redirects="1"
fi

# This option logs packets from impossible addresses.
if [ "$SYSCTL" = "" ]
then
    echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
else
    $SYSCTL net.ipv4.conf.all.log_martians="1"
fi


###############################################################################
#
# Flush Any Existing Rules or Chains
#

echo "Flushing Tables ..."

# Reset Default Policies
$IPT -P INPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT
$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT

# Flush all rules
$IPT -F
$IPT -t nat -F
$IPT -t mangle -F

# Erase all non-default chains
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

if [ "$1" = "stop" ]
then
	echo "Firewall completely flushed!  Now running with no firewall."
	exit 0
fi

###############################################################################
#
# Rules Configuration
#

###############################################################################
#
# Filter Table
#
###############################################################################

# Set Policies

$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

###############################################################################
#
# User-Specified Chains
#
# Create user chains to reduce the number of rules each packet
# must traverse.

echo "Create and populate custom rule chains ..."

# Create a chain to filter INVALID packets

$IPT -N bad_packets

# Create another chain to filter bad tcp packets

$IPT -N bad_tcp_packets

# Create separate chains for icmp, tcp (incoming and outgoing),
# and incoming udp packets.

$IPT -N icmp_packets

# Used for UDP packets inbound from the Internet
$IPT -N udp_inbound

# Used to block outbound UDP services from internal network
# Default to allow all
$IPT -N udp_outbound

# Used to allow inbound services if desired
# Default fail except for established sessions
$IPT -N tcp_inbound

# Used to block outbound services from internal network
# Default to allow all
$IPT -N tcp_outbound

###############################################################################
#
# Populate User Chains
#

# bad_packets chain
#

# Drop INVALID packets immediately
$IPT -A bad_packets -p ALL -m state --state INVALID -j LOG \
    --log-prefix "Invalid packet: "

$IPT -A bad_packets -p ALL -m state --state INVALID -j DROP

# Then check the tcp packets for additional problems
$IPT -A bad_packets -p tcp -j bad_tcp_packets

# All good, so return
$IPT -A bad_packets -p ALL -j RETURN

# bad_tcp_packets chain
#
# All tcp packets will traverse this chain.
# Every new connection attempt should begin with
# a syn packet.  If it doesn't, it is likely a
# port scan.  This drops packets in state
# NEW that are not flagged as syn packets.


$IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
    --log-prefix "New not syn: "
$IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j LOG \
    --log-prefix "Stealth scan: "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j DROP

$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j LOG \
    --log-prefix "Stealth scan: "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j DROP

$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG \
    --log-prefix "Stealth scan: "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP

$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j LOG \
    --log-prefix "Stealth scan: "
$IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP

$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j LOG \
    --log-prefix "Stealth scan: "
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG \
    --log-prefix "Stealth scan: "
$IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

# All good, so return
$IPT -A bad_tcp_packets -p tcp -j RETURN

# icmp_packets chain
#
# This chain is for inbound (from the Internet) icmp packets only.
# Type 8 (Echo Request) is not accepted by default
# Enable it if you want remote hosts to be able to reach you.
# 11 (Time Exceeded) is the only one accepted
# that would not already be covered by the established
# connection rule.  Applied to INPUT on the external interface.
# 
# See: http://www.ee.siue.edu/~rwalden/networking/icmp.html
# for more info on ICMP types.
#
# Note that the stateful settings allow replies to ICMP packets.
# These rules allow new packets of the specified types.

# ICMP packets should fit in a Layer 2 frame, thus they should
# never be fragmented.  Fragmented ICMP packets are a typical sign
# of a denial of service attack.
$IPT -A icmp_packets --fragment -p ICMP -j LOG \
    --log-prefix "ICMP Fragment: "
$IPT -A icmp_packets --fragment -p ICMP -j DROP

# Echo - uncomment to allow your system to be pinged.
# Uncomment the LOG command if you also want to log PING attempts
# 
# $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j LOG \
#    --log-prefix "Ping detected: "
# $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT

# By default, however, drop pings without logging. Blaster
# and other worms have infected systems blasting pings.
# Comment the line below if you want pings logged, but it
# will likely fill your logs.
$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j DROP

# Time Exceeded
$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

# Not matched, so return so it will be logged
$IPT -A icmp_packets -p ICMP -j RETURN

# TCP & UDP
# Identify ports at:
#    http://www.chebucto.ns.ca/~rakerman/port-table.html
#    http://www.iana.org/assignments/port-numbers

# udp_inbound chain
#
# This chain describes the inbound UDP packets it will accept.
# It's applied to INPUT on the external or Internet interface.
# Note that the stateful settings allow replies.
# These rules are for new requests.
# It drops netbios packets (windows) immediately without logging.

# Drop netbios calls
# Please note that these rules do not really change the way the firewall
# treats netbios connections.  Connections from the localhost and
# internal interface (if one exists) are accepted by default.
# Responses from the Internet to requests initiated by or through
# the firewall are also accepted by default.  To get here, the
# packets would have to be part of a new request received by the
# Internet interface.  You would have to manually add rules to
# accept these.  I added these rules because some network connections,
# such as those via cable modems, tend to be filled with noise from
# unprotected Windows machines.  These rules drop those packets
# quickly and without logging them.  This prevents them from traversing
# the whole chain and keeps the log from getting cluttered with
# chatter from Windows systems.
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 137 -j DROP
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 138 -j DROP

# Network Time Protocol (NTP) Server
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 123 -j ACCEPT

# Network File System (NFS) Server
# Please note that additional services must
# be configured in order to support an NFS Server through
# the firewall. Read the help in the generator or this site:
# http://www.lowth.com/LinWiz/nfs_help.html

# NFS Server - portmapper
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 111 -j ACCEPT

# NFS Server - statd
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 9400 -j ACCEPT

# NFS Server - NFS daemon
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 2049 -j ACCEPT

# NFS Server - lockd
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 9401 -j ACCEPT

# NFS Server - mountd
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 9402 -j ACCEPT

# NFS Server - quotad
$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 9403 -j ACCEPT


# Not matched, so return for logging
$IPT -A udp_inbound -p UDP -j RETURN

# udp_outbound chain
#
# This chain is used with a private network to prevent forwarding for
# UDP requests on specific protocols.  Applied to the FORWARD rule from
# the internal network.  Ends with an ACCEPT


# No match, so ACCEPT
$IPT -A udp_outbound -p UDP -s 0/0 -j ACCEPT

# tcp_inbound chain
#
# This chain is used to allow inbound connections to the
# system/gateway.  Use with care.  It defaults to none.
# It's applied on INPUT from the external or Internet interface.

# Web Server

# HTTP
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 80 -j ACCEPT

# HTTPS (Secure Web Server)
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 443 -j ACCEPT

# Email Server (SMTP)
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 25 -j ACCEPT

# Email Server (POP3)
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 110 -j ACCEPT

# Email Server (IMAP4)
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 143 -j ACCEPT

# SSL Email Server (POP3)
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 995 -j ACCEPT

# SSL Email Server (IMAP4)
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 993 -j ACCEPT

# sshd
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 22 -j ACCEPT

# Network File System (NFS) Server
# Please note that additional services must
# be configured in order to support an NFS Server through
# the firewall. Read the help in the generator or this site:
# http://www.lowth.com/LinWiz/nfs_help.html

# NFS Server - portmapper
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 111 -j ACCEPT

# NFS Server - statd
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 9400 -j ACCEPT

# NFS Server - NFS daemon
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 2049 -j ACCEPT

# NFS Server - lockd
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 9401 -j ACCEPT

# NFS Server - mountd
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 9402 -j ACCEPT

# NFS Server - quotad
$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 9403 -j ACCEPT


# Not matched, so return so it will be logged
$IPT -A tcp_inbound -p TCP -j RETURN

# tcp_outbound chain
#
# This chain is used with a private network to prevent forwarding for
# requests on specific protocols.  Applied to the FORWARD rule from
# the internal network.  Ends with an ACCEPT


# No match, so ACCEPT
$IPT -A tcp_outbound -p TCP -s 0/0 -j ACCEPT

###############################################################################
#
# INPUT Chain
#

echo "Process INPUT chain ..."

# Allow all on localhost interface
$IPT -A INPUT -p ALL -i $LO_IFACE -j ACCEPT

# Drop bad packets
$IPT -A INPUT -p ALL -j bad_packets

# DOCSIS compliant cable modems
# Some DOCSIS compliant cable modems send IGMP multicasts to find
# connected PCs.  The multicast packets have the destination address
# 224.0.0.1.  You can accept them.  If you choose to do so,
# Uncomment the rule to ACCEPT them and comment the rule to DROP
# them  The firewall will drop them here by default to avoid
# cluttering the log.  The firewall will drop all multicasts
# to the entire subnet (224.0.0.1) by default.  To only affect
# IGMP multicasts, change '-p ALL' to '-p 2'.  Of course,
# if they aren't accepted elsewhere, it will only ensure that
# multicasts on other protocols are logged.
# Drop them without logging.
$IPT -A INPUT -p ALL -d 224.0.0.1 -j DROP
# The rule to accept the packets.
# $IPT -A INPUT -p ALL -d 224.0.0.1 -j ACCEPT


# Inbound Internet Packet Rules

# Accept Established Connections
$IPT -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED \
     -j ACCEPT

# Route the rest to the appropriate user chain
$IPT -A INPUT -p TCP -i $INET_IFACE -j tcp_inbound
$IPT -A INPUT -p UDP -i $INET_IFACE -j udp_inbound
$IPT -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets

# Drop without logging broadcasts that get this far.
# Cuts down on log clutter.
# Comment this line if testing new rules that impact
# broadcast protocols.
$IPT -A INPUT -m pkttype --pkt-type broadcast -j DROP

# Log packets that still don't match
$IPT -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
    --log-prefix "INPUT packet died: "

###############################################################################
#
# FORWARD Chain
#

echo "Process FORWARD chain ..."

# Used if forwarding for a private network


###############################################################################
#
# OUTPUT Chain
#

echo "Process OUTPUT chain ..."

# Generally trust the firewall on output

# However, invalid icmp packets need to be dropped
# to prevent a possible exploit.
$IPT -A OUTPUT -m state -p icmp --state INVALID -j DROP

# Localhost
$IPT -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPT -A OUTPUT -p ALL -o $LO_IFACE -j ACCEPT

# To internet
$IPT -A OUTPUT -p ALL -o $INET_IFACE -j ACCEPT

# Log packets that still don't match
$IPT -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
    --log-prefix "OUTPUT packet died: "

###############################################################################
#
# nat table
#
###############################################################################

# The nat table is where network address translation occurs if there
# is a private network.  If the gateway is connected to the Internet
# with a static IP, snat is used.  If the gateway has a dynamic address,
# masquerade must be used instead.  There is more overhead associated
# with masquerade, so snat is better when it can be used.
# The nat table has a builtin chain, PREROUTING, for dnat and redirects.
# Another, POSTROUTING, handles snat and masquerade.

echo "Load rules for nat table ..."

###############################################################################
#
# PREROUTING chain
#


###############################################################################
#
# POSTROUTING chain
#


###############################################################################
#
# mangle table
#
###############################################################################

# The mangle table is used to alter packets.  It can alter or mangle them in
# several ways.  For the purposes of this generator, we only use its ability
# to alter the TTL in packets.  However, it can be used to set netfilter
# mark values on specific packets.  Those marks could then be used in another
# table like filter, to limit activities associated with a specific host, for
# instance.  The TOS target can be used to set the Type of Service field in
# the IP header.  Note that the TTL target might not be included in the
# distribution on your system.  If it is not and you require it, you will
# have to add it.  That may require that you build from source.

echo "Load rules for mangle table ..."
 
2 members found this post helpful.
Old 02-05-2011, 06:48 AM   #4
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Like acid_kewpie said, those ACCEPT rules are futile since the packet would never reach them (it would get filtered by the second rule). I would also add that you could streamline this by getting rid of all those LOG rules and just using one to catch everything at the end of the chain. There's really no need for you to have any DROP rules at all with such a simple setup.

BTW, is the "-j" in the policy commands valid syntax? I've never seen that before.
 
Old 02-05-2011, 08:20 AM   #5
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966
Quote:
Originally Posted by win32sux View Post
Like acid_kewpie said, those ACCEPT rules are futile since the packet would never reach them (it would get filtered by the second rule). I would also add that you could streamline this by getting rid of all those LOG rules and just using one to catch everything at the end of the chain. There's really no need for you to have any DROP rules at all with such a simple setup.

BTW, is the "-j" in the policy commands valid syntax? I've never seen that before.
Thanks for confirming that! I was, like, 100% percent certain (no more, that's impossible...) that was the case, because it clearly was, but when someone is asking for advie to improve it, does suggest that somehow it's already working.
 
Old 02-05-2011, 11:04 AM   #6
ewsmith
Member
 
Registered: Oct 2010
Location: Weesatche, Texas
Distribution: Slackware
Posts: 72

Original Poster
Rep: Reputation: 7
Thanks for the replies. I have only started thinking about iptables, so I didn't have a clue on how it was thrown together.
@ acid_kewpie:
I did the first test before posting this. And would you know it? iptables complained. XD
it didn't know wtf -j was. Nothing's better than making mistakes when it comes to learning.

i have made a few mods to the file. the updated version is:
Code:
#!/bin/bash

#######################################
#        Specific LOG Rules          #
#######################################
iptables -A INPUT -p tcp -m state --state NEW -j LOG
iptables -A INPUT -m state --state INVALID -j LOG
iptables -A INPUT -m state --state UNTRACKED -j LOG

#######################################
#       Specific ACCEPT Rules         #
#######################################
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i wlan0 -j ACCEPT
iptables -A INPUT -p tcp --syn -m limit --limit 5/s -i eth0 -j ACCEPT

#######################################
#           Global Rules              #
#######################################
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
@ xeleema:
I've used the wizard and am looking over the file now. No offense to you, but I don't trust 'wizards' and the like(bad experience with one).


PS: Does anyone know why wicd drops a connection about every ten seconds? It's starting to vex me.

EDIT: Forgot to post that I copied some rules from the Slackware essentials book.
It had the -j. That's why I was confused.

EDIT2: I have bolded changes to the above configuration that made iptables recognize the commands. It took four reboots for me to figure out what was wrong.
the very first complaint that iptables gave me was based on the fact that i forget the -j on the limit lines and placed -j on the global rules.
please keep in mine that this is on Slackware 13.1 with the rc.firewall file.

Last edited by ewsmith; 02-05-2011 at 11:59 AM. Reason: clarifying my stupidity
 
Old 02-06-2011, 03:38 AM   #7
xeleema
Member
 
Registered: Aug 2005
Location: D.i.t.h.o, Texas
Distribution: Slackware 13.x, rhel3/5, Solaris 8-10(sparc), HP-UX 11.x (pa-risc)
Posts: 987
Blog Entries: 4

Rep: Reputation: 249Reputation: 249Reputation: 249
Quote:
I've used the wizard and am looking over the file now. No offense to you, but I don't trust 'wizards' and the like(bad experience with one).
I don't trust them either, but I use them to hammer-out the basics and review/tweak the rest. I don't actually run anything until I understand how it's doing what I want (this of course involves reading documentation and maybe heading over to the bookstore).
 
Old 02-07-2011, 04:49 AM   #8
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
The script is still really weird, IMHO. For example, those LOG rules don't have any prefixes (so you won't be able to easily distinguish the log entries from one another). By doing your logging at the top of the chain, you're also increasing the risk of something being logged as filtered/allowed even though a subsequent rule nullified the action. Like I said, your approach here is really weird, and I would highly recommend you start with a more traditional set of minimal rules and then tweak/expand them as needed. Something like this, perhaps:
Code:
#!/bin/sh

IPT="/sbin/iptables"

$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT

$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i lo -m state --state NEW -j ACCEPT
$IPT -A INPUT -j LOG --log-prefix "INPUT DROP: "

Last edited by win32sux; 02-07-2011 at 04:50 AM.
 
Old 02-07-2011, 04:54 AM   #9
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,414

Rep: Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966Reputation: 1966
The logging "NEW" connections but that never matching with an explicit permit for any other "NEW" conenctions seems odd. Might work fine, but very inconsistent.
 
Old 02-07-2011, 11:59 AM   #10
ewsmith
Member
 
Registered: Oct 2010
Location: Weesatche, Texas
Distribution: Slackware
Posts: 72

Original Poster
Rep: Reputation: 7
Quote:
Originally Posted by win32sux
The script is still really weird, IMHO. For example, those LOG rules don't have any prefixes (so you won't be able to easily distinguish the log entries from one another). By doing your logging at the top of the chain, you're also increasing the risk of something being logged as filtered/allowed even though a subsequent rule nullified the action. Like I said, your approach here is really weird, and I would highly recommend you start with a more traditional set of minimal rules and then tweak/expand them as needed. Something like this, perhaps:
Code:
#!/bin/sh

IPT="/sbin/iptables"

$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT

$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i lo -m state --state NEW -j ACCEPT
$IPT -A INPUT -j LOG --log-prefix "INPUT DROP: "
Great idea! Thanks! :D
But how does it differentiate between those that DROPed and those that didn't?

Quote:
Originally Posted by acid_kewpie
The logging "NEW" connections but that never matching with an explicit permit for any other "NEW" conenctions seems odd. Might work fine, but very inconsistent.
Wait..what?

Last edited by ewsmith; 02-07-2011 at 12:04 PM.
 
Old 02-07-2011, 02:06 PM   #11
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by ewsmith View Post
Great idea! Thanks!
But how does it differentiate between those that DROPed and those that didn't?
In the script I posted, only packets which are filtered will be logged.

Notice how the LOG rule is the last in the chain, right before the policy (which is set to DROP).
 
Old 02-07-2011, 02:44 PM   #12
ewsmith
Member
 
Registered: Oct 2010
Location: Weesatche, Texas
Distribution: Slackware
Posts: 72

Original Poster
Rep: Reputation: 7
Quote:
Originally Posted by win32sux View Post
In the script I posted, only packets which are filtered will be logged.

Notice how the LOG rule is the last in the chain, right before the policy (which is set to DROP).
-face palm-
I can't believe that I didn't get that before. :/

I've (re)worked my rc.firewall. it now looks like:
Code:
#!/bin/bash

#######################################
#           Global Rules              #
#######################################
iptables -P INPUT  DROP
iptables -P FORWARD  DROP
iptables -P OUTPUT  ACCEPT

#######################################
#       Specific ACCEPT Rules         #
#######################################
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT

#######################################
#             LOG Rules               #
#######################################
iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "
iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: "
I'm starting to understand this more. :D
 
Old 02-07-2011, 03:16 PM   #13
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
BTW, what was with the ACCEPT rules for TCP SYN packets on wlan0 and eth0?

I forgot to ask you earlier.
 
Old 02-07-2011, 05:11 PM   #14
ewsmith
Member
 
Registered: Oct 2010
Location: Weesatche, Texas
Distribution: Slackware
Posts: 72

Original Poster
Rep: Reputation: 7
Quote:
Originally Posted by win32sux View Post
BTW, what was with the ACCEPT rules for TCP SYN packets on wlan0 and eth0?

I forgot to ask you earlier.
Honestly, i can't remember. .-.
That's why i removed them.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Opinions Needed Eightpock Linux - Networking 1 06-30-2008 10:25 AM
captive portal opinions needed tanoatlq Linux - Software 0 05-18-2008 05:51 PM
Opinions needed Windchaser Linux - Server 5 12-15-2006 12:55 AM
Opinions needed RobNyc Linux - Distributions 23 06-12-2005 08:02 PM
ISO Editor - opinions needed Mig21 Linux - Software 4 05-20-2005 07:34 PM


All times are GMT -5. The time now is 10:01 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration