All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gáspár Lajos" <swifty@freemail.hu>
To: Gopinath <gopinath.u@gmail.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: Default deny rule
Date: Mon, 14 May 2007 14:33:17 +0200	[thread overview]
Message-ID: <4648570D.4040308@freemail.hu> (raw)
In-Reply-To: <d2af4f000705132302t3d8b2c8eo6158406d02af9f91@mail.gmail.com>

Gopinath írta:
> Please find the correct IP details below... Is it neccessary to
> upgrade my kernel and iptables to achieve NAT and Default deny
> functionality ?
Not neccessary but suggested... At least you should upgrade your 
iptables to 1.3.7.

Now I comment your rules... :D
> :INPUT ACCEPT [364:57615]
> :FORWARD ACCEPT [1:52]
> :OUTPUT ACCEPT [211:18044]
If there is no matching rule then EVERYTHING is ACCEPTED because your 3 
policies above is set to ACCEPT.
In DEFAULT DENY mode you should set these policies to DROP as mentioned 
in the previos mail of mine:

iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP


> -A INPUT -s 10.44.20.70 -p icmp -j ACCEPT
> -A INPUT -s 10.44.2.140 -p icmp -j ACCEPT
Here you enable 2 IPs to use ICMP (ping) on your host.
> -A INPUT -s 10.44.2.140 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -s 10.44.20.70 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -s 10.1.0.246 -p tcp -m tcp --dport 22 -j ACCEPT
The above 3 IPs are enabled to SSH to your host.
BUT IF YOU DO NOT SET THE DEFAULT POLICY TO DROP THEN THESE RULES ARE 
MEANINGLESS!!!

> -A FORWARD -s 10.2.10.240 -d 10.44.2.140 -i eth0 -o eth1 -p tcp -m
> state --state NEW -j ACCEPT
> -A FORWARD -s 10.2.10.240 -d 10.44.2.100 -i eth0 -o eth1 -p tcp -m
> state --state NEW -j ACCEPT
10.2.10.240 can create NEW connections to 10.44.2.100 and 10.44.2.140...

10.2.10.240 should be on eth0
10.44.2.100 should be on eth1
10.44.2.140 should be on eth1
> -A FORWARD -o eth0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
ANY host that sends ANY (NEW,RELATED,ESTABLISHED) packets through eth0 
(not only to 10.2.10.240) is ACCEPTED.
> -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
ANY host thar sends RELATED or ESTABLISED packets from eth0 (not only 
from 10.2.10.240) is ACCEPTED.
AGAIN IF YOU DO NOT SET THE DEFAULT POLICY TO DROP THEN THESE RULES ARE 
MEANINGLESS!!!

> *nat
> :PREROUTING ACCEPT [289:55706]
> :POSTROUTING ACCEPT [77:6468]
> :OUTPUT ACCEPT [77:6468]
These ACCEPTs are ok.
> -A PREROUTING -d 10.1.60.240 -i eth0 -j DNAT --to-destination 10.44.2.100
> -A PREROUTING -d 10.1.60.245 -i eth0 -j DNAT --to-destination 10.44.2.140
Anything that comes form eth0 and would go to 10.1.60.240 should go to 
10.44.2.100.
Anything that comes form eth0 and would go to 10.1.60.245 should go to 
10.44.2.140.

> -A POSTROUTING -s 10.44.2.100 -o eth0 -j SNAT --to-source 10.1.60.240
> -A POSTROUTING -s 10.44.2.140 -o eth0 -j SNAT --to-source 10.1.60.245
Anything that goes out on eth0 and comes from 10.44.2.100 should appear 
as it would come from 10.1.60.240.
Anything that goes out on eth0 and comes from 10.44.2.140 should appear 
as it would come from 10.1.60.245.

Maybe you do not need these last two rules at all because a DNAT rule 
simply does the reverse SNAT is most cases.
> # iptables -nv -L
>
> Chain INPUT (policy ACCEPT 100 packets, 14882 bytes)
You had 100 packets that did not matched ANY rule in the INPUT chain.
> pkts bytes target     prot opt in     out     source
> destination
>    0     0 ACCEPT     icmp --  *      *       10.44.20.70
> 0.0.0.0/0
>    0     0 ACCEPT     icmp --  *      *       10.44.2.140
> 0.0.0.0/0
>    0     0 ACCEPT     tcp  --  *      *       10.44.2.140
> 0.0.0.0/0           tcp dpt:22
>  356 24672 ACCEPT     tcp  --  *      *       10.44.20.70
> 0.0.0.0/0           tcp dpt:22
>    0     0 ACCEPT     tcp  --  *      *       10.1.0.246
> 0.0.0.0/0           tcp dpt:22
No connection, no ping yet ???
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source
> destination
>    0     0 ACCEPT     tcp  --  eth0   eth1    10.2.10.240
> 10.44.2.140         state NEW
>    0     0 ACCEPT     tcp  --  eth0   eth1    10.2.10.240
> 10.44.2.100         state NEW
>    0     0 ACCEPT     all  --  *      eth0    0.0.0.0/0
> 0.0.0.0/0           state NEW,RELATED,ESTABLISHED
>    0     0 ACCEPT     all  --  eth0   *       0.0.0.0/0
> 0.0.0.0/0           state RELATED,ESTABLISHED
>
No NAT yet ???
> Chain OUTPUT (policy ACCEPT 302 packets, 34150 bytes)
> pkts bytes target     prot opt in     out     source               
> destination
>
Just 302 packet that went out and no rule. Btw. maybe you do not want to 
filter your outgoing traffic.
In that case you should leave your OUTPUT policy as ACCEPT.
> Regards,
> Gopinath.U

I think that you want something else then what you did in your rules.
I would restart the whole project from the ground.

!!!
Please describe the connected networks and the target of the firewalling.
!!!

Here is a core script that may help you:
 (A bit long but can be usefull. And of course not working in current 
state... :D )

#!/bin/bash
echo "Setting up FIREWALL rules:"

core_set="/proc/sys/net/core"
ip_set="/proc/sys/net/ipv4"
echo                 0 > $ip_set/conf/all/rp_filter
echo                 1 > $ip_set/conf/all/proxy_arp
echo                 1 > $ip_set/icmp_echo_ignore_broadcasts
echo                 1 > $ip_set/ip_forward
echo             32768 > $ip_set/netfilter/ip_conntrack_max
echo                 1 > $ip_set/tcp_abort_on_overflow
echo                10 > $ip_set/tcp_fin_timeout
echo                 1 > $ip_set/tcp_rfc1337
echo                 1 > $ip_set/tcp_sack
echo                 2 > $ip_set/tcp_synack_retries
echo                 1 > $ip_set/tcp_syncookies
echo 16384 16384 16384 > $ip_set/tcp_wmem
echo             16384 > $core_set/rmem_default
echo             16384 > $core_set/wmem_default
echo             16384 > $core_set/wmem_max
sysctl -w net.ipv4.tcp_ecn=0 >/dev/null 2>/dev/null


modprobe ip_conntrack >/dev/null 2>/dev/null
modprobe ip_nat >/dev/null 2>/dev/null
modprobe iptable_nat >/dev/null 2>/dev/null

clean_subchain() {
 $table -F $subchain >/dev/null 2>/dev/null
 $table -X $subchain >/dev/null 2>/dev/null
 $table -Z $subchain >/dev/null 2>/dev/null
 }

create_subchain() {
 subchain=$1
 clean_subchain
 $table -N $subchain
 }

clean_table() {
 subchain=""
 clean_subchain
 }

table="iptables -t nat"
clean_table

chain="PREROUTING"
$table -P $chain ACCEPT

create_subchain "DNAT_of_eth0"
$table -A $chain -j $subchain -i eth0
$table -A $subchain -j DNAT -d 10.1.60.240 --to-destination 10.44.2.100
$table -A $subchain -j DNAT -d 10.1.60.245 --to-destination 10.44.2.140

chain="POSTROUTING"
$table -P $chain ACCEPT

chain="OUTPUT"
$table -P $chain ACCEPT


table="iptables -t filter"
clean_table

create_subchain "send_reject"
$table -A $subchain -j REJECT -p tcp --reject-with tcp-reset
$table -A $subchain -j REJECT --reject-with icmp-admin-prohibited
$table -A $subchain -j DROP

create_subchain "log_invalid"
$table -A $subchain -j LOG  --log-prefix "INVALID: " --log-level debug --log-tcp-sequence --log-tcp-options --log-ip-options
$table -A $subchain -j send_reject

create_subchain "con_icmp"
$table -A $subchain -j RETURN -p icmp --icmp-type echo-reply
$table -A $subchain -j RETURN -p icmp --icmp-type destination-unreachable
$table -A $subchain -j RETURN -p icmp --icmp-type source-quench
$table -A $subchain -j RETURN -p icmp --icmp-type echo-request -m hashlimit --hashlimit-name icmp --hashlimit 1/s --hashlimit-mode srcip
$table -A $subchain -j RETURN -p icmp --icmp-type time-exceeded
$table -A $subchain -j DROP -p icmp

create_subchain "con_udp"
#TODO

create_subchain "con_tcp"
$table -A $subchain -j RETURN -p tcp --syn -m conntrack --ctstate NEW
$table -A $subchain -j RETURN -m conntrack --ctstatus EXPECTED
$table -A $subchain -j log_invalid

create_subchain "connected"
$table -A $subchain -j ACCEPT -m conntrack --ctstate ESTABLISHED
$table -A $subchain -j ACCEPT -m conntrack --ctstate RELATED
$table -A $subchain -j RETURN -i lo -o lo
$table -A $subchain -j con_icmp -p icmp
$table -A $subchain -j RETURN -p icmp
$table -A $subchain -j con_udp -p udp
$table -A $subchain -j RETURN -p udp
$table -A $subchain -j con_tcp -p tcp
$table -A $subchain -j RETURN -p tcp

chain="INPUT"

$table -P $chain DROP

$table -A $chain -j connected

create_subchain "ICMP_ok"
$table -A $chain -j $subchain -p icmp
$table -j ACCEPT -s 10.44.20.70
$table -j ACCEPT -s 10.44.2.140

create_subchain "SSH_ok"
$table -A $chain -j $subchain -p tcp --dport 22
$table -j ACCEPT -s 10.1.0.246
$table -j ACCEPT -s 10.44.2.140
$table -j ACCEPT -s 10.44.20.70

chain="FORWARD"
$table -P $chain DROP

$table -A $chain -j connected

create_chain "enable_DNAT_to_eth1"
$table -A $chain -j $subchain -o eth1
$table -A $subchain -j ACCEPT -d 10.44.2.100
$table -A $subchain -j ACCEPT -d 10.44.2.140


chain="OUTPUT"
$table -P $chain ACCEPT

echo "done."



Swifty



  reply	other threads:[~2007-05-14 12:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-10  5:28 Default deny rule Gopinath
2007-05-11 10:09 ` Gáspár Lajos
2007-05-14  6:02   ` Gopinath
2007-05-14 12:33     ` Gáspár Lajos [this message]
     [not found]       ` <d2af4f000705150134r4d5bbf84r96d0f91aae9a725d@mail.gmail.com>
2007-05-21 16:03         ` Gáspár Lajos
2007-05-28 13:45           ` Gopinath
2007-05-29 13:04             ` Gáspár Lajos
2007-05-29 14:44               ` Gopinath
2007-05-30 10:25                 ` Gáspár Lajos
2007-05-31  5:11                   ` Gopinath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4648570D.4040308@freemail.hu \
    --to=swifty@freemail.hu \
    --cc=gopinath.u@gmail.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.