Firewall Configuration Help

Firewall Configuration Help

[NICHOLAS KLINE]

Hi,

I have a fresh install of Ubuntu 8.x desktop edition running on a
laptop. Before I plug the laptop into a public network and proceed to
patch it, I want to make sure I have a secure firewall in place.

This particular system will not be running any server services such as
HTTPD, SSH, FTP, etc. Inbound traffic should be denied unless an
outbound connection was first established.
I will mostly be using a wired internet connection but I might switch
to wireless once in awhile.

After reading a few Linux security books, I have a decent set of
firewall rules almost ready to put into place. The only rule
preventing me from putting the firewall in place is:

$IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A INPUT -s $IP_LOCAL -j DROP

Which says to drop any incoming packet which has my source IP address
on it. The reason this rule is preventing me from putting the firewall
in place is because my IP address is not always the same or I will be
occasionally using a public wireless network. The complete version of
my firewall rules are below.

My questions are:

1.) What are the risks of excluding the firewall rule mentioned above?
2.) How can my firewall adapt to a changing IP address?
3.) Please critique my complete firewall rules

Thank you for your help!


Complete Firewall Rules
-------------------------------

# Establish some variables:

# Location of IPTABLES on your system
IPTABLES="/sbin/iptables"

# Reserved loopback address range
LOOPBACK="127.0.0.0/8"

# Class A private networks
CLASS_A="10.0.0.0/8"

# Class B private networks
CLASS_B="172.16.0.0/12"

# Class C private networks
CLASS_C="192.168.0.0/16"


# SETUP

# Flush active rules and custom tables
$IPTABLES --flush
$IPTABLES -t nat --flush
$IPTABLES -t mangle --flush

$IPTABLES --delete-chain
$IPTABLES -t nat --delete-chain
$IPTABLES -t mangle --delete-chain

# Give free reign to the loopback interfaces, i.e. local processes may connect
# to other processes' listening-ports.
$IPTABLES -A INPUT  -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# Set default-deny policies for all chains.
# User-defined chains cannot be assigned default policies.
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

$IPTABLES -t nat -P PREROUTING DROP
$IPTABLES -t nat -P OUTPUT DROP
$IPTABLES -t nat -P POSTROUTING DROP

$IPTABLES -t mangle -P PREROUTING DROP
$IPTABLES -t mangle -P OUTPUT DROP

# Do some rudimentary anti-IP-spoofing drops. The rule of thumb is "drop
# any source IP address which is impossible"

# Refuse packets claiming to be from the loopback interface
$IPTABLES -A INPUT -s $LOOPBACK -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A INPUT -s $LOOPBACK -j DROP

# Refuse packets claiming to be from a Class A private network
$IPTABLES -A INPUT -s $CLASS_A -j LOG --log-prefix " Spoofed source IP"
$IPTABLES -A INPUT -s $CLASS_A -j DROP

# Refuse packets claiming to be from a Class B private network
$IPTABLES -A INPUT -s $CLASS_B -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A INPUT -s $CLASS_B -j DROP

# Refuse packets claiming to be from a Class C private network
$IPTABLES -A INPUT -s $CLASS_C -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A INPUT -s $CLASS_C -j DROP

$IPTABLES -A INPUT -s 255.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A INPUT -s 255.0.0.0/8 -j DROP
$IPTABLES -A INPUT -s 0.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A INPUT -s 0.0.0.0/8 -j DROP

# The following will NOT interfere with local inter-process traffic, whose
# packets have the source IP of the local loopback interface, e.g. 127.0.0.1

$IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A INPUT -s $IP_LOCAL -j DROP

# Tell netfilter that all TCP sessions do indeed begin with SYN

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
--log-prefix "Stealth scan attempt?"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP


# INBOUND POLICY:

# Accept inbound packets that are part of previously-OK'ed sessions
$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Log and drop anything not accepted above
# (Obviously we want to log any packet that doesn't match any ACCEPT rule, for
# both security and troubleshooting. Note that the final "DROP" rule is
# redundant if the default policy is already DROP, but redundant security is
# usually a good thing.)

$IPTABLES -A INPUT -j LOG --log-prefix "Dropped by default (INPUT):"
$IPTABLES -A INPUT -j DROP


# OUTBOUND POLICY:

# (Applies to packets sent to the network interface (NOT loopback)
# from local processes)

# If it's part of an approved connection, let it out
$IPTABLES -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow outbound ping
# (For testing only! If someone compromises your system they may attempt
# to use ping to identify other active IP addresses on the DMZ. Comment
# this rule out when you don't need to use it yourself!)

# $IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

# Allow outbound DNS queries, e.g. to resolve IPs in logs
# (Many network applications break or radically slow down if they
# can't use DNS. Although DNS queries usually use UDP 53, they may also use TCP
# 53. Although TCP 53 is normally used for zone-transfers, DNS queries with
# replies greater than 512 bytes also use TCP 53, so we'll allow both
TCP and UDP
# 53 here

$IPTABLES -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT

# Log & drop anything not accepted above; if for no other reason, for
troubleshooting

# NOTE: you might consider setting your log-checker (e.g. Swatch) to
# sound an alarm whenever this rule fires; unexpected outbound trans-
# actions are often a sign of intruders!

$IPTABLES -A OUTPUT -j LOG --log-prefix "Dropped by default (OUTPUT):"
$IPTABLES -A OUTPUT -j DROP

# Log & drop ALL incoming packets destined anywhere but here.
# (We already set the default FORWARD policy to DROP. But this is
# yet another free, reassuring redundancy, so why not throw it in?)

$IPTABLES -A FORWARD -j LOG --log-prefix "Attempted FORWARD? Dropped
by default:"
$IPTABLES -A FORWARD -j DROP

Re: Firewall Configuration Help

[Julien Vehent]

Hello Nicholas,


On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu> wrote:
> Hi,
> 
> I have a fresh install of Ubuntu 8.x desktop edition running on a
> laptop. Before I plug the laptop into a public network and proceed to
> patch it, I want to make sure I have a secure firewall in place.
> 
> This particular system will not be running any server services such as
> HTTPD, SSH, FTP, etc. Inbound traffic should be denied unless an
> outbound connection was first established.
> I will mostly be using a wired internet connection but I might switch
> to wireless once in awhile.
> 
> After reading a few Linux security books, I have a decent set of
> firewall rules almost ready to put into place. The only rule
> preventing me from putting the firewall in place is:
> 
> $IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $IP_LOCAL -j DROP
> 
> Which says to drop any incoming packet which has my source IP address
> on it. The reason this rule is preventing me from putting the firewall
> in place is because my IP address is not always the same or I will be
> occasionally using a public wireless network. The complete version of
> my firewall rules are below.
> 
> My questions are:
> 
> 1.) What are the risks of excluding the firewall rule mentioned above?

Well, the chances that your own IP address is going to be spoofed are very
low. And even so, the packets you would send back to the attacker would
never get there, and then largely reduce the possibility of attacks. So
it's good practice to clean up this behavior but not mandatory in real
life.

> 2.) How can my firewall adapt to a changing IP address?

Get the address from ifconfig when you start the firewall ;)

> 3.) Please critique my complete firewall rules

ok, comment are below

> 
> Thank you for your help!
> 
> 
> Complete Firewall Rules
> -------------------------------
> 
> # Establish some variables:
> 
> # Location of IPTABLES on your system
> IPTABLES="/sbin/iptables"
> 
> # Reserved loopback address range
> LOOPBACK="127.0.0.0/8"
> 
> # Class A private networks
> CLASS_A="10.0.0.0/8"
> 
> # Class B private networks
> CLASS_B="172.16.0.0/12"
> 
> # Class C private networks
> CLASS_C="192.168.0.0/16"
> 
> 
> # SETUP
> 
> # Flush active rules and custom tables
> $IPTABLES --flush
> $IPTABLES -t nat --flush
> $IPTABLES -t mangle --flush
> 
> $IPTABLES --delete-chain
> $IPTABLES -t nat --delete-chain
> $IPTABLES -t mangle --delete-chain
> 
> # Give free reign to the loopback interfaces, i.e. local processes may
> connect
> # to other processes' listening-ports.
> $IPTABLES -A INPUT  -i lo -j ACCEPT
> $IPTABLES -A OUTPUT -o lo -j ACCEPT
> 
> # Set default-deny policies for all chains.
> # User-defined chains cannot be assigned default policies.
> $IPTABLES -P INPUT DROP
> $IPTABLES -P FORWARD DROP
> $IPTABLES -P OUTPUT DROP
> 
> $IPTABLES -t nat -P PREROUTING DROP
> $IPTABLES -t nat -P OUTPUT DROP
> $IPTABLES -t nat -P POSTROUTING DROP
> 
> $IPTABLES -t mangle -P PREROUTING DROP
> $IPTABLES -t mangle -P OUTPUT DROP
> 

I don't like the default policy because you can't log anything in these
rules.
I prefer to put at the end of the ruleset something like
--------
   echo "Default log drop, at the end so we just drop what doesn't match
the
previous rules"
   $IPT -N LOGDROP
   $IPT -A LOGDROP -j LOG --log-prefix "DROP => " --log-level debug
   $IPT -A LOGDROP -j DROP

   $IPT -A INPUT -i $NETCARD -j LOGDROP
   $IPT -A OUTPUT -o $NETCARD -j LOGDROP
--------
that allows you to log and then drop, instead of just dropping.


> # Do some rudimentary anti-IP-spoofing drops. The rule of thumb is "drop
> # any source IP address which is impossible"
> 
> # Refuse packets claiming to be from the loopback interface
> $IPTABLES -A INPUT -s $LOOPBACK -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $LOOPBACK -j DROP
> 
> # Refuse packets claiming to be from a Class A private network
> $IPTABLES -A INPUT -s $CLASS_A -j LOG --log-prefix " Spoofed source IP"
> $IPTABLES -A INPUT -s $CLASS_A -j DROP
> 
> # Refuse packets claiming to be from a Class B private network
> $IPTABLES -A INPUT -s $CLASS_B -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $CLASS_B -j DROP
> 
> # Refuse packets claiming to be from a Class C private network
> $IPTABLES -A INPUT -s $CLASS_C -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $CLASS_C -j DROP
> 
> $IPTABLES -A INPUT -s 255.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s 255.0.0.0/8 -j DROP
> $IPTABLES -A INPUT -s 0.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s 0.0.0.0/8 -j DROP
> 

Errrr.... why would you want to drop all the packets coming from the
private network you are connected to ?
These are very dangerous rules. If you are not connected directly, with a
public address, to the internet, you will more likely be connected through
a local network, and then your rules are going to block everything.


> # The following will NOT interfere with local inter-process traffic,
whose
> # packets have the source IP of the local loopback interface, e.g.
> 127.0.0.1
> 
> $IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $IP_LOCAL -j DROP
> 
> # Tell netfilter that all TCP sessions do indeed begin with SYN
> 
> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
> --log-prefix "Stealth scan attempt?"
> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
> 
> 

My understanding of the conntrack subsystem is that a connection cannot be
in the state NEW without a syn packet, therefore I don't think this is
useful.


> # INBOUND POLICY:
> 
> # Accept inbound packets that are part of previously-OK'ed sessions
> $IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> 
> # Log and drop anything not accepted above
> # (Obviously we want to log any packet that doesn't match any ACCEPT
rule,
> for
> # both security and troubleshooting. Note that the final "DROP" rule is
> # redundant if the default policy is already DROP, but redundant security
> is
> # usually a good thing.)
> 
> $IPTABLES -A INPUT -j LOG --log-prefix "Dropped by default (INPUT):"
> $IPTABLES -A INPUT -j DROP
> 

if you default policy drops, why would you drop in the ruleset ? if you
have to drop in the ruleset, then you default policy is not good enough :)


> 
> # OUTBOUND POLICY:
> 
> # (Applies to packets sent to the network interface (NOT loopback)
> # from local processes)
> 
> # If it's part of an approved connection, let it out
> $IPTABLES -I OUTPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT
> 
> # Allow outbound ping
> # (For testing only! If someone compromises your system they may attempt
> # to use ping to identify other active IP addresses on the DMZ. Comment
> # this rule out when you don't need to use it yourself!)
> 
> # $IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
> 
> # Allow outbound DNS queries, e.g. to resolve IPs in logs
> # (Many network applications break or radically slow down if they
> # can't use DNS. Although DNS queries usually use UDP 53, they may also
use
> TCP
> # 53. Although TCP 53 is normally used for zone-transfers, DNS queries
with
> # replies greater than 512 bytes also use TCP 53, so we'll allow both
> TCP and UDP
> # 53 here
> 
> $IPTABLES -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
> $IPTABLES -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
> 
> # Log & drop anything not accepted above; if for no other reason, for
> troubleshooting
> 
> # NOTE: you might consider setting your log-checker (e.g. Swatch) to
> # sound an alarm whenever this rule fires; unexpected outbound trans-
> # actions are often a sign of intruders!
> 
> $IPTABLES -A OUTPUT -j LOG --log-prefix "Dropped by default (OUTPUT):"
> $IPTABLES -A OUTPUT -j DROP
> 

Honestly, for a laptop, I would recommand you open OUTPUT in wide.
Otherwise you're gonna spend a lot of time opening connection to ports you
normally use when connected to any network (smtp, imap, http, https,
jabber, ssh, ...)

> # Log & drop ALL incoming packets destined anywhere but here.
> # (We already set the default FORWARD policy to DROP. But this is
> # yet another free, reassuring redundancy, so why not throw it in?)
> 
> $IPTABLES -A FORWARD -j LOG --log-prefix "Attempted FORWARD? Dropped
> by default:"
> $IPTABLES -A FORWARD -j DROP


FORWARD is processed after INPUT and OUTPUT. If you drop in those two
chains, you shouldn't need to do anything in FORWARD.


Hope it helps,
Julien


-- 
julien
http://jve.linuxwall.info/blog

Re: Firewall Configuration Help

[Billy Crook]

On Tue, Jul 28, 2009 at 04:09, Julien Vehent<julien@linuxwall.info> wrote:
> Hello Nicholas,
>
>
> On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu> wrote:
>> $IPTABLES -A INPUT -s 255.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
>> $IPTABLES -A INPUT -s 255.0.0.0/8 -j DROP
>> $IPTABLES -A INPUT -s 0.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
>> $IPTABLES -A INPUT -s 0.0.0.0/8 -j DROP
>>
>
> Errrr.... why would you want to drop all the packets coming from the
> private network you are connected to ?
> These are very dangerous rules. If you are not connected directly, with a
> public address, to the internet, you will more likely be connected through
> a local network, and then your rules are going to block everything.

That's not exactly what these rules would do.  It will block broadcast
traffic like netbios, avahi, and printer advertisements though.  That
said, Nick is clearly giong to be in a world of hurt when he enables a
ruleset as nasty as this.  Simple is better.  Nick's reminds me of
SUSE!  Unless you intend to read about every dropped packet, why are
you logging them?  And stop talking about classed networks.  That era
has been dead for a very long time.

Use iptables-save and iptables-restore for firewall configs.  It's
what they exist for.

And here's my config, which is longer than I'd like, but as short as
it can be and still do the job.  You might change :FORWARD ACCEPT to
:FORWARD REJECT if you don't ever plan to act as a router.

[root@Zero ~]# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
#Allow incoming Sunrpc from lan (to facilitate NFS)
-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -s
192.168.171.0/24 -j ACCEPT
#Allow incoming syslog from lan
-A INPUT -m state --state NEW -m udp -p udp --dport 514 -s
192.168.171.0/24 -j ACCEPT
#Allow incoming rpc.mountd from lan
-A INPUT -m state --state NEW -m udp -p udp --dport 892 -s
192.168.171.0/24 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 892 -s
192.168.171.0/24 -j ACCEPT
#Allow incoming NFS from lan
-A INPUT -m state --state NEW -m udp -p udp --dport 2049 -s
192.168.171.0/24 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -s
192.168.171.0/24 -j ACCEPT
#Allow incoming LDAP from lan
-A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -s
192.168.171.0/24 -j ACCEPT
#Allow incoming gmonds from lan
-A INPUT -m state --state NEW -m udp -p udp --dport 8649 -s
192.168.171.0/24 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 8649 -s
192.168.171.0/24 -j ACCEPT
#Allow incoming SSH
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#Allow incoming HTTP
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
#Allow incoming SMTP from the world
-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
#Allow incoming VMware
#-A INPUT -m state --state NEW -m tcp -p tcp --dport 902  -j ACCEPT
#-A INPUT -m state --state NEW -m tcp -p tcp --dport 904  -j ACCEPT
#-A INPUT -m state --state NEW -m tcp -p tcp --dport 8222 -j ACCEPT
#-A INPUT -m state --state NEW -m tcp -p tcp --dport 8333 -j ACCEPT
#Allow Jabber clients and federation
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5222 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5269 -j ACCEPT
#Allow incoming KTorrent
-A INPUT -m state --state NEW -m tcp -p tcp --dport 6881 -j ACCEPT
#Allow incoming TFTP
-A INPUT -p udp --dport 69 -j ACCEPT
#Allow incoming DNS
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
#Allow network printer awareness
-A INPUT -p udp -m udp --dport 631 -j ACCEPT
#Default policy ot rejection
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Re: Firewall Configuration Help

[Julien Vehent]

On Tue, 28 Jul 2009 08:19:19 -0500, Billy Crook <billycrook@gmail.com>
wrote:
> On Tue, Jul 28, 2009 at 04:09, Julien Vehent<julien@linuxwall.info>
wrote:
>> Hello Nicholas,
>>
>>
>> On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu>
>> wrote:
>>> $IPTABLES -A INPUT -s 255.0.0.0/8 -j LOG --log-prefix "Spoofed source
>>> IP"
>>> $IPTABLES -A INPUT -s 255.0.0.0/8 -j DROP
>>> $IPTABLES -A INPUT -s 0.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
>>> $IPTABLES -A INPUT -s 0.0.0.0/8 -j DROP
>>>
>>
>> Errrr.... why would you want to drop all the packets coming from the
>> private network you are connected to ?
>> These are very dangerous rules. If you are not connected directly, with
a
>> public address, to the internet, you will more likely be connected
>> through
>> a local network, and then your rules are going to block everything.
> 
> That's not exactly what these rules would do.  It will block broadcast
> traffic like netbios, avahi, and printer advertisements though.  That
> said, Nick is clearly giong to be in a world of hurt when he enables a
> ruleset as nasty as this.  Simple is better.  Nick's reminds me of
> SUSE!  Unless you intend to read about every dropped packet, why are
> you logging them?  And stop talking about classed networks.  That era
> has been dead for a very long time.
> 

Yes, I was refering to the previous rules were he drops traffic for the LAN
classes.
I disagree with you about the LOG of DROPped packets, but essentially
because I put rules on servers where I want to know what's going on. On a
laptop, I don't really see the point (NATed networks, short time
connections, ...) but that's just a personal opinion.

> Use iptables-save and iptables-restore for firewall configs.  It's
> what they exist for.
> 

Once again, it's a matter of personal choice. I don't like the syntax of
these files, I prefer a good-old-bash syntax. And, also, I have the bad
habit of putting in the same file the firewall rules and the QoS rules,
so....

> And here's my config, which is longer than I'd like, but as short as
> it can be and still do the job.  You might change :FORWARD ACCEPT to
> :FORWARD REJECT if you don't ever plan to act as a router.
> 
> [root@Zero ~]# cat /etc/sysconfig/iptables
> # Firewall configuration written by system-config-firewall
> # Manual customization of this file is not recommended.
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> #Allow incoming Sunrpc from lan (to facilitate NFS)
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -s
> 192.168.171.0/24 -j ACCEPT
> #Allow incoming syslog from lan
> -A INPUT -m state --state NEW -m udp -p udp --dport 514 -s
> 192.168.171.0/24 -j ACCEPT
> #Allow incoming rpc.mountd from lan
> -A INPUT -m state --state NEW -m udp -p udp --dport 892 -s
> 192.168.171.0/24 -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 892 -s
> 192.168.171.0/24 -j ACCEPT
> #Allow incoming NFS from lan
> -A INPUT -m state --state NEW -m udp -p udp --dport 2049 -s
> 192.168.171.0/24 -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -s
> 192.168.171.0/24 -j ACCEPT
> #Allow incoming LDAP from lan
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -s
> 192.168.171.0/24 -j ACCEPT
> #Allow incoming gmonds from lan
> -A INPUT -m state --state NEW -m udp -p udp --dport 8649 -s
> 192.168.171.0/24 -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 8649 -s
> 192.168.171.0/24 -j ACCEPT
> #Allow incoming SSH
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
> #Allow incoming HTTP
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
> #Allow incoming SMTP from the world
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
> #Allow incoming VMware
> #-A INPUT -m state --state NEW -m tcp -p tcp --dport 902  -j ACCEPT
> #-A INPUT -m state --state NEW -m tcp -p tcp --dport 904  -j ACCEPT
> #-A INPUT -m state --state NEW -m tcp -p tcp --dport 8222 -j ACCEPT
> #-A INPUT -m state --state NEW -m tcp -p tcp --dport 8333 -j ACCEPT
> #Allow Jabber clients and federation
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 5222 -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 5269 -j ACCEPT
> #Allow incoming KTorrent
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 6881 -j ACCEPT
> #Allow incoming TFTP
> -A INPUT -p udp --dport 69 -j ACCEPT
> #Allow incoming DNS
> -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
> -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
> #Allow network printer awareness
> -A INPUT -p udp -m udp --dport 631 -j ACCEPT
> #Default policy ot rejection
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A FORWARD -j REJECT --reject-with icmp-host-prohibited
> COMMIT
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
julien
http://jve.linuxwall.info/blog

Re: Firewall Configuration Help

[/dev/rob0]

On Tuesday 28 July 2009 08:19:19 Billy Crook wrote:
[snip lots of good advice]
> And here's my config, which is longer than I'd like, but as short as
> it can be and still do the job.  You might change :FORWARD ACCEPT to
> :FORWARD REJECT if you don't ever plan to act as a router.

1. Allow me to introduce my friend, the multiport match, which will
   indeed shorten your rules and still do the job. :)
2. REJECT is not a valid policy, see DROP.
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header

Re: Firewall Configuration Help

[Mart Frauenlob]

NICHOLAS KLINE wrote:
> Hi,
>
> I have a fresh install of Ubuntu 8.x desktop edition running on a
> laptop. Before I plug the laptop into a public network and proceed to
> patch it, I want to make sure I have a secure firewall in place.
>
> This particular system will not be running any server services such as
> HTTPD, SSH, FTP, etc. Inbound traffic should be denied unless an
> outbound connection was first established.
> I will mostly be using a wired internet connection but I might switch
> to wireless once in awhile.
>
> After reading a few Linux security books, I have a decent set of
> firewall rules almost ready to put into place. The only rule
> preventing me from putting the firewall in place is:
>
> $IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $IP_LOCAL -j DROP
>
> Which says to drop any incoming packet which has my source IP address
> on it. The reason this rule is preventing me from putting the firewall
> in place is because my IP address is not always the same or I will be
> occasionally using a public wireless network. The complete version of
> my firewall rules are below.
>
> My questions are:
>
> 1.) What are the risks of excluding the firewall rule mentioned above?
> 2.) How can my firewall adapt to a changing IP address?
> 3.) Please critique my complete firewall rules
>
> Thank you for your help!
>
>
> Complete Firewall Rules
> -------------------------------
>
> # Establish some variables:
>
> # Location of IPTABLES on your system
> IPTABLES="/sbin/iptables"
>
> # Reserved loopback address range
> LOOPBACK="127.0.0.0/8"
>
> # Class A private networks
> CLASS_A="10.0.0.0/8"
>
> # Class B private networks
> CLASS_B="172.16.0.0/12"
>
> # Class C private networks
> CLASS_C="192.168.0.0/16"
>
>
> # SETUP
>
> # Flush active rules and custom tables
> $IPTABLES --flush
> $IPTABLES -t nat --flush
> $IPTABLES -t mangle --flush
>
> $IPTABLES --delete-chain
> $IPTABLES -t nat --delete-chain
> $IPTABLES -t mangle --delete-chain
>
> # Give free reign to the loopback interfaces, i.e. local processes may connect
> # to other processes' listening-ports.
> $IPTABLES -A INPUT  -i lo -j ACCEPT
> $IPTABLES -A OUTPUT -o lo -j ACCEPT
>
> # Set default-deny policies for all chains.
> # User-defined chains cannot be assigned default policies.
> $IPTABLES -P INPUT DROP
> $IPTABLES -P FORWARD DROP
> $IPTABLES -P OUTPUT DROP
>
> $IPTABLES -t nat -P PREROUTING DROP
> $IPTABLES -t nat -P OUTPUT DROP
> $IPTABLES -t nat -P POSTROUTING DROP
>
> $IPTABLES -t mangle -P PREROUTING DROP
> $IPTABLES -t mangle -P OUTPUT DROP
>  

Set policies in for nat and mangle table to the default ACCEPT. Just
drop in filter table.
In newer versions of iptables DROP in nat table is prohibited. Dropping
everything in mangle table creates more hassle, because you need to
explicitely allow in mangle and in the filter table.
The filter table is the place meant to do the filtering work.

> # Do some rudimentary anti-IP-spoofing drops. The rule of thumb is "drop
> # any source IP address which is impossible"
>
> # Refuse packets claiming to be from the loopback interface
> $IPTABLES -A INPUT -s $LOOPBACK -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $LOOPBACK -j DROP
>
> # Refuse packets claiming to be from a Class A private network
> $IPTABLES -A INPUT -s $CLASS_A -j LOG --log-prefix " Spoofed source IP"
> $IPTABLES -A INPUT -s $CLASS_A -j DROP
>
> # Refuse packets claiming to be from a Class B private network
> $IPTABLES -A INPUT -s $CLASS_B -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $CLASS_B -j DROP
>
> # Refuse packets claiming to be from a Class C private network
> $IPTABLES -A INPUT -s $CLASS_C -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $CLASS_C -j DROP
>
> $IPTABLES -A INPUT -s 255.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s 255.0.0.0/8 -j DROP
> $IPTABLES -A INPUT -s 0.0.0.0/8 -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s 0.0.0.0/8 -j DROP
>
> # The following will NOT interfere with local inter-process traffic, whose
> # packets have the source IP of the local loopback interface, e.g. 127.0.0.1
>
> $IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
> $IPTABLES -A INPUT -s $IP_LOCAL -j DROP
>
>   

$IPTABLES -N SPOOFED_SOURCE
$IPTABLES -A SPOOFED_SOURCE -m limit --limit 'value-of_choice' 
--limit-burst 'value-of_choice' -j LOG --log-prefix "Spoofed source IP"
$IPTABLES -A SPOOFED_SOURCE -j DROP

now put your INPUT rules and send them to the SPOOFED_SOURCE chain.
i.e.
$IPTABLES -A INPUT -s 255.0.0.0/8 -j SPOOFED_SOURCE

saves writing and elaborating lots of rules.

...

greets

Mart

Re: Firewall Configuration Help

[Mart Frauenlob]

Julien Vehent wrote:
> Hello Nicholas,
>
>
> On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu> wrote:
>   
>> Hi,
>>
>> I have a fresh install of Ubuntu 8.x desktop edition running on a
>> laptop. Before I plug the laptop into a public network and proceed to
>> patch it, I want to make sure I have a secure firewall in place.
>>
>> This particular system will not be running any server services such as
>> HTTPD, SSH, FTP, etc. Inbound traffic should be denied unless an
>> outbound connection was first established.
>> I will mostly be using a wired internet connection but I might switch
>> to wireless once in awhile.
>>
>> After reading a few Linux security books, I have a decent set of
>> firewall rules almost ready to put into place. The only rule
>> preventing me from putting the firewall in place is:
>>     
...

>> # Set default-deny policies for all chains.
>> # User-defined chains cannot be assigned default policies.
>> $IPTABLES -P INPUT DROP
>> $IPTABLES -P FORWARD DROP
>> $IPTABLES -P OUTPUT DROP
>>
>> $IPTABLES -t nat -P PREROUTING DROP
>> $IPTABLES -t nat -P OUTPUT DROP
>> $IPTABLES -t nat -P POSTROUTING DROP
>>
>> $IPTABLES -t mangle -P PREROUTING DROP
>> $IPTABLES -t mangle -P OUTPUT DROP
>>
>>     
>
> I don't like the default policy because you can't log anything in these
> rules.
> I prefer to put at the end of the ruleset something like
> --------
>    echo "Default log drop, at the end so we just drop what doesn't match
> the
> previous rules"
>    $IPT -N LOGDROP
>    $IPT -A LOGDROP -j LOG --log-prefix "DROP => " --log-level debug
>    $IPT -A LOGDROP -j DROP
>
>    $IPT -A INPUT -i $NETCARD -j LOGDROP
>    $IPT -A OUTPUT -o $NETCARD -j LOGDROP
> --------
> that allows you to log and then drop, instead of just dropping.
>
>
>   
Why not just put a log rule as the final rule and let the policy drop 
the packet? That way there's less rules and traffic gets logged and dropped.

...
>> # Log & drop ALL incoming packets destined anywhere but here.
>> # (We already set the default FORWARD policy to DROP. But this is
>> # yet another free, reassuring redundancy, so why not throw it in?)
>>
>> $IPTABLES -A FORWARD -j LOG --log-prefix "Attempted FORWARD? Dropped
>> by default:"
>> $IPTABLES -A FORWARD -j DROP
>>     
>
>
> FORWARD is processed after INPUT and OUTPUT. If you drop in those two
> chains, you shouldn't need to do anything in FORWARD.
>
>
>   
hm, I think this is not right.
After the routing deciscion, packets either go to INPUT, OUTPUT or 
FORWARD chain.
If the OP is not 'routing' traffic not originated from his box, the 
FORWARD chain will not be used at all, so a simple policy drop will do 
the job (log before if wanted).
Correct me if I'm wrong please.

greets

Mart

Re: Firewall Configuration Help

[Mart Frauenlob]

Julien Vehent wrote:
> Hello Nicholas,
>
>
> On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu> wrote:
>   
>> # Tell netfilter that all TCP sessions do indeed begin with SYN
>>
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
>> --log-prefix "Stealth scan attempt?"
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>>     
>
> My understanding of the conntrack subsystem is that a connection cannot be
> in the state NEW without a syn packet, therefore I don't think this is
> useful.
>
>
>   
Wrong, from the iptables tutorial 1.2.2 at frozentux:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html#STATEMACHINE

The NEW state tells us that the packet is the first packet that we see. 
This means that the first packet that the conntrack module sees, within 
a specific connection, will be matched. For example, if we see a SYN 
packet and it is the first packet in a connection that we see, it will 
match. However, the packet may as well not be a SYN packet and still be 
considered NEW.

greets

Mart

Re: Firewall Configuration Help

[Julien Vehent]

On Wed, 05 Aug 2009 15:35:55 +0200, Mart Frauenlob
<mart.frauenlob@chello.at> wrote:
> Julien Vehent wrote:
>> Hello Nicholas,
>>
>>
>> On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu>
>> wrote:
>>   
>>> # Tell netfilter that all TCP sessions do indeed begin with SYN
>>>
>>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
>>> --log-prefix "Stealth scan attempt?"
>>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>>>     
>>
>> My understanding of the conntrack subsystem is that a connection cannot
>> be
>> in the state NEW without a syn packet, therefore I don't think this is
>> useful.
>>
>>
>>   
> Wrong, from the iptables tutorial 1.2.2 at frozentux:
>
http://iptables-tutorial.frozentux.net/iptables-tutorial.html#STATEMACHINE
> 
> The NEW state tells us that the packet is the first packet that we see. 
> This means that the first packet that the conntrack module sees, within 
> a specific connection, will be matched. For example, if we see a SYN 
> packet and it is the first packet in a connection that we see, it will 
> match. However, the packet may as well not be a SYN packet and still be 
> considered NEW.
> 

OK, I thought conntrack was doing some sort of protocol validation. I
suppose then that Linux will reply with some sort of RST packet. Thus, I'm
not quite sure to understand how this is a threat...



> greets
> 
> Mart

Julien
-- 
julien
http://jve.linuxwall.info/blog

Re: Firewall Configuration Help

[Julien Vehent]

On Wed, 05 Aug 2009 15:20:18 +0200, Mart Frauenlob
<mart.frauenlob@chello.at> wrote:
> Julien Vehent wrote:
>> Hello Nicholas,
>>
>>
>> On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu>
>> wrote:
>>   
>>> Hi,
>>>
>>> I have a fresh install of Ubuntu 8.x desktop edition running on a
>>> laptop. Before I plug the laptop into a public network and proceed to
>>> patch it, I want to make sure I have a secure firewall in place.
>>>
>>> This particular system will not be running any server services such as
>>> HTTPD, SSH, FTP, etc. Inbound traffic should be denied unless an
>>> outbound connection was first established.
>>> I will mostly be using a wired internet connection but I might switch
>>> to wireless once in awhile.
>>>
>>> After reading a few Linux security books, I have a decent set of
>>> firewall rules almost ready to put into place. The only rule
>>> preventing me from putting the firewall in place is:
>>>     
> ...
> 
>>> # Set default-deny policies for all chains.
>>> # User-defined chains cannot be assigned default policies.
>>> $IPTABLES -P INPUT DROP
>>> $IPTABLES -P FORWARD DROP
>>> $IPTABLES -P OUTPUT DROP
>>>
>>> $IPTABLES -t nat -P PREROUTING DROP
>>> $IPTABLES -t nat -P OUTPUT DROP
>>> $IPTABLES -t nat -P POSTROUTING DROP
>>>
>>> $IPTABLES -t mangle -P PREROUTING DROP
>>> $IPTABLES -t mangle -P OUTPUT DROP
>>>
>>>     
>>
>> I don't like the default policy because you can't log anything in these
>> rules.
>> I prefer to put at the end of the ruleset something like
>> --------
>>    echo "Default log drop, at the end so we just drop what doesn't
match
>> the
>> previous rules"
>>    $IPT -N LOGDROP
>>    $IPT -A LOGDROP -j LOG --log-prefix "DROP => " --log-level debug
>>    $IPT -A LOGDROP -j DROP
>>
>>    $IPT -A INPUT -i $NETCARD -j LOGDROP
>>    $IPT -A OUTPUT -o $NETCARD -j LOGDROP
>> --------
>> that allows you to log and then drop, instead of just dropping.
>>
>>
>>   
> Why not just put a log rule as the final rule and let the policy drop 
> the packet? That way there's less rules and traffic gets logged and
> dropped.
> 

You would not log the firewall's decision then. Only the packet details.


> ...
>>> # Log & drop ALL incoming packets destined anywhere but here.
>>> # (We already set the default FORWARD policy to DROP. But this is
>>> # yet another free, reassuring redundancy, so why not throw it in?)
>>>
>>> $IPTABLES -A FORWARD -j LOG --log-prefix "Attempted FORWARD? Dropped
>>> by default:"
>>> $IPTABLES -A FORWARD -j DROP
>>>     
>>
>>
>> FORWARD is processed after INPUT and OUTPUT. If you drop in those two
>> chains, you shouldn't need to do anything in FORWARD.
>>
>>
>>   
> hm, I think this is not right.
> After the routing deciscion, packets either go to INPUT, OUTPUT or 
> FORWARD chain.
> If the OP is not 'routing' traffic not originated from his box, the 
> FORWARD chain will not be used at all, so a simple policy drop will do 
> the job (log before if wanted).
> Correct me if I'm wrong please.
> 

Uh.. Shame on me. You are actually right on this. It's PREROUTING or
POSTROUTING that are processed before FORWARD. 

> greets
> 
> Mart
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
julien
http://jve.linuxwall.info/blog

Re: Firewall Configuration Help

[Mart Frauenlob]

Julien Vehent wrote:
> On Wed, 05 Aug 2009 15:20:18 +0200, Mart Frauenlob
> <mart.frauenlob@chello.at> wrote:
>   
>> Julien Vehent wrote:
>>     
>>> Hello Nicholas,
>>>
>>>
>>> On Mon, 27 Jul 2009 13:56:59 -0400, NICHOLAS KLINE <nkline@kent.edu>
>>> wrote:
>>>   
>>>       
>>>> Hi,
>>>>
>>>> I have a fresh install of Ubuntu 8.x desktop edition running on a
>>>> laptop. Before I plug the laptop into a public network and proceed to
>>>> patch it, I want to make sure I have a secure firewall in place.
>>>>
>>>> This particular system will not be running any server services such as
>>>> HTTPD, SSH, FTP, etc. Inbound traffic should be denied unless an
>>>> outbound connection was first established.
>>>> I will mostly be using a wired internet connection but I might switch
>>>> to wireless once in awhile.
>>>>
>>>> After reading a few Linux security books, I have a decent set of
>>>> firewall rules almost ready to put into place. The only rule
>>>> preventing me from putting the firewall in place is:
>>>>     
>>>>         
>> ...
>>
>>     
>>>> # Set default-deny policies for all chains.
>>>> # User-defined chains cannot be assigned default policies.
>>>> $IPTABLES -P INPUT DROP
>>>> $IPTABLES -P FORWARD DROP
>>>> $IPTABLES -P OUTPUT DROP
>>>>
>>>> $IPTABLES -t nat -P PREROUTING DROP
>>>> $IPTABLES -t nat -P OUTPUT DROP
>>>> $IPTABLES -t nat -P POSTROUTING DROP
>>>>
>>>> $IPTABLES -t mangle -P PREROUTING DROP
>>>> $IPTABLES -t mangle -P OUTPUT DROP
>>>>
>>>>     
>>>>         
>>> I don't like the default policy because you can't log anything in these
>>> rules.
>>> I prefer to put at the end of the ruleset something like
>>> --------
>>>    echo "Default log drop, at the end so we just drop what doesn't
>>>       
> match
>   
>>> the
>>> previous rules"
>>>    $IPT -N LOGDROP
>>>    $IPT -A LOGDROP -j LOG --log-prefix "DROP => " --log-level debug
>>>    $IPT -A LOGDROP -j DROP
>>>
>>>    $IPT -A INPUT -i $NETCARD -j LOGDROP
>>>    $IPT -A OUTPUT -o $NETCARD -j LOGDROP
>>> --------
>>> that allows you to log and then drop, instead of just dropping.
>>>
>>>
>>>   
>>>       
>> Why not just put a log rule as the final rule and let the policy drop 
>> the packet? That way there's less rules and traffic gets logged and
>> dropped.
>>
>>     
>
> You would not log the firewall's decision then. Only the packet details.
>
>   
iptables -A INPUT -j LOG --log-prefix "INPUT_POLICY_DROP: " ...
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT_POLICY_DROP: " ...
iptables -A FORWARD -j LOG --log-prefix "FORWARD_POLICY_DROP: " ...

policies do the rest. IMHO you get to know everything you need.

greets

Mart

Re: Firewall Configuration Help

[Christoph A.]

[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]

On 28.07.2009 11:09, Julien Vehent wrote:
>> # The following will NOT interfere with local inter-process traffic,
> whose
>> # packets have the source IP of the local loopback interface, e.g.
>> 127.0.0.1
>>
>> $IPTABLES -A INPUT -s $IP_LOCAL -j LOG --log-prefix "Spoofed source IP"
>> $IPTABLES -A INPUT -s $IP_LOCAL -j DROP
>>
>> # Tell netfilter that all TCP sessions do indeed begin with SYN
>>
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG
>> --log-prefix "Stealth scan attempt?"
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>>
>>
> 
> My understanding of the conntrack subsystem is that a connection cannot be
> in the state NEW without a syn packet, therefore I don't think this is
> useful.


I also thought that such a packet has the state INVALID, but after
making some tests I saw that such TCP packets (! --syn with state NEW)
are possible, but considering his hole ruleset these packets would be
DROPed anyway by his default policy, because he has no
-A INPUT ... --state NEW -j ACCEPT
rules in his ruleset.
This means that the rule is redundant and should be removed to minimize
the number of rules.

Just for the record, I tested it like this:
I generated a packet with hping that has only the ACK flag set and
to see the state I created some logging rules:

iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state NEW -j
LOG --log-prefix "NEW_: "
iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state RELATED
-j LOG --log-prefix "RELATED_: "
iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state
ESTABLISHED -j LOG --log-prefix "ESTABLISHED_: "
iptables -A INPUT -p tcp --sport 9999 ! --syn -m state --state INVALID
-j LOG --log-prefix "INVALID_: "


test #1: (ACK flag set)
hping3 -c 1 -I wlan0 -A -s 9999 -p 1110 localhost

Logging output:
NEW_: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=192.168.1.33 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=4943
PROTO=TCP SPT=9999 DPT=1110 WINDOW=512 RES=0x00 ACK URGP=0

state => NEW
------------------------------------------------------
test #2 (no TCP flags set):
hping command:

hping -c 1 -I wlan0 -s 9999 -p 1111 localhost

Logging output:
INVALID_: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=192.168.1.33 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=9687
PROTO=TCP SPT=9999 DPT=1111 WINDOW=512 RES=0x00 URGP=0

(test was made with iptables v1.4.3.1)


On 05.08.2009 15:35, Mart Frauenlob wrote:
> Wrong, from the iptables tutorial 1.2.2 at frozentux:
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#STATEMACHINE
>
> The NEW state tells us that the packet is the first packet that we see.
> This means that the first packet that the conntrack module sees, within
> a specific connection, will be matched. For example, if we see a SYN
> packet and it is the first packet in a connection that we see, it will
> match. However, the packet may as well not be a SYN packet and still be
> considered NEW.

Given this fact I'm reconsidering my rules like:

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT

to be changed to:
iptables -A INPUT -p tcp --dport 80 --syn -j ACCEPT
(because this is the samller group of packets and works as well)

best regards,
Christoph A.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]