* ruleset
@ 2004-07-20 14:58 Brent Clark
2004-07-20 15:37 ` ruleset Antony Stone
0 siblings, 1 reply; 9+ messages in thread
From: Brent Clark @ 2004-07-20 14:58 UTC (permalink / raw)
To: iptables
Hi all
Sorry to be a pain about this
But hopefully im getting there. No cant say im not learning.
Below is a copied and pasted ruleset.
Anyone care to have a look, it would really be appreciated.
I have concentrated on more FORWARDS and removing unnessacary DROPS, like i
mistakenly previously had (Thanks Anthony for putting me on the right road)
Thanks in advance to anyone who would care to assist
Kind Regards
Brent Clark
P.s. Sorry been a pain, but im determined to get this right and understand
iptables more fully.
============================================================================
============================
#/bin/sh
# Rules for gateway
#Clear \ Flush all the rules from the different chains and tables
/sbin/iptables --flush
/sbin/iptables --flush INPUT #Flush the INPUT chain
/sbin/iptables --flush OUTPUT #Flush the OUTPUT chain
/sbin/iptables --flush FORWARD #Flush the FORWARD chain
/sbin/iptables -t nat --flush #Flush the nat table
/sbin/iptables -t mangle --flush #Flush the mangle table
/sbin/iptables --delete-chain #Delete any pre-existing chains
/sbin/iptables -t nat --delete-chain #Delete any pre-existing chains from
nat table
/sbin/iptables -t mangle --delete-chain #Delete any pre-existing chains from
the mangle table
#Setting the default Policies for the chains
/sbin/iptables --policy INPUT DROP #Setting the default policy for INPUT
chain
/sbin/iptables --policy FORWARD DROP #Setting the default plicy for FORWARD
chain
/sbin/iptables --policy OUTPUT DROP #Setting the default policy for the
OUTPUT chain
#Create new chain
/sbin/iptables -N LOG_DROP #Create new chain
/sbin/iptables -N LOG_ACCEPT #Create new chain
#Accepting traffic for and to internal interface
/sbin/iptables -A INPUT -i lo -j ACCEPT #Allowing unlimited loopback
traffic
/sbin/iptables -A OUTPUT -o lo -j ACCEPT #Allowing unlimited loopback
traffic
###########################################################
#Stealth Scans and TCP state flags
#
# All of the bits are cleared
#/sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# SYN and FIN are both set
#/sbin/iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
# SYN and RST are both set
#/sbin/iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
# FIN and RST are both set
#/sbin/iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
# FIN is the only bit set, without the expected accompanying ACK
#/sbin/iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
# PSH is the only bit set, without the expected accompanying ACK
#/sbin/iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
# URG is the only bit set, without the expected accompanying ACK
#/sbin/iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
###########################################################
# Using Connection State to By-Pass checking
# Creating the rules
/sbin/iptables -t nat -A POSTROUTING -o eth0 -s 192.168.111.0/24 -d 0/0 -j
MASQUERADE
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT #NOTE TO SELF - NEED TO
MAKE THIS MORE TIGHTER
/sbin/iptables -A INPUT -m state --state INVALID -j LOG --log-prefix
"INVALID input: "
/sbin/iptables -A INPUT -m state --state INVALID -j DROP
/sbin/iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix
"INVALID output: "
/sbin/iptables -A OUTPUT -m state --state INVALID -j DROP
##########################################################
/sbin/iptables -A INPUT -i eth0 -p udp -d 224.0.0.0/4 -j ACCEPT
############################################################
# Allow for resolving of DNS and lookup from gate
/sbin/iptables -A OUTPUT -o eth0 -p udp --dport 53 -m state --state NEW -j
ACCEPT
/sbin/iptables -A INPUT -i eth1 -p udp --sport 53 -m state --state NEW -j
ACCEPT
/sbin/iptables -A FORWARD -p udp --sport 53 -m state --state NEW -j ACCEPT
#############################################################
# Allow for mail traffic
/sbin/iptables -A OUTPUT -o eth0 -p tcp --dport 25 -m state --state NEW -j
ACCEPT
/sbin/iptables -A FORWARD -o eth0 -p tcp --dport 25 -m state --state NEW -j
ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -p tcp -s 192.168.111.0/24 --dport
110 -m state --state NEW -j ACCEPT
/sbin/iptables -A OUTPUT -o eth0 -p tcp -s 192.168.111.0/24 --dport 110 -m
state --state NEW -j ACCEPT
#############################################################
# Allow access gate from 192.168.111.0/255.255.255.0
/sbin/iptables -A INPUT -i eth1 -p all -s 192.168.111.0/24 -j ACCEPT
/sbin/iptables -A FORWARD -p all -s 192.168.111.0/24 -d 192.168.111.0/24 -j
ACCEPT
/sbin/iptables -A OUTPUT -o eth1 -p all -s 192.168.111.0/24 -j ACCEPT
############################################################
# Allow access to port 80(http) and 443(https) to the gate
/sbin/iptables -A FORWARD -o eth0 -p tcp -m multiport --dport 80,443 -m
state --state NEW -j ACCEPT
/sbin/iptables -A OUTPUT -o eth0 -p tcp -m multiport --dport 80,443 -m
state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -i eth1 -s 192.168.111.0/24 -p tcp -m
multiport --dport 80,443 -m state --state NEW -j ACCEPT
###########################################################
# Allowing ssh to remote servers
/sbin/iptables -A OUTPUT -o eth0 -p tcp --dport 22 -m state --state NEW -j
ACCEPT
/sbin/iptables -A INPUT -i eth0 -p tcp ! --syn --sport 22 -j ACCEPT
###########################################################
# FTP ACCESS
/sbin/iptables -A FORWARD -o eth0 -p tcp -m multiport --dport 20,21 -m
state --state NEW -j ACCEPT
/sbin/iptables -A OUTPUT -o eth0 -p tcp -m multiport --dport 20,21 -m
state --state NEW -j ACCEPT
#/sbin/iptables -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
###########################################################
# Ntp update
/sbin/iptables -A OUTPUT -o eth0 -p udp -m state --state NEW --dport 123 -j
ACCEPT
/sbin/iptables -A INPUT -i eth1 -p udp --sport 123 -m state --state NEW -j
ACCEPT
#/sbin/iptables -A INPUT -p tcp -m tcp --dport 123 -j ACCEPT
#/sbin/iptables -A OUTPUT -p tcp -m tcp --dport 123 -j ACCEPT
#############################################################
# Allowing me to ping from here and dealing in ICMP packets
/sbin/iptables -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
/sbin/iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
/sbin/iptables -A INPUT -p icmp --icmp-type destination-unreachable -j
ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --icmp-type time-exceeded -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp --icmp-type source-quench -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp --icmp-type parameter-problem -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
/sbin/iptables -A OUTPUT -p icmp --icmp-type echo-request -m state --state
NEW -j ACCEPT
/sbin/iptables -A OUTPUT -o eth1 -p icmp --icmp-type
destination-unreachable -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p icmp --icmp-type ! echo-request -j LOG
############################################################
# Create some logging
/sbin/iptables -A INPUT -j LOG_DROP
/sbin/iptables -A OUTPUT -j LOG_DROP
/sbin/iptables -A LOG_DROP -j LOG --log-prefix "[IPTABLES DROP]:
" --log-tcp-options --log-ip-options
/sbin/iptables -A LOG_DROP -j DROP
/sbin/iptables -A LOG_ACCEPT -j LOG --log-prefix "[IPTABLES ACCEPT]:
" --log-tcp-options --log-ip-options
/sbin/iptables -A LOG_ACCEPT -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_dynaddr #
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians #Enable logging for
malformed Ip Address
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ruleset
2004-07-20 14:58 ruleset Brent Clark
@ 2004-07-20 15:37 ` Antony Stone
2004-07-20 16:02 ` ruleset Brent Clark
0 siblings, 1 reply; 9+ messages in thread
From: Antony Stone @ 2004-07-20 15:37 UTC (permalink / raw)
To: iptables
On Tuesday 20 July 2004 3:58 pm, Brent Clark wrote:
> Hi all
>
> Below is a copied and pasted ruleset.
> Anyone care to have a look, it would really be appreciated.
<snip...>
> # Allow for resolving of DNS and lookup from gate
>
> /sbin/iptables -A OUTPUT -o eth0 -p udp --dport 53 -m state --state NEW -j
> ACCEPT
> /sbin/iptables -A INPUT -i eth1 -p udp --sport 53 -m state --state NEW -j
> ACCEPT
> /sbin/iptables -A FORWARD -p udp --sport 53 -m state --state NEW -j ACCEPT
Is your firewall running a DNS server? If so, you want the INPUT rule. If
not (ie: you are passing DNS requests through to somewhere else), you want
the FORWARD rule. I'd be surprised if you really want both.
Why do you specify source port 53 in the FORWARD rule instead of destination
port 53? The reply packets are already taken care of by the
ESTABLISHED,RELATED rule.
> # Allow access gate from 192.168.111.0/255.255.255.0
>
> /sbin/iptables -A INPUT -i eth1 -p all -s 192.168.111.0/24 -j ACCEPT
You want *all* machines on 192.68.111.0./24 to have access to *all* services
on the firewall??
> /sbin/iptables -A FORWARD -p all -s 192.168.111.0/24 -d 192.168.111.0/24 -j
> ACCEPT
This one makes no sense. Packets from one subnet to another machine on the
same subnet do not go through the firewall.
> # Allow access to port 80(http) and 443(https) to the gate
>
> /sbin/iptables -A INPUT -i eth1 -s 192.168.111.0/24 -p tcp -m
> multiport --dport 80,443 -m state --state NEW -j ACCEPT
You are running an http/s server on the firewall???
> #/sbin/iptables -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
You are running an FTP server on the firewall as well as HTTP, HTTPS and
perhaps DNS??? Something makes me think you don't know about good security
practice saying "don't run uneccessary (some people say "any") services on
your firewall, as a compromise of one service can lead to a compromise of the
firewall".
Regards,
Antony.
--
"It would appear we have reached the limits of what it is possible to achieve
with computer technology, although one should be careful with such
statements; they tend to sound pretty silly in five years."
- John von Neumann (1949)
Please reply to the list;
please don't CC me.
^ permalink raw reply [flat|nested] 9+ messages in thread* RE: ruleset
2004-07-20 15:37 ` ruleset Antony Stone
@ 2004-07-20 16:02 ` Brent Clark
2004-07-20 16:13 ` ruleset Antony Stone
0 siblings, 1 reply; 9+ messages in thread
From: Brent Clark @ 2004-07-20 16:02 UTC (permalink / raw)
To: iptables
Hi all and Anthony
Thanks for replying.
In terms of "I know know nothing about security", unfortunately I have a
budget and expenditure to worry about, therefore, I cant really afford to
spend to much on machine etc. Therefore I am forced to run a few services on
the FW.
I am running a small dns server (pdnsd).
And I am running apache for the sake of my bandwith logging util (bandwithd,
bandwithd.sourceforge.org - REALLY NICE TOOL).
thanks for your assistance and pointers.
Really appreciate it.
Kind Regards
Brent Clark
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Antony Stone
Sent: Tuesday, July 20, 2004 5:37 PM
To: iptables
Subject: Re: ruleset
On Tuesday 20 July 2004 3:58 pm, Brent Clark wrote:
> Hi all
>
> Below is a copied and pasted ruleset.
> Anyone care to have a look, it would really be appreciated.
<snip...>
> # Allow for resolving of DNS and lookup from gate
>
> /sbin/iptables -A OUTPUT -o eth0 -p udp --dport 53 -m state --state NEW -j
> ACCEPT
> /sbin/iptables -A INPUT -i eth1 -p udp --sport 53 -m state --state NEW -j
> ACCEPT
> /sbin/iptables -A FORWARD -p udp --sport 53 -m state --state NEW -j ACCEPT
Is your firewall running a DNS server? If so, you want the INPUT rule.
If
not (ie: you are passing DNS requests through to somewhere else), you want
the FORWARD rule. I'd be surprised if you really want both.
Why do you specify source port 53 in the FORWARD rule instead of destination
port 53? The reply packets are already taken care of by the
ESTABLISHED,RELATED rule.
> # Allow access gate from 192.168.111.0/255.255.255.0
>
> /sbin/iptables -A INPUT -i eth1 -p all -s 192.168.111.0/24 -j ACCEPT
You want *all* machines on 192.68.111.0./24 to have access to *all* services
on the firewall??
> /sbin/iptables -A FORWARD -p all -s 192.168.111.0/24 -d
192.168.111.0/24 -j
> ACCEPT
This one makes no sense. Packets from one subnet to another machine on the
same subnet do not go through the firewall.
> # Allow access to port 80(http) and 443(https) to the gate
>
> /sbin/iptables -A INPUT -i eth1 -s 192.168.111.0/24 -p tcp -m
> multiport --dport 80,443 -m state --state NEW -j ACCEPT
You are running an http/s server on the firewall???
> #/sbin/iptables -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
You are running an FTP server on the firewall as well as HTTP, HTTPS and
perhaps DNS??? Something makes me think you don't know about good security
practice saying "don't run uneccessary (some people say "any") services on
your firewall, as a compromise of one service can lead to a compromise of
the
firewall".
Regards,
Antony.
--
"It would appear we have reached the limits of what it is possible to
achieve
with computer technology, although one should be careful with such
statements; they tend to sound pretty silly in five years."
- John von Neumann (1949)
Please reply to the
list;
please don't CC
me.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: ruleset
2004-07-20 16:02 ` ruleset Brent Clark
@ 2004-07-20 16:13 ` Antony Stone
2004-07-20 16:31 ` ruleset Brent Clark
0 siblings, 1 reply; 9+ messages in thread
From: Antony Stone @ 2004-07-20 16:13 UTC (permalink / raw)
To: iptables
On Tuesday 20 July 2004 5:02 pm, Brent Clark wrote:
> Hi all and Antony
>
> Thanks for replying.
> In terms of "I know know nothing about security",
Sorry - I didn't mean it to sound like that - I was trying to say that your
ruleset suggested you were running services on the firewall; running services
on the firewall is not good security practice; therefore I simply wondered
whether you knew about this maxim.
> unfortunately I have a
> budget and expenditure to worry about, therefore, I cant really afford to
> spend to much on machine etc. Therefore I am forced to run a few services
> on the FW.
No problem - just so long as you're aware of the risks :)
Regards,
Antony.
--
Never automate fully anything that does not have a manual override capability.
Never design anything that cannot work under degraded conditions in emergency.
Please reply to the list;
please don't CC me.
^ permalink raw reply [flat|nested] 9+ messages in thread* RE: ruleset
2004-07-20 16:13 ` ruleset Antony Stone
@ 2004-07-20 16:31 ` Brent Clark
0 siblings, 0 replies; 9+ messages in thread
From: Brent Clark @ 2004-07-20 16:31 UTC (permalink / raw)
To: iptables
Hi
It kewl, Im just greatfull that someone is prepared to look at my ruleset.
I basically need and want to be at secure as I possibly can. Give that my
management is so tight with the funding.
And I appreciate you concern.
Kind Regards and thanks again
Brent Clark
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Antony Stone
Sent: Tuesday, July 20, 2004 6:14 PM
To: iptables
Subject: Re: ruleset
On Tuesday 20 July 2004 5:02 pm, Brent Clark wrote:
> Hi all and Antony
>
> Thanks for replying.
> In terms of "I know know nothing about security",
Sorry - I didn't mean it to sound like that - I was trying to say that your
ruleset suggested you were running services on the firewall; running
services
on the firewall is not good security practice; therefore I simply wondered
whether you knew about this maxim.
> unfortunately I have a
> budget and expenditure to worry about, therefore, I cant really afford to
> spend to much on machine etc. Therefore I am forced to run a few services
> on the FW.
No problem - just so long as you're aware of the risks :)
Regards,
Antony.
--
Never automate fully anything that does not have a manual override
capability.
Never design anything that cannot work under degraded conditions in
emergency.
Please reply to the
list;
please don't CC
me.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Ruleset
@ 2004-08-10 7:22 Brent Clark
2004-08-10 8:27 ` Ruleset Antony Stone
0 siblings, 1 reply; 9+ messages in thread
From: Brent Clark @ 2004-08-10 7:22 UTC (permalink / raw)
To: iptables
Hi all
When I learn \ try something new, I tend to post my findings and or config
file etc, in the hope of someone out there
would be kind so share their views, points, critism, experiences etc.
This time ive dabbling with DMZ and transparent proxy (squid).
If possible would someone be so kind as to have a look at my ruleset and if
possible, share some pointers.
I have another linux box (Ip address 192.168.3.3, connected to eth1 on the
FW)
I have a lan (192.168.2.0/24) connected to eth0
For my internet handling I have a ppp connection.
Im also currently toying with dyndns (ez-ipupdate).
Kind Regards
Brent Clark
============================================================================
==========================
#!/bin/sh -e
IP="/sbin/iptables"
#############################################################
# Flush clean all rules and chains
$IP --flush; #Delete all rules in chain or all chains
$IP --zero; #Zero counters in chain or all chains
$IP --table nat --flush; #Flush nat table
$IP --table mangle --flush; #Flush mangle table
$IP -X;
############################################################
# Default policy
$IP -t filter --policy INPUT DROP;
$IP -t filter --policy FORWARD DROP;
$IP -t filter --policy OUTPUT DROP;
#############################################################
# Create outside connections
$IP -t nat -A POSTROUTING -o ppp+ -s 192.168.2.0/24 -j MASQUERADE;
$IP -t nat -A POSTROUTING -o ppp+ -s 192.168.3.0/24 -j MASQUERADE;
#############################################################
# Established Rules
$IP -t nat -A PREROUTING -i ! ppp0 -p tcp --dport 80 -j REDIRECT --to-port
3128
$IP -t nat -A PREROUTING -i ppp+ -p tcp --dport 80 -j DNAT --to-destination
192.168.3.3
$IP -t filter -A INPUT -p all -s 127.0.0.1 -j ACCEPT;
$IP -t filter -A INPUT -i lo -p all -s 192.168.2.2 -d 192.168.2.2 -j ACCEPT;
$IP -t filter -A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID
INPUT DROP ";
$IP -t filter -A INPUT -m state --state INVALID -j DROP
$IP -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT;
$IP -t filter -A INPUT -i eth0 -p tcp --dport 22 -s 192.168.2.0/24 -m
state --state NEW -j ACCEPT;
$IP -t filter -A INPUT -i ! ppp0 -p udp --dport 53 -m state --state NEW -j
ACCEPT;
$IP -t filter -A INPUT -i ! ppp0 -p tcp --dport 53 -m state --state NEW -j
ACCEPT;
$IP -t filter -A INPUT -i ppp+ -p udp --sport 53 -m state --state NEW -j
ACCEPT;
$IP -t filter -A INPUT -i ppp+ -p tcp --sport 53 -m state --state NEW -j
ACCEPT;
$IP -t filter -A INPUT -i eth0 -p tcp --dport 80 -s 192.168.2.0/24 -m
state --state NEW -j ACCEPT;
$IP -t filter -A INPUT -i ! ppp0 -p tcp --dport 3128 -m state --state
NEW -j ACCEPT;
$IP -t filter -A INPUT -p udp --dport 135:139 -j DROP
$IP -t filter -A INPUT -p tcp --dport 135:139 -j DROP
$IP -t filter -A INPUT -p tcp --dport 445 -j DROP
$IP -t filter -A INPUT -p udp --dport 445 -j DROP
$IP -t filter -A INPUT -j LOG --log-prefix "INPUT DROP ";
$IP -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT;
$IP -t filter -A FORWARD -m state --state INVALID -j LOG --log-prefix
"INVALID FORWARD DROP ";
$IP -t filter -A FORWARD -m state --state INVALID -j DROP
$IP -t filter -A FORWARD -i eth0 -p all -d 192.168.2.255 -j LOG --log-prefix
"INVALID FORWARD DROP ";
$IP -t filter -A FORWARD -i eth0 -p all -d 192.168.2.255 -j DROP
$IP -t filter -A FORWARD -o ppp+ -m state --state NEW,ESTABLISHED,RELATED -j
ACCEPT;
#############################
# DMZ settings
$IP -t filter -A FORWARD -i ppp0 -o eth1 -m state --state NEW -j ACCEPT;
$IP -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j ACCEPT;
#$IP -t filter -A FORWARD -i eth1 -o eth0 -m state --state NEW -j ACCEPT;
$IP -t filter -A INPUT -i eth1 -p udp --dport 53 -m state --state NEW -j
ACCEPT;
############################
$IP -t filter -A FORWARD -j LOG --log-prefix "FORWARD DROP ";
$IP -t filter -A OUTPUT -m state --state INVALID -j LOG --log-prefix
"INVALID OUTPUT DROP ";
$IP -t filter -A OUTPUT -m state --state INVALID -j DROP
$IP -t filter -A OUTPUT -s 127.0.0.1 -j ACCEPT;
$IP -t filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT;
$IP -t filter -A OUTPUT -m state --state NEW -j ACCEPT;
#$IP -t filter -A OUTPUT -o eth0 -d 192.168.2.0/24 -j ACCEPT;
#$IP -t filter -A OUTPUT -o eth1 -d 192.168.3.0/24 -j ACCEPT;
$IP -t filter -A OUTPUT -j LOG --log-prefix "OUTPUT DROP ";
#################################################################
# Proc allows
echo 1 > /proc/sys/net/ipv4/ip_forward #Ip forwarding;
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians;
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Ruleset
2004-08-10 7:22 Ruleset Brent Clark
@ 2004-08-10 8:27 ` Antony Stone
2004-08-10 8:45 ` Ruleset Antony Stone
0 siblings, 1 reply; 9+ messages in thread
From: Antony Stone @ 2004-08-10 8:27 UTC (permalink / raw)
To: iptables
On Tuesday 10 August 2004 8:22 am, Brent Clark wrote:
> Hi all
>
> If possible would someone be so kind as to have a look at my ruleset and if
> possible, share some pointers. I have another linux box (Ip address
> 192.168.3.3, connected to eth1 on the FW) I have a lan (192.168.2.0/24)
> connected to eth0 For my internet handling I have a ppp connection. Im also
> currently toying with dyndns (ez-ipupdate).
1. For efficiency I would put the ESTABLISHED,RELATED rule first in your INPUT
chain.
2. I do not entirely approve of running a DNS server on the firewall. Since
you have another box availabel on 192.168.3.3 I would suggest running DNS on
that and redirecting requests (or configuring clients to know what's where to
find it).
3. I do not think you will see any packets addressed to 192.168.2.255 in the
FORWARD chain - they would appear in the INPUT chain. I also think they
should be logged as "BROADCAST", not as "INVALID".
4. Do you *really* want to allow *all* NEW packets from the Internet to the
DMZ, no matter what protocol they are? You might as well simply stick your
192.168.3.3 machine on a public IP address with no firewall....
5. For efficiency I would put the ESTABLISHED,RELATED rule first in your
OUTPUT chain.
6. The default DROP policy on OUTPUT is rather misleading (and may give you a
false sense of security), since the ruleset allows all NEW, ESTABLISHED, and
RELATED packets. That means everything which can be part of a connection.
Regards,
Antony.
--
The idea that Bill Gates appeared like a knight in shining armour to lead all
customers out of a mire of technological chaos neatly ignores the fact that
it was he who, by peddling second-rate technology, led them into it in the
first place.
- Douglas Adams in The Guardian, 25th August 1995
Please reply to the list;
please don't CC me.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Ruleset
2004-08-10 8:27 ` Ruleset Antony Stone
@ 2004-08-10 8:45 ` Antony Stone
2004-08-10 9:15 ` Ruleset Brent Clark
0 siblings, 1 reply; 9+ messages in thread
From: Antony Stone @ 2004-08-10 8:45 UTC (permalink / raw)
To: iptables
On Tuesday 10 August 2004 9:27 am, Antony Stone wrote:
> On Tuesday 10 August 2004 8:22 am, Brent Clark wrote:
> > Hi all
> >
> > If possible would someone be so kind as to have a look at my ruleset and
> > if possible, share some pointers. I have another linux box (Ip address
> > 192.168.3.3, connected to eth1 on the FW) I have a lan (192.168.2.0/24)
> > connected to eth0 For my internet handling I have a ppp connection. Im
> > also currently toying with dyndns (ez-ipupdate).
>
> 4. Do you *really* want to allow *all* NEW packets from the Internet to the
> DMZ, no matter what protocol they are? You might as well simply stick
> your 192.168.3.3 machine on a public IP address with no firewall....
The above comment is not quite accurate - you are, of course, only DNATting
packets to TCP port 80, therefore only HTTP should get through to the DMZ,
however I would still recommend narrowing down the FORWARD rule just to make
it obvious that's what's happening when you look at the filter rules, rather
than having to refer to the nat rules to figure out what traffic is being
allowed.
In other words, make the ruleset slightly more obvious, so you don't make the
same mistake I did, when you come to read the ruleset in 3 months' time :)
Regards,
Antony.
--
People who use Microsoft software should be certified.
Please reply to the list;
please don't CC me.
^ permalink raw reply [flat|nested] 9+ messages in thread* RE: Ruleset
2004-08-10 8:45 ` Ruleset Antony Stone
@ 2004-08-10 9:15 ` Brent Clark
0 siblings, 0 replies; 9+ messages in thread
From: Brent Clark @ 2004-08-10 9:15 UTC (permalink / raw)
To: iptables
Once again, thanks Anthony
Correcting my mistakes right now
Kind Regards
Brent Clark
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Antony Stone
Sent: Tuesday, August 10, 2004 10:45 AM
To: iptables
Subject: Re: Ruleset
On Tuesday 10 August 2004 9:27 am, Antony Stone wrote:
> On Tuesday 10 August 2004 8:22 am, Brent Clark wrote:
> > Hi all
> >
> > If possible would someone be so kind as to have a look at my ruleset and
> > if possible, share some pointers. I have another linux box (Ip address
> > 192.168.3.3, connected to eth1 on the FW) I have a lan (192.168.2.0/24)
> > connected to eth0 For my internet handling I have a ppp connection. Im
> > also currently toying with dyndns (ez-ipupdate).
>
> 4. Do you *really* want to allow *all* NEW packets from the Internet to
the
> DMZ, no matter what protocol they are? You might as well simply stick
> your 192.168.3.3 machine on a public IP address with no firewall....
The above comment is not quite accurate - you are, of course, only DNATting
packets to TCP port 80, therefore only HTTP should get through to the DMZ,
however I would still recommend narrowing down the FORWARD rule just to make
it obvious that's what's happening when you look at the filter rules, rather
than having to refer to the nat rules to figure out what traffic is being
allowed.
In other words, make the ruleset slightly more obvious, so you don't make
the
same mistake I did, when you come to read the ruleset in 3 months' time :)
Regards,
Antony.
--
People who use Microsoft software should be certified.
Please reply to the
list;
please don't CC
me.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-08-10 9:15 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-20 14:58 ruleset Brent Clark
2004-07-20 15:37 ` ruleset Antony Stone
2004-07-20 16:02 ` ruleset Brent Clark
2004-07-20 16:13 ` ruleset Antony Stone
2004-07-20 16:31 ` ruleset Brent Clark
-- strict thread matches above, loose matches on Subject: below --
2004-08-10 7:22 Ruleset Brent Clark
2004-08-10 8:27 ` Ruleset Antony Stone
2004-08-10 8:45 ` Ruleset Antony Stone
2004-08-10 9:15 ` Ruleset Brent Clark
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox