From: David Cannings <lists@edeca.net>
To: netfilter@lists.netfilter.org
Subject: Re: Firewall Script Help
Date: Mon, 8 Mar 2004 20:12:34 +0000 [thread overview]
Message-ID: <200403082012.34162.lists@edeca.net> (raw)
In-Reply-To: <JKELJHHMDHPOLKFBOEGHMECLFDAA.cldavis@speakeasy.net>
On Monday 08 March 2004 19:19, Christopher Davis wrote:
> David:
> > Just a quick point, it is (in my opinion at
> > least) far easier to read your
> > firewall rules if they're output from iptables
> > itself. Following through
> > the script is harder.
> Here it is! If it is easier to read, I can forward indivual
> txt docs with the same information -- I didn't want to
> attach anything being sent to the list.
Only a few comments, your script seems fairly comprehensive.
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 DROP all -- any any anywhere
> anywhere state INVALID
> 0 0 ACCEPT all -- any any anywhere
> anywhere state RELATED,ESTABLISHED
> 0 0 ACCEPT all -- lo any anywhere
> anywhere
> 0 0 DROP tcp -- any any anywhere
> anywhere tcp flags:FIN,ACK/FIN
> 0 0 DROP tcp -- any any anywhere
As I understand it, this means "check the flags FIN and ACK, only match if
FIN is set and ACK isn't". This would match packets that only have the
FIN flag set, which I am fairly sure are valid. I may need correcting on
this issure, however.
> anywhere tcp dpt:ssh
> 0 0 DROP tcp -- any any anywhere
Do you really want anybody in the world able to connect to your SSH
server? Personally, I only allow from IP addresses ranges that I know.
If you're on DHCP on your home connection, allow the whole /24 or
even /16 address pool the IP comes from. That still leaves a few billion
hosts unable to connect to you.
I say this purely from a paranoid point of view. As soon as a remote
exploit is found in SSH malicious people can possibly take advantage of
it.
> anywhere tcp flags:SYN/SYN
> 0 0 DROP tcp -- any any anywhere
Perhaps use the NEW keyword here, it might help.
> Chain BADIP (0 references)
> pkts bytes target prot opt in out source
> destination
You don't reference this chain anywhere. Perhaps you should -I a
reference to it at the top of the INPUT and OUTPUT chains.
Blocking INVALID packets may do what you do with manual --tcp-flags
checks, as I do not know the specific internals of it. In short, it
blocks packets that aren't related to existing connections but I am
unsure whether it will also block "illegal" packets so I cannot comment.
David
next prev parent reply other threads:[~2004-03-08 20:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-08 18:47 Firewall Script Help Christopher Davis
2004-03-08 18:49 ` David Cannings
2004-03-08 19:19 ` Christopher Davis
2004-03-08 20:12 ` David Cannings [this message]
2004-03-08 20:32 ` Antony Stone
2004-03-09 4:34 ` Mark E. Donaldson
2004-03-08 18:51 ` Aldo S. Lagana
-- strict thread matches above, loose matches on Subject: below --
2004-03-08 21:14 cldavis
2004-03-08 22:06 ` Antony Stone
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=200403082012.34162.lists@edeca.net \
--to=lists@edeca.net \
--cc=david@edeca.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox