there is no need to not compile modules for iptables, they're not going to be
loaded unless you want to. Also, there have been no security issues with the
state module since it has been declared stable. you're safe even using ftp
state tracking(a separate module that needs to be explicitly loaded) as long
as you're using kernels 2.4.4-2.4.9, and 2.4.11-2.4.18. to the original
author, you didn't specify enough of your rules to ensure you're safe or not,
you could still allow some funny stuff with your rules allowing someone to
circumvent your configuration. see
http://www.securityfocus.com/cgi-bin/unix_topics.pl?topic=fwrules for some
iptables examples (mine is #6): i'll point out some key parts right now about
what's needed to make sure someone doesnt abuse your rules:
### beware of line wraps,if it doesn't start with iptables,it's not a new line
# $INTNET is your internal network, $INTIF is the internal interface
# $EXTIP is the ip of your external interface, $EXTIF is the external
interface
####
## here we're setting the default policy for particular chains
#we set prerouting and postrouting to accept because putting it to drop adds
# a bunch of rules to our file it blocks stuff before or after it's been
# routed so the order goes like this
# /-input-----\
# packet -> prerouting--forward--------postrouting
# \-output---/
# so blocking stuff in prerouting will stop it from getting to the input,
# forward or output chains, regardless of what they say.
# so a default policy of drop in either one would require an extra pre/post
# accept for each input,output, forward accept rule you add
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
# i allow everything to input to the local machine because i deny it later on
# however you may want to change this to drop and add a rule for port 22 on
# the internal side to allow ssh on the inside to administer the box
iptables -P INPUT ACCEPT
# output is stuff leaving the local machine, usually should be accept
# however you may want to add rules to deny this on packets leaving
# the external interface, and/or the internal one on all ports but 22 tcp
# so the firewall itself can't talk to anything but the internal network over
#ssh, but can still forward/nat packets as it should.
iptables -P OUTPUT ACCEPT
# forward is packets we'll forward through, should be drop in any setup
iptables -P FORWARD DROP
## do the actual network address translation
# notice that it says that only stuff coming from the internet network, going
# somewhere that's not the internal network, and which is going to leave the
# external interface, change it's source address to the external ip.
# this is done this way to prevent the ip's from my intnet from getting natted
# when talking to machines on the 3rd interface, but it also is exactly
# specific to what you want, so it's more secure, or something
iptables -t nat -A POSTROUTING -s $INTNET -d ! $INTNET -o $EXTIF -j SNAT
--to $EXTIP
## allow the internal net to be forwarded
# this is needed so the packets will actually get forwarded, i could add the
# -o extif or -i intif from above but this would mean i would have to add
# more rules for my 3rd network, but most people would want to add it
iptables -A FORWARD -s $INTNET -d ! $INTNET -j ACCEPT
## configure stateful stuff
# we allow and track new connections originating from the internal network
# only if it's destination is not the internal network, and it came in on the
# internal network's interface, and will go out the external interface
iptables -A FORWARD -m state --state NEW -i $INTIF -o $EXTIF -s $INTNET
-d ! $INTNET -j ACCEPT
# here we allow packets back in if they match an existing state, only if they
# come in on the external interface, and their source is not the internal
# network. a lot of the specificity of these rules will help make your
# filtering more ingress/egress'ish
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -i $EXTIF -s !
$INTNET -j ACCEPT
On Tuesday 23 April 2002 01:14 pm, Sandro Littke wrote:
> Am Die, 2002-04-23 um 12.19 schrieb Ferry van Steen:
> > Hey there,
>
> Hey too,
>
> > accepting traffic from the internet part of an existing connection (with
> > the iptables -m state --state ESTABLISHED,RELATED).
>
> obviously you are using Netfilter's state machine features. Currently i
> would expect any remaining netfilter bug most probably in the state
> machine/conntrack code. We have seen some of them, for example dealing
> with ftp and RELATED. If you dont need RELATED feature for ftp, irc etc,
> just dont use it, this might be the safest approach. I guess, this is
> impossible for you, so have a look at your kernel version: check out the
> security announcements at netfilter.org. You can see that kernels prior
> to 2.4.18 arent good enough for your business.
> At the opportunity of compiling your own kernel you should disable any
> netfilter feature you dont use, maybe irc or ftp conntrack too.
> To summarize: Maybe there are thousands of bugs in netfilter, if you
> careful watch out for cleaned kernels you are almost safe, unless your
> business shows enhanced security needs by threat analyses.
> Basically you want to be protected against hackers from outside, working
> at weekend: If you feel unsafe up to now, you have some options: (1) add
> another firewall serial to your first system, ideally not Linux -
> OpenBSD with (maybe) stealth firewalling (bridging, non IPs-
> interfaces). In this case there is no need for re-adressing your
> internal nets. (2) On the other hand intrusion detection (might) help,
> but needs a lot more expertise and payed attention, so (1) would be my
> first choice. Option (3) is just another reminder: reduce or stop
> 'unsafe' protocols :-)
> But: if you got trojan horses or evil users inside your network, you are
> lost. Any experienced coder nowadays uses 'unsuspicious' protocols
> (http, dns) for transmissions. A concept for content security (packet:
> ids, stream: virus scanners etc) _might_ help, but attacks designed only
> to your company will succeed even in this case.
>
>
> Best regards,
>
> Sandro Littke.
