l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 16:57

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] ipchains/firewall question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] ipchains/firewall question

On Wed, Oct 18, 2000 at 04:32:18PM -0700, Peter Jay Salzman wrote:
> yes, i'm absolutely, positively fantstically, unequivocally, super-duper sure.
> i don't even want to talk to support1.adobe.com (
> i hope i convinced you i don't want to talk with *anyone* whose ip address
> starts with 192.   i would go even farther -- i don't even want to talk to
> anyone with an ip address of 19*.*.*.
> did i forget to mention to you that i really don't want to talk to any ip
> address that begins with 192?  :)
> why not?  if nobody comes a-knockin', nobody here wants to listen...
> that's what i plan to do.  it'll take awhile to compile the addresses, but
> in the meantime...

With all due respect...

I cannot fathom why you are discussing blocking or 19*.*.*.*.
This indicates a basic lack of understanding about IP routing, netmasks,
and (drum roll) an appropriate network design.

Either you are being silly (which makes for a short career in the
firewalls field), or you really shouldn't be building firewall rulesets.

As Micah mentioned the internal network space is and
should be blocked from reaching the world, or the world reaching in to
you.  Other spaces are and

Also, rather than removing access from 19*.*.*.*, you should probably
focus on what you will allow, with a default of deny.

As such, 
  block traffic to or from the following networks via any public
  Install a default INPUT policy of DENY.
  Install a ACCEPT rule for your management IP ranges

Notice that last one?

And for completeness your proposed ruleset is totally and completely
wrong (it correct to the question you asked, but wrong from a proper
network design standpoint).  Here it is again:

  ipchains -A input -s -i eth0 -j DENY

According to your design eth0 is the public side.  Blocking packets
sourced from is pointless.  You want to block packets destined
for your internal network of

The following ruleset snippet is more correct, though not anywhere near
  ipchains -F input
  ipchains -P input DENY
  # block stuff we should never even receive    # REDUNDANT given policy
  ipchains -A input -s -i eth0 -j DENY
  ipchains -A input -s -i eth0 -j DENY
  ipchains -A input -s -i eth0 -j DENY
  # block stuff we should never even receive    # REDUNDANT given policy
  ipchains -A input -d -i eth0 -j DENY
  ipchains -A input -d -i eth0 -j DENY
  ipchains -A input -d -i eth0 -j DENY
  # allow some management
  ipchains -A input -s pete's_home_ip/32 -i eth0 -j ACCEPT

It's not my point to belittle or ridicule, but security is exceptionally
important.  To hear the lack of understanding on this issue flaunted is
very discomforting.  

Get an expert.  Sit at their feet.  Learn.  

Ted Deppner

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.