[gentoo-user] iptables example on Gentoo

[gentoo-user] iptables example on Gentoo

[James]

Hello,

I've been trying to build a simple firewall with a DMZ for a 
web server.
x.x.x.x is the local single static IP y.y.y.y is the gateway IP.
z.z.z.z is the broadcast.
Outward access is working (ip and dns) Currently the dns servers
I use are the cable modem company's, and they work just fine,
for now. I can download packages and ebuilds just fine. Access
to the mail servers outside the network works just fine.

Note: I have an openbsd firewall with a dmz & web server, and all
works just fine. It's disconnected while I try to get this gentoo
firewall working with the same web server and other lan components.

Following this simple example:
http://www.gentoo.org/doc/en/home-router-howto.xml

Here's what I did to add a DMZ based web server:

A. (3) ethernet interfaces are setup via ifconfig and are working.

B. /etc/conf.d.net
        I added these lines:
iface_eth0="192.168.2.20 broadcast 192.168.2.255 
netmask 255.255.255.0"
iface_eth1="192.168.3.11 broadcast 192.168.3.255 
netmask 255.255.255.0"
iface_eth2="x.x.x.x broadcast z.z.z.z 
netmask 255.255.255.252"
routes_eth2=( "default gw y.y.y.y" )

C. and here's the IP tables portion:
Start with ' iptables -F'  and 'iptables -t nat -F'



 export LAN=eth0
  export DMZ=eth1
  export WAN=eth2
  iptables -I INPUT 1 -i ${LAN} -j ACCEPT
  iptables -I INPUT 1 -i lo -j ACCEPT
  iptables -A INPUT -p UDP --dport bootps -i !
       ${LAN} -j REJECT
  iptables -A INPUT -p UDP --dport domain -i !
       ${LAN} -j REJECT
  iptables -A INPUT -p TCP -i ! ${LAN} -d 0/0 
       --dport 0:1023 -j DROP
  iptables -A INPUT -p UDP -i ! ${LAN} -d 0/0 
      --dport 0:1023 -j DROP
  iptables -I FORWARD -i ${LAN} -d 
       192.168.0.0/255.255.0.0 -j DROP
  iptables -A FORWARD -i ${LAN} -s 
      192.168.0.0/255.255.0.0 -j ACCEPT
  iptables -A FORWARD -i ${WAN} -d 
      192.168.0.0/255.255.0.0 -j ACCEPT
  iptables -t nat -A POSTROUTING -o 
      ${WAN} -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp 
      --dport 80 -i ${WAN} -j DNAT --to 192.168.3.11

D. Next:
echo 1 > /proc/sys/net/ipv4/ip_forward
  for f in /proc/sys/net/ipv4/conf/*/rp_filter ;
        do echo 1 > $f ; done

E. And finishing with:
  /etc/init.d/iptables save  
  rc-update add iptables default
  vi /etc/sysctl.conf
Add/Uncomment the following lines:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

Questions
Step C: Qestion 1:

The rule I added:
iptables -t nat -A PREROUTING -p tcp 
      --dport 80 -i ${WAN} -j DNAT --to 192.168.3.11

Does not give access to the web server, either from the outside
internet, nor from the interlan lan. Can somebody fix the rule
or tell me what I've done wrong or what is additionally needed?


Here are the error messages:
Warning: wierd character in interface `-j' (No aliases, :, ! or *).
Bad argument `DNAT'

Question 2:
Where are the config files, built by iptables (filter, nat,
 mangle,
 raw)
and is it OK to just edit these manually, trying various rules
and testing the results? Any other files to edit directly?

I've read about shorewall, but I prefer to
directly edit these files (and any others I have missed) directly
while I learn/test the features of iptables/netfilter. Shorewall
or any other gui, is for later, when I've develop a 
certain confidence
via understanding how iptables/netfilter works.

This is only a simple network, I'm setting up to mostly to 
learn about
iptables/netfilter. Any help or comments is appreciated. I intend
to slowly add features and rules and to test along the way, as 
to satisfy my
curiousity while learning firewalling on linux based systems.

James

-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] iptables example on Gentoo

[Dave Nebinger]

> I've been trying to build a simple firewall with a DMZ for a
> web server.

Dude, trying to use iptables directly was your first mistake.

Take a spin out and look at shorewall (I'm sure others have different
recommendations).

Shorewall will get you up and running in no time and will easily handle the
configuration stuff from your original post.

Trying to manage such a complex config using iptables directly is doomed to
failure; any mistake in ordering of rules, etc., will break your
connectivity.  Sticking with a tool like shorewall will simplify rules
maintenance and pose less of a problem when performing updates later on.

Dave


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] iptables example on Gentoo

[Holly Bostick]

Dave Nebinger schreef:
>> I've been trying to build a simple firewall with a DMZ for a web 
>> server.
> 
> 
> Dude, trying to use iptables directly was your first mistake.
> 
> Take a spin out and look at shorewall (I'm sure others have different
>  recommendations).
> 
> Shorewall will get you up and running in no time and will easily 
> handle the configuration stuff from your original post.
> 
> Trying to manage such a complex config using iptables directly is 
> doomed to failure; any mistake in ordering of rules, etc., will break
>  your connectivity.  Sticking with a tool like shorewall will
> simplify rules maintenance and pose less of a problem when performing
> updates later on.
> 

If you're trying to learn, James, there is something to be said for
Dave's position; it's not as if the config files are going to disappear
just because you used shorewall to write them with correct settings.

It might be easier to understand how iptables works if you configure it
through a system that will do it properly, *then* look at the configured
rules and work out why they work (as opposed to what your self-made
rules do), rather than wait to have a working configuration until you've
understood iptables (which is apparently not really easy for most
everybody).

Holly
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Holly Bostick <motub <at> planet.nl> writes:


> If you're trying to learn, James, there is something to be said for
> Dave's position; it's not as if the config files are going to disappear
> just because you used shorewall to write them with correct settings.

Following this example, I've had no problems, only it did not
include the DMZ portion of the example. I looked at Shorewall. No thanks.

> It might be easier to understand how iptables works if you configure it
> through a system that will do it properly, *then* look at the configured
> rules and work out why they work (as opposed to what your self-made
> rules do), rather than wait to have a working configuration until you've
> understood iptables (which is apparently not really easy for most
> everybody).

Hey, it took me quite a long time to digest OpenBSD +pf and other tools.
That's OK, even fantastic. It's what I want to do. Struggle, learn,
make little mods and test the results.....

If I need immediate coverage, I have a OpenBSD +pf box that is fantastic,
because I took the time to learn. If shorewall is so easy, then just email
to me the config files for a 3 nic network, with DMZ based web server,
and only internally (LAN) initiated connections allowed, in the form
of config files, OK?  

I'm quite sure I'll master iptables/netfilter, the commnand line and
config file way.........the old fashion, hard-headed way.

YMMY

James



-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

> If shorewall is so easy, then just email
> to me the config files for a 3 nic network, with DMZ based web server,
> and only internally (LAN) initiated connections allowed, in the form
> of config files, OK?

Sure, there's 5 files you'd need to set up and, as per your request, it is
limited to web service on DMZ box and outbound connections only.  Took me
all of 5 minutes to sketch this out and yes, it would work as-is.

Hand-coding the iptables rules, while instructional, is really painful when
you're trying to work with a production server.  When you get down to it,
iptables is not super difficult to learn, but the syntax and nuances can be
a pain to try to get straight.

It is for that reason that I tend to push folks away from direct iptables
coding when the messages come up on the list; it is typically much simpler
to say 'set up shorewall like this' than it is to get them to understand
about defining the connection tracking rules before the general rules,
manage the default policies, include the bits and pieces of iptables that
can filter out bogus tcp/udp packets, etc. etc.  I certainly wasn't trying
to rain on your educational parade.

/etc/shorewall/interfaces:
# Assumes you're getting IP address from dhcp server
net eth0 detect dhcp,routefilter,norfc1918,tcpflags
# Assumes you're serving dhcp to internal systems
loc eth1 detect dhcp,tcpflags
# Assumes DMZ has fixed IP addresses
dmz eth2 detect tcpflags

/etc/shorewall/masq:
# All outgoing traffic should be masqueraded as coming from the primary card
eth0 eth1
eth0 eth2

/etc/shorewall/policy:
# Allow any outbound traffic from local network
loc net ACCEPT
# Allow any outbound traffic initiated from the DMZ
dmz net ACCEPT
# Allow traffic between DMZ and local zone
dmz loc ACCEPT
loc dmz ACCEPT
# Drop any incoming packets
net all DROP
# throw away the rest
all all REJECT

/etc/shorewall/zones:
net Net Internet
loc Local Local Networks
dmz DMZ Demilitarized Zone

/etc/shorewall/rules:
# Allow ports 80, 443 to go to the DMZ via dnat
# Assumes web server is at ip address below
DNAT net dmz:192.168.1.10 tcp 80,443



-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Dave Nebinger <dnebinger <at> joat.com> writes:

> 
> > If shorewall is so easy, then just email
> > to me the config files for a 3 nic network, with DMZ based web server,
> > and only internally (LAN) initiated connections allowed, in the form
> > of config files, OK?
> 
> Sure, there's 5 files you'd need to set up and, as per your request, it is
> limited to web service on DMZ box and outbound connections only.  Took me
> all of 5 minutes to sketch this out and yes, it would work as-is.
> 

The cable modem is a single static IP. Internally I route everything
statically from the lan to to firewall, via a gateway(no dhcp). likewise
on the dmz web sever.

> Hand-coding the iptables rules, while instructional, is really painful when
> you're trying to work with a production server.  When you get down to it,
> iptables is not super difficult to learn, but the syntax and nuances can be
> a pain to try to get straight.

OK, I agree.
 
> It is for that reason that I tend to push folks away from direct iptables
> coding when the messages come up on the list; it is typically much simpler
> to say 'set up shorewall like this' than it is to get them to understand
> about defining the connection tracking rules before the general rules,
> manage the default policies, include the bits and pieces of iptables that
> can filter out bogus tcp/udp packets, etc. etc.  I certainly wasn't trying
> to rain on your educational parade.

It's not a parade, it's what old-timers do, it's how I learn.

> /etc/shorewall/interfaces:
> # Assumes you're getting IP address from dhcp server
> net eth0 detect dhcp,routefilter,norfc1918,tcpflags
> # Assumes you're serving dhcp to internal systems
> loc eth1 detect dhcp,tcpflags
how about for a static
loc eht1 detect tcpflags   <????????>

> # Assumes DMZ has fixed IP addresses
> dmz eth2 detect tcpflags
>
> /etc/shorewall/masq:
> # All outgoing traffic should be masqueraded as coming from the primary card
> eth0 eth1
> eth0 eth2

> /etc/shorewall/policy:
> # Allow any outbound traffic from local network
> loc net ACCEPT
> # Allow any outbound traffic initiated from the DMZ
> dmz net ACCEPT
> # Allow traffic between DMZ and local zone
> dmz loc ACCEPT
> loc dmz ACCEPT
> # Drop any incoming packets
> net all DROP
> # throw away the rest
> all all REJECT

> /etc/shorewall/zones:
> net Net Internet
> loc Local Local Networks
> dmz DMZ Demilitarized Zone

> /etc/shorewall/rules:
> # Allow ports 80, 443 to go to the DMZ via dnat
> # Assumes web server is at ip address below
> DNAT net dmz:192.168.1.10 tcp 80,443


Dave,

Thanks for your help. I think I've got enough here to get
it basically working. One I make the rulesets more complex,
I'll use shorewall generated rules and configs to see what I
have missed.

Thanks for your patience,

James


-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

> It's not a parade, it's what old-timers do, it's how I learn.

I started that way too (being an old-timer myself ;-)

However after consuming info available on the net and buying/reading an
iptables book, I quickly came to realize that it's quite easy to shoot
yourself in the foot with iptables.

Shorewall, and many of the other alternatives, end up handling the nuances
of iptables quite nicely and take most of the bullets out of your gun, thus
protecting your feet.

> > /etc/shorewall/interfaces:
> > # Assumes you're getting IP address from dhcp server
> > net eth0 detect dhcp,routefilter,norfc1918,tcpflags
> > # Assumes you're serving dhcp to internal systems
> > loc eth1 detect dhcp,tcpflags
> how about for a static
> loc eht1 detect tcpflags   <????????>

Yes, /etc/shorewall/interfaces file has excessive documentation that
explains what would go on the end.
 
> 
> Thanks for your help. I think I've got enough here to get
> it basically working. One I make the rulesets more complex,
> I'll use shorewall generated rules and configs to see what I
> have missed.

You may be in a little trouble if you're talking about mixing shorewall &
iptables...  They really don't play well together.

Shorewall (and many of the others) create custom chains to contain
individual rules of varying types.  The problem is that these custom chains
tend to get intertwined with each other and trying to identify a
shorewall-based iptable rule that you want to copy to a straight iptable
implementation can be difficult.

That plus if you start shorewall it basically clears all existing chains to
load it's own info, so all firewall rules must be kept in the shorewall
files.

So you really have to pick one or the other but not both.

Dave


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[gentuxx]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Nebinger wrote:

>>If shorewall is so easy, then just email
>>to me the config files for a 3 nic network, with DMZ based web server,
>>and only internally (LAN) initiated connections allowed, in the form
>>of config files, OK?
>
>
>Sure, there's 5 files you'd need to set up and, as per your request, it is
>limited to web service on DMZ box and outbound connections only. Took me
>all of 5 minutes to sketch this out and yes, it would work as-is.
>
>Hand-coding the iptables rules, while instructional, is really painful when
>you're trying to work with a production server. When you get down to it,
>iptables is not super difficult to learn, but the syntax and nuances can be
>a pain to try to get straight.
>
>It is for that reason that I tend to push folks away from direct iptables
>coding when the messages come up on the list; it is typically much simpler
>to say 'set up shorewall like this' than it is to get them to understand
>about defining the connection tracking rules before the general rules,
>manage the default policies, include the bits and pieces of iptables that
>can filter out bogus tcp/udp packets, etc. etc. I certainly wasn't trying
>to rain on your educational parade.
>
>/etc/shorewall/interfaces:
># Assumes you're getting IP address from dhcp server
>net eth0 detect dhcp,routefilter,norfc1918,tcpflags
># Assumes you're serving dhcp to internal systems
>loc eth1 detect dhcp,tcpflags
># Assumes DMZ has fixed IP addresses
>dmz eth2 detect tcpflags
>
>/etc/shorewall/masq:
># All outgoing traffic should be masqueraded as coming from the primary card
>eth0 eth1
>eth0 eth2
>
>/etc/shorewall/policy:
># Allow any outbound traffic from local network
>loc net ACCEPT
># Allow any outbound traffic initiated from the DMZ
>dmz net ACCEPT
># Allow traffic between DMZ and local zone
>dmz loc ACCEPT
>loc dmz ACCEPT
># Drop any incoming packets
>net all DROP
># throw away the rest
>all all REJECT
>
>/etc/shorewall/zones:
>net Net Internet
>loc Local Local Networks
>dmz DMZ Demilitarized Zone
>
>/etc/shorewall/rules:
># Allow ports 80, 443 to go to the DMZ via dnat
># Assumes web server is at ip address below
>DNAT net dmz:192.168.1.10 tcp 80,443
>
>
>
I think it might be important to point out here how Shorewall
handles/uses these files.  I don't use Shorewall, so I can't really
shed light on it.  But these config files are really only one side of
the mirror.

Just my 2¢.

- --
gentux
echo "hfouvyAdpy/ofu" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 34CE 2E97 40C7 EF6E EC40  9795 2D81 924A
6996 0993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHi4qLYGSSmmWCZMRAqTAAKDPZKtENYbobogeq5HWpjMJf9NT3gCfen9m
elbeSFll/aKFpRZhJj4GgFE=
=wSn/
-----END PGP SIGNATURE-----

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[W.Kenworthy]

Also check out monmotha for a good script that should handle this.

However, as others have pointed out, home brew firewall scripts,
especially with someone who admits they are lost is a recipe for
disaster.  Pick something like shorewall or monmotha and modify -
carefully.  There is a very good reason they are so complex!

BillK


On Tue, 2005-09-06 at 17:02 -0700, gentuxx wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dave Nebinger wrote:
> 
> >>If shorewall is so easy, then just email
> >>to me the config files for a 3 nic network, with DMZ based web server,
> >>

...
-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

> I think it might be important to point out here how Shorewall
> handles/uses these files.  I don't use Shorewall, so I can't really
> shed light on it.  But these config files are really only one side of
> the mirror.

Actually these files are typically the only ones you'll need to edit...

/etc/shorewall/interfaces defines the interfaces that will be available to
shorewall and provides some logical names for rules mapping.

/etc/shorewall/masq defines the masquerades to use and provides a quick and
easy way to say things like "eth1 traffic going out on eth0 should be
masqueraded".

/etc/shorewall/policy defines the default policies on the interfaces.

/etc/shorewall/zones defines human-readable names for the interfaces,
although I haven't really seen them used for much they are critical to the
functionality (you'll get weird startup failure messages if they're
missing).

/etc/shorewall/rules is the critical file, and it defines the rules for what
traffic will be allowed.  My rules file, for example, indicates that
incoming mail and other services are either allowed for the router box to
handle or forwarded into the DMZ.  It also defines what traffic to block
(i.e. outbound windblows networking ports), what hosts to block (ip
addresses that hit the ssh daemon), etc.

Other files that you might edit are /etc/shorewall/blacklist, an optional
blacklist file to block all traffic from these hosts, and
/etc/shorewall/shorewall.conf, the general shorewall configuration file.

Many other files exist in the directory but I'm willing to bet that 95% of
the time you won't need to modify them.



-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Dave Nebinger <dnebinger <at> joat.com> writes:


> > I think it might be important to point out here how Shorewall
> > handles/uses these files.  I don't use Shorewall, so I can't really
> > shed light on it.  But these config files are really only one side of
> > the mirror.

Sorry, I HAVE ZERO INTEREST IN A GUI, UNLESS THE RESULTING RULESETS
ARE SIMILAR TO THOSE BUILT MANUALLY with a one-to-one correspondance
to iptables/netfilter.

> Actually these files are typically the only ones you'll need to edit...


I have a very robust OpenBSD based firewall. 

I'm not looking for advice on building firewalls as a newbie.
I'm looking for somebody that knows IPTABLES/NETFILTER, preferable
on Gentoo, and is willing to share a little information. I'm in the
process of building a gentoo based firewall to compare the robustness
against OpenBSD + pf. The really funny thing is a year ago, this
list was full of persons that debunked OpenBSD's security supremacy.
Now all I'm getting is a lot of 'hot air' and 'bull-loney'. Why are 
so many people scared to manage there own firewall rulesets directly?


Personally,
when the occasional hacker does manage to penetrate a managerie
of obsticles, I like to watch what they do, and learn. Besides the
end result is there is nothing in my networks that if destroyed,
cannot be rebuilt. Anything of treasure value is protected by
a 4 foot air_gap. I guess I see talented penetration specialists
more as kindred spirits, as opposed to evil interlopers. This FEAR
of managing your own iptables/netfilters rulesets is not healthly.
Who the F*** wants to live life afraid? Conquer your demons
face to face, unless there really is truth to what the OpenBSD community
says about linux, 'linux based security is bullshit'.

Prove me wrong; don't hijack the thread!

OpenBSD + PF is a piece of cake. OpenBSD comes secure right 
out of the box. If the gentoo experts that peruse this list 
read this email, surely they can direct one to examples where 
the details of secure rulesets exist? 
Surely someone is  confident enough in their 
iptables/netfilter rulesets to publish them?

Maybe the linux security models are not up to the task?
SElinux etc....?
PF rulessets are quite elaborate, but easily discernable.

You know, 'the rat' culture is questionable, but, he's really quite
talented and reasonable, once you get past the phasic behavior.

OpenBSD comes secure, right out off the installation. Builing a really
secure firewall is trivial. I thought (gentoo)linux was suppose to
be equal to or superior to OpenBSD for security and every other
aspect of computing?

If you have ruleset capabilities, then look at this example,
and tell me what's deficient with it? 
http://www.linuxguruz.com/iptables/scripts/rc.DMZ.firewall.txt

It was created for
2.4 based kernels, but this simple website shows one
how to prepare a 2.6 kernel as the basis of the firewall:
http://www.gentoo.org/doc/en/home-router-howto.xml
It is a bit shallow, but at least this author is
not scared of iptables/netfilter fundamentals.

(Booo) <this is where the Gentooers mess their britches?>


The really sad thing in this whole thread, is nobody
has even mentiond which (kernel) sources to use, what
to disable/enable and why. Is this some sort of deep secret
or is the gentoo community un_caring about those who
simply want to learn about iptables/netfilter in a 2.6
kernel environment? Hell, if this list and the greater
gentoo community do not have this aggregated knowledge
then let's develop it and document it and share it. 
This is how we, as the open_source community distinguish 
ourselves from the Vulture and his menion_buzzards that inhabit
Redmond!

sincerely, from a dreamer and a looser, and an simpleton,

(but, I'm not afraid of any stinking rule_set, are you?)

James

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Holly Bostick]

James schreef:
<snip>
> 
> (Booo) <this is where the Gentooers mess their britches?>
> 
> 
> The really sad thing in this whole thread, is nobody
> has even mentiond which (kernel) sources to use, what
> to disable/enable and why. Is this some sort of deep secret
> or is the gentoo community un_caring about those who
> simply want to learn about iptables/netfilter in a 2.6
> kernel environment? Hell, if this list and the greater
> gentoo community do not have this aggregated knowledge

Good morning, this is the general users list. If you want the security
experts, try

gentoo-security  	For the discussion of security issues and fixes
gentoo-hardened 	For a security hardened version of Gentoo

If you want to discuss comparisons between Gentoo and BSD, this might be
the place:

gentoo-bsd 	Discussion about Gentoo/BSD

That's all I'm going to say in the face of all this needlessly insulting
behaviour.

Holly
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Holly Bostick <motub <at> planet.nl> writes:

> Good morning, this is the general users list. If you want the security
> experts, try

> gentoo-security  	For the discussion of security issues and fixes
> gentoo-hardened 	For a security hardened version of Gentoo

You mean I have to go to this group to find detailed documentation
in iptables/netfilter rulesets that are indeed secure, published,
and used in more than one place?

> If you want to discuss comparisons between Gentoo and BSD, this might be
> the place:

agreeded

> That's all I'm going to say in the face of all this needlessly insulting
> behaviour.

Holly, I have not nor do not intend to insult or constipate anyone. 
Sincere apologies. However, I find this very strange that published
rulesets do not exist for iptables/netfilter, for simple and common
things lick a home-office router with (3) nics, including LAN, WAN
and DMZ with optional web and dns(internal) servers. If you find my
sharing these thoughts with you, and the 50 times I've had to write
that I'm interested in iptables/netfilters and not shorewall, then
I think you are a bit too sensitive about divergent opinions.

sincerely,
James



-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

> > That's all I'm going to say in the face of all this needlessly insulting
> > behaviour.
> 
> Holly, I have not nor do not intend to insult or constipate anyone.
> Sincere apologies. However, I find this very strange that published
> rulesets do not exist for iptables/netfilter, for simple and common
> things lick a home-office router with (3) nics, including LAN, WAN
> and DMZ with optional web and dns(internal) servers. If you find my
> sharing these thoughts with you, and the 50 times I've had to write
> that I'm interested in iptables/netfilters and not shorewall, then
> I think you are a bit too sensitive about divergent opinions.

Up to now I haven't really wanted to have someone bounced from the list; but
your lack of sensitivity and generally insulting manners make you the first
obvious candidate for such a bouncing.

> > Good morning, this is the general users list. If you want the security
> > experts, try
> 
> > gentoo-security  	For the discussion of security issues and fixes
> > gentoo-hardened 	For a security hardened version of Gentoo
> 
> You mean I have to go to this group to find detailed documentation
> in iptables/netfilter rulesets that are indeed secure, published,
> and used in more than one place?

Why do you think that iptables/netfilter is exclusive to gentoo?  It is a
general linux question; iptables is not a product of gentoo.

There are no such published, shared rule sets because each site has it's own
security requirements and places different priorities upon the rules.  Some
will prioritize the connection tracking rules above the service rules (to
optimize outbound active connections over new service connections) whilst
others will prioritize them in the opposite direction.  And the services
themselves can be prioritized differently.

If you really want the down and dirty on iptables, go out and buy "Linux
Firewalls" by Ziegler and Constantine.  It describes every nook and cranny
of iptables.

In the mean time, welcome to my kill file.



-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Dave Nebinger <dnebinger <at> joat.com> writes:


> Up to now I haven't really wanted to have someone bounced from the list; but
> your lack of sensitivity and generally insulting manners make you the first
> obvious candidate for such a bouncing.

Ok your call, let me know.....


> Why do you think that iptables/netfilter is exclusive to gentoo?  It is a
> general linux question; iptables is not a product of gentoo.

Agreed. I never stated it was, just asked on this list for information and
help, repeatedly about iptables/netfilters. I have clearly, and repeated
articulated the fact, that shorewall, and other applications, are not
useful to me, unless they redender ruleset that can be manipulated
manually. So a tool, that I can mix and match with command line access
to iptables/netfilter would be acceptable. However, there seems to be
some confusion about whether shorewall et. al. actually can work
in this capacity. The last thing I want is another layer. A tool/scripts/gui
that is 100% compatible with command line manipulations and testing of
rulesets is OK. Any guidance you can provide here is appreciated.

> There are no such published, shared rule sets because each site has it's own
> security requirements and places different priorities upon the rules.  Some
> will prioritize the connection tracking rules above the service rules (to
> optimize outbound active connections over new service connections) whilst
> others will prioritize them in the opposite direction.  And the services
> themselves can be prioritized differently.
> 
OK, but published examples would be nice, even if they require changes.

> If you really want the down and dirty on iptables, go out and buy "Linux
> Firewalls" by Ziegler and Constantine.  It describes every nook and cranny
> of iptables.

Great reference. The third addition was just published in September 05.
I've pre-ordered one....

> In the mean time, welcome to my kill file.

OK, whatever this means....

Sorry to offend, but, I did not like having Shorewall or anything
else shove down my throat. The title of the email was
and is 'iptables example on Gentoo'. It a shame we had to get so
heated before folks actually started talking about iptables/netfilter,
and not some intermediary....

James




-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[kashani]

James wrote:
  > OK, whatever this means....
> 
> Sorry to offend, but, I did not like having Shorewall or anything
> else shove down my throat. The title of the email was
> and is 'iptables example on Gentoo'. It a shame we had to get so
> heated before folks actually started talking about iptables/netfilter,
> and not some intermediary....

	I think it's fairly rational for people to answer "I use Shorewall to 
create my iptables rules" in response to your original question. While 
not the answer you might have been looking for it does answer the 
question. And frankly I can do without the bad ol' days of writing my 
own ipchains rules... what a mess that was. I suspect most people who 
answered you feel the same way and would rather spend their time doing 
other things. In my case I have a set of firewalls I never touch and 
forty odd web servers. I believe my time is better spent letting a well 
respected program setup my firewall rather than mucking about myself. 
Much like I let Gentoo build packages for me rather than do my own 
source installs.

	To bring things full circle I *actually* had a chat with my motorcycle 
mechanic last week about carbs. I buy parts from him a little above 
market plus a six pack and he tells me how to install it or what to 
watch out for thus saving me $75/hour. This week I mentioned some overly 
complicated work I was planning that he suggested might not be in my 
engine's best interest. A point he punctuated after lecturing me 15 
minutes for even mentioning the hard method by throwing 20lbs of broken 
carbs across the garage in my general direction. I think you got off 
easy in comparison. :-)

The moral of the stories is two part:
Sometimes the easy way is actually the best way;
You can do it the hard way, but don't expect people to help.

	However feel free to get your hands dirty in iptables you may enjoy it 
and find it useful especially if you're a full time security guy. I've 
been there and have neither the interest nor time to do something by 
hand with decent tools availible.

kashani, who found Fortran 77 a vast relief after Assembler for the IBM 
Mini Computer.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Holly Bostick]

James schreef:
> Holly Bostick <motub <at> planet.nl> writes:
> 
> 
>> Good morning, this is the general users list. If you want the 
>> security experts, try
> 
> 
>> gentoo-security  	For the discussion of security issues and fixes 
>> gentoo-hardened 	For a security hardened version of Gentoo
> 
> 
> You mean I have to go to this group to find detailed documentation in
>  iptables/netfilter rulesets that are indeed secure, published, and 
> used in more than one place?

I mean that if such documentation exists, that group would be much more
likely to know where it is (because that group is focused on such issues
and knowledge) than this group would be (where such knowledge is more
likely to be a random roll of the dice as to whether anyone around today
happens to know about it).

Now, of course for detailed documentation on iptables/netfilter, the
place to start, for me, at least, would be

http://www.iptables.org/documentation/index.html#documentation-howto .

As for 'published rulesets', well, so far I've found

http://linux.unimelb.edu.au/server/course/fc3/iptables.html (see examples)

http://www.hackinglinuxexposed.com/articles/20021008.html

http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.firewall-iptables

http://www.linux.org/docs/ldp/howto/IP-Masquerade-HOWTO/ (see
http://www.linux.org/docs/ldp/howto/IP-Masquerade-HOWTO/stronger-firewall-examples.html#RC.FIREWALL-IPTABLES-STRONGER)

http://www.linuxtopia.org/Linux_Firewall_iptables/index.html (see
example scripts beginning at
http://www.linuxtopia.org/Linux_Firewall_iptables/x5753.html)

http://forums.gentoo.org/viewtopic-p-1436652-highlight-iptables+rulesets.html?sid=b777f7a8f3ef392e9cb4d14f0bcccfa1#1436652

That's all the Googling I feel like right now, but I'm sure that
gentoo-security might know more places such things are likely to be
found (especially any gentoo-specific resources).
> 
<snip>
> 
>> That's all I'm going to say in the face of all this needlessly 
>> insulting behaviour.
> 
> 
> Holly, I have not nor do not intend to insult or constipate anyone. 
> Sincere apologies. However, I find this very strange that published 
> rulesets do not exist for iptables/netfilter, for simple and common 
> things lick a home-office router with (3) nics, including LAN, WAN 
> and DMZ with optional web and dns(internal) servers. If you find my 
> sharing these thoughts with you, and the 50 times I've had to write 
> that I'm interested in iptables/netfilters and not shorewall, then I 
> think you are a bit too sensitive about divergent opinions.


>> The really funny thing is a year ago, this list was full of persons
>>  that debunked OpenBSD's security supremacy. Now all I'm getting is
>>  a lot of 'hot air' and 'bull-loney'. Why are so many people scared
>>  to manage there own firewall rulesets directly?

This is not a 'divergent opinion'.. it is an opinion, true, but there is
nothing for it to diverge from (since this is not a debate about
OpenBSD's supremacy or lack thereof, nor about whether anyone is
'scared' to manage their own rulesets directly).

>> I thought (gentoo)linux was suppose to be equal to or superior to 
>> OpenBSD for security and every other aspect of computing?

This is not a 'divergent opinion', because this is again not a debate
over, nor is this a forum for debate concerning, whether Gentoo is
superior to anything at all, this is a user help mailing list.

>> (Booo) <this is where the Gentooers mess their britches?>

Excuse me? This is somehow not a taunt?

Whatever.

Though what I wonder is, is iptables under BSD so radically different
than iptables under Linux that somehow you can't simply use or adapt the
oh-so-easy BSD rulesets that you already have to your current conditions?

Or, I would wonder, if I didn't have concerns that I value higher taking
priority over my thinking about this at all.

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[gentuxx]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James wrote:

>Dave Nebinger <dnebinger <at> joat.com> writes:
>
>
>>>I think it might be important to point out here how Shorewall
>>>handles/uses these files. I don't use Shorewall, so I can't really
>>>shed light on it. But these config files are really only one side of
>>>the mirror.
>
>
>Sorry, I HAVE ZERO INTEREST IN A GUI, UNLESS THE RESULTING RULESETS
>ARE SIMILAR TO THOSE BUILT MANUALLY with a one-to-one correspondance
>to iptables/netfilter.


I think, perhaps, you misunderstood what I was saying.  My
understanding of shorewall was that it was a script (or series of
scripts) that look for the previously specified config files and do
"cool stuff" with the information contained in them.  I was simply
stating that in order to put value to the information in the config
files, that you would have to know what the scripts do.  I was not, in
any way, suggesting that you use Shorewall.  I can completely
understand and sympathize with your need to dissect iptables, and the
security it provides.  However, I tend to take a top-down approach, as
opposed to the bottom-up approach you seem to prefer.

>
>>Actually these files are typically the only ones you'll need to edit...
>
>
>
>I have a very robust OpenBSD based firewall.
>
>I'm not looking for advice on building firewalls as a newbie.
>I'm looking for somebody that knows IPTABLES/NETFILTER, preferable
>on Gentoo, and is willing to share a little information. I'm in the
>process of building a gentoo based firewall to compare the robustness
>against OpenBSD + pf.

< ... snipping "BSD is better" rant ... >

>
>sincerely, from a dreamer and a looser, and an simpleton,
>
>(but, I'm not afraid of any stinking rule_set, are you?)
>
>James
>
Going back to your original questions, I'm not really sure I can help
with Q1.  However, in regards to Q2, there aren't any config files for
iptables.  The tables are stored in memory.  You can do an
"iptables-save", which will output a modified version of the rules
currently in place, which can subsequently be modified (assuming you
understand and duplicate the syntax) and restored (with any changes)
using "iptables-restore".  Otherwise, all of your editing should be
done at the command line.  I would recommend using a script (of your
own design, if so desired) to ease repeatability, and reduce the
possibility for mistakes (fat-fingering).  Also, a script of this
nature would be handy for starting the iptables upon boot (I believe
the HOW-TO you referenced covers this).

HTH.

- --
gentux
echo "hfouvyAdpy/ofu" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 34CE 2E97 40C7 EF6E EC40  9795 2D81 924A
6996 0993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHzQ7LYGSSmmWCZMRAgx1AKCT+7L3dXEppBtzjsZ8K/PLKYB4BQCff/AJ
IWqjSAL5vD46NiY0sfquCe4=
=hejB
-----END PGP SIGNATURE-----

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

gentuxx <gentuxx <at> gmail.com> writes:



> I think, perhaps, you misunderstood what I was saying.  My
> understanding of shorewall was that it was a script (or series of
> scripts) that look for the previously specified config files and do
> "cool stuff" with the information contained in them.  I was simply
> stating that in order to put value to the information in the config
> files, that you would have to know what the scripts do.  I was not, in
> any way, suggesting that you use Shorewall.  I can completely
> understand and sympathize with your need to dissect iptables, and the
> security it provides.  However, I tend to take a top-down approach, as
> opposed to the bottom-up approach you seem to prefer.

OK this is great!. However, I'm a C/assembler hack, with embedded
tendencies. Scripts are OK, as most are self explanatory. 
As a hardware guy, I often start with a microP, and write/add
firmware to a custom bootloader. From there, often, as simple
state_machine with selected code creates wonderful things;
so I'm definately a bottoms up kind of guy. YMMV.


> Going back to your original questions, I'm not really sure I can help
> with Q1.  However, in regards to Q2, there aren't any config files for
> iptables.  The tables are stored in memory.  You can do an
> "iptables-save", which will output a modified version of the rules
> currently in place, which can subsequently be modified (assuming you
> understand and duplicate the syntax) and restored (with any changes)
> using "iptables-restore".  Otherwise, all of your editing should be
> done at the command line.  I would recommend using a script (of your
> own design, if so desired) to ease repeatability, and reduce the
> possibility for mistakes (fat-fingering).  Also, a script of this
> nature would be handy for starting the iptables upon boot (I believe
> the HOW-TO you referenced covers this).

Is this the one? 
http://www.linuxguruz.com/iptables/scripts/rc.DMZ.firewall.txt
I've reference many urls. This one was written for 2.4 
based kernels and I'm not sure it's useful for 2.6. That was one
of my questions.... Can you look at it and suggest where it is
defective?  That way, I can use it as a baseline to learn and develop
a more robust (in_memory) ruleset that spawns from a shell script
or elsewhere. Or maybe share a 2.6 based script?

OK all of this is fantastic! All of the googling and reading 
I've done has not revealed this. Most of what I find is circa 2.4 
and I'm not adept enough to discern what's relevant for 2.4 and 2.6 
kernels, yet.

Thank you very, very much,
James




-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[gentuxx]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James wrote:

>gentuxx <gentuxx <at> gmail.com> writes:
>
>
>
>>I think, perhaps, you misunderstood what I was saying. My
>>understanding of shorewall was that it was a script (or series of
>>scripts) that look for the previously specified config files and do
>>"cool stuff" with the information contained in them. I was simply
>>stating that in order to put value to the information in the config
>>files, that you would have to know what the scripts do. I was not, in
>>any way, suggesting that you use Shorewall. I can completely
>>understand and sympathize with your need to dissect iptables, and the
>>security it provides. However, I tend to take a top-down approach, as
>>opposed to the bottom-up approach you seem to prefer.
>
>
>OK this is great!. However, I'm a C/assembler hack, with embedded
>tendencies. Scripts are OK, as most are self explanatory.
>As a hardware guy, I often start with a microP, and write/add
>firmware to a custom bootloader. From there, often, as simple
>state_machine with selected code creates wonderful things;
>so I'm definately a bottoms up kind of guy. YMMV.
>
>
>>Going back to your original questions, I'm not really sure I can help
>>with Q1. However, in regards to Q2, there aren't any config files for
>>iptables. The tables are stored in memory. You can do an
>>"iptables-save", which will output a modified version of the rules
>>currently in place, which can subsequently be modified (assuming you
>>understand and duplicate the syntax) and restored (with any changes)
>>using "iptables-restore". Otherwise, all of your editing should be
>>done at the command line. I would recommend using a script (of your
>>own design, if so desired) to ease repeatability, and reduce the
>>possibility for mistakes (fat-fingering). Also, a script of this
>>nature would be handy for starting the iptables upon boot (I believe
>>the HOW-TO you referenced covers this).
>
>
>Is this the one?
>http://www.linuxguruz.com/iptables/scripts/rc.DMZ.firewall.txt

No, this one.

http://www.gentoo.org/doc/en/home-router-howto.xml


>I've reference many urls. This one was written for 2.4
>based kernels and I'm not sure it's useful for 2.6. That was one
>of my questions.... Can you look at it and suggest where it is
>defective? That way, I can use it as a baseline to learn and develop
>a more robust (in_memory) ruleset that spawns from a shell script
>or elsewhere. Or maybe share a 2.6 based script?
>
>OK all of this is fantastic! All of the googling and reading
>I've done has not revealed this. Most of what I find is circa 2.4
>and I'm not adept enough to discern what's relevant for 2.4 and 2.6
>kernels, yet.
>
>Thank you very, very much,
>James

As far as functionality and rule set development, I don't think there
is that much of a difference between 2.4 and 2.6.  I'm sure there are
tons of cool things that go on under the hood that I don't really know
about, but the implementation is basically the same.  2.6 kernels may
offer newer targets, different kernel hooks, etc., etc., but like I
said, that's a little beyond my current scope.  Why not compile a 2.4
kernel (with netfilter), build a ruleset, then load up your 2.6 kernel
and see what breaks (if anything)?

- --
gentux
echo "hfouvyAdpy/ofu" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 34CE 2E97 40C7 EF6E EC40  9795 2D81 924A
6996 0993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDH0X1LYGSSmmWCZMRAlBDAJ9xan8nam9i93nWTKL8CkcFJsb1YgCdE2V4
Pw+Zo2IuXCqMabsrEEryjFQ=
=qppu
-----END PGP SIGNATURE-----

-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

> As far as functionality and rule set development, I don't think there
> is that much of a difference between 2.4 and 2.6.  I'm sure there are
> tons of cool things that go on under the hood that I don't really know
> about, but the implementation is basically the same.  2.6 kernels may
> offer newer targets, different kernel hooks, etc., etc., but like I
> said, that's a little beyond my current scope.  Why not compile a 2.4
> kernel (with netfilter), build a ruleset, then load up your 2.6 kernel
> and see what breaks (if anything)?

There are new targets and matches in the 2.6 kernel.  Also it is my
understanding that the internal tables are managed differently, in that the
2.6 implementation is faster in the table processing.
 

-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

> > > I think it might be important to point out here how Shorewall
> > > handles/uses these files.  I don't use Shorewall, so I can't really
> > > shed light on it.  But these config files are really only one side of
> > > the mirror.
> 
> Sorry, I HAVE ZERO INTEREST IN A GUI, UNLESS THE RESULTING RULESETS
> ARE SIMILAR TO THOSE BUILT MANUALLY with a one-to-one correspondance
> to iptables/netfilter.

FWIW, shorewall does not have a gui.  It reads the script files and builds
appropriate iptables rules and applies them.
 
> I'm not looking for advice on building firewalls as a newbie.
> I'm looking for somebody that knows IPTABLES/NETFILTER, preferable
> on Gentoo, and is willing to share a little information. I'm in the
> process of building a gentoo based firewall to compare the robustness
> against OpenBSD + pf. The really funny thing is a year ago, this
> list was full of persons that debunked OpenBSD's security supremacy.
> Now all I'm getting is a lot of 'hot air' and 'bull-loney'. Why are
> so many people scared to manage there own firewall rulesets directly?

I know iptables/netfilter.  I've worked through all of the online
documentation, I've read iptables books, I've implemented firewalls using
just iptables.

Knowing all of that information, I still suggest using a tool to help manage
iptables.

The reason is this: iptables, like PF on openbsd, allows for fine-grained
control over every aspect of the network traffic going in and out of the
box.

Most folks, however, have little need for such fine-grained control over
their firewall.  They want a simple set of rules that allow outgoing traffic
and certain incoming traffic.  They don't care about masquerading vs
DNAT/SNAT, what to enable/disable on the ICMP packets, which ones to reject
vs deny, etc.  They don't need a detailed explanation of why the order of
the addition of rules to the table impact network performance as well as
whether a certain rule actually disables traffic that a later rule would
actually allow.

So why is it so necessary to get down and dirty with iptables when there are
supporting tools that manage all of these details quite well.
 
> Personally,
> when the occasional hacker does manage to penetrate a managerie
> of obsticles, I like to watch what they do, and learn. Besides the
> end result is there is nothing in my networks that if destroyed,
> cannot be rebuilt. Anything of treasure value is protected by
> a 4 foot air_gap. I guess I see talented penetration specialists
> more as kindred spirits, as opposed to evil interlopers. This FEAR
> of managing your own iptables/netfilters rulesets is not healthly.
> Who the F*** wants to live life afraid? Conquer your demons
> face to face, unless there really is truth to what the OpenBSD community
> says about linux, 'linux based security is bullshit'.

Oh, come on.  Using a tool to assist in rules maintenance hardly qualifies
as being afraid.  Using a tool to assist in rules maintenance means you have
better things to do with your time than operate at such a low level.

Per your idiom, we should throw out higher-level programming languages
because they take us all away from knowing microcode and assembler.

The tools exist because they are an aid, not a crutch.
 
> OpenBSD + PF is a piece of cake. OpenBSD comes secure right
> out of the box. If the gentoo experts that peruse this list
> read this email, surely they can direct one to examples where
> the details of secure rulesets exist?
> Surely someone is  confident enough in their
> iptables/netfilter rulesets to publish them?

Being a gentoo and/or linux expert does not qualify one as an iptables
expert.  Perhaps the same cannot be said about openbsd wrt pf, but that's
not for me to say.

If you think iptables should be so easy to pick up, then go pick it up and
make it work for you - no one is stopping you from that task.

> Maybe the linux security models are not up to the task?
> SElinux etc....?

They are up to the task, which is why linux is used a heck of a lot more
than openbsd...

> PF rulessets are quite elaborate, but easily discernable.

Iptables, as well, can be quite elaborate.  Discernable is another question
entirely.

If you know what you're doing, you can create a discernable set of rules
using custom chains and appropriate ordering.

Most often, though, what you'll see is the list of rules in some quasi order
which is supposed to satisfy security and accessibility requirements, but
hardly show up as being discernable.
 
> If you have ruleset capabilities, then look at this example,
> and tell me what's deficient with it?
> http://www.linuxguruz.com/iptables/scripts/rc.DMZ.firewall.txt

First of all the connection tracking rule is too far down in the INPUT
chain; it should come close to the top to shorten the amount of rules an
established connection would need to travel through before being accepted.

Secondly there's no filtering of traffic headed outbound.  Typically any
windblows & ipp traffic should be blocked at the router, as well as some
dhcp and dns traffic, as well as any specific service that you want to allow
to internal services but deny to external services.

> http://www.gentoo.org/doc/en/home-router-howto.xml
> It is a bit shallow, but at least this author is
> not scared of iptables/netfilter fundamentals.

You are correct in that it is shallow.  The author gives a 'perfect world'
iptables script without looking at the bad packet handling and ip address
spoofing at least partially addressed in the previous script.

The biggest shortcoming in this document is that, although the author goes
through great details on how to enable connection tracking support for
netfilter within the kernel, none of the iptables rules the author provides
support the use of connection tracking!

And I don't think that either script handles incoming FTP connections well
at all.

> (Booo) <this is where the Gentooers mess their britches?>

This has nothing to do with gentoo or any other linux distribution, it has
everything to do with iptables and their complexities and nuances.

> The really sad thing in this whole thread, is nobody
> has even mentiond which (kernel) sources to use, what
> to disable/enable and why. Is this some sort of deep secret
> or is the gentoo community un_caring about those who
> simply want to learn about iptables/netfilter in a 2.6
> kernel environment? Hell, if this list and the greater
> gentoo community do not have this aggregated knowledge
> then let's develop it and document it and share it.
> This is how we, as the open_source community distinguish
> ourselves from the Vulture and his menion_buzzards that inhabit
> Redmond!

First of all you didn't ask these questions, you asked for rules themselves.

Second of all the questions above are not specific to gentoo (why you would
think they are is beyond me), they apply generally to linux and therefore to
all distributions.

So, here goes:

1. The latest kernel is typically the best to use because it will contain
the latest security patches.  Stay away from 2.6.12.2 or 3 (I forget which
one it is) because they have a problem where they will report invalid packet
issues because of a patch that was applied to networking in general without
being applied to the specific tcp layers.  I've been using 2.6.13 and have
been very happy with it.

2. For enabling, I'd go to the gentoo doco you referred to earlier.  It
covers the basic kernel options that you'll want to include support for.

3. It is not a deep dark secret, it is just beyond the typical needs of the
gentoo/linux crowd.

4. The information is out there
(http://www.tldp.org/HOWTO/HOWTO-INDEX/admin.html#ADMSECURITY) you just need
to know where to look.

> sincerely, from a dreamer and a looser, and an simpleton,

I'd agree with the second and third adjectives.

> (but, I'm not afraid of any stinking rule_set, are you?)

Seriously James, it has nothing to do with being afraid of rulesets, it has
to do with how much folks need to know to get their systems secure, which
tends to be very simple rules for the average linux user.

Linux offers many, many, many more options than what I think that PF allows
for.  Each kernel option regarding the target and match support has a fellow
relationship in the iptables rules.  Many folks don't understand or need to
know for that matter how to set up MARK support or MAC address support, etc.

Finding the folks that know and understand and can apply all of these things
means you've wandered into the elite of linux security, not the general
linux community.

I don't know much about the BSDs, so I cannot judge what the average BSDer
knows about PF.  My guess is that they rely for the most part on the out of
the box security and have little need to dig any further.

The same kinds of things can be said about iptables; most folks can get away
with the default DENY policies whilst enabling outbound and existing
connection traffic.

That's why, when folks post questions regarding how to set up their
firewalls we all throw out tools for them to use to help set them up -
they're looking for a general setup that provides the protection they need
w/o interfering with the access they want to have.  The tools, as aids,
quickly allow them to do that.  And we don't have to deal with the follow up
questions like how to enable this service or redirect that service; using
the tool as an aid simplifies the process in general.



-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Dave Nebinger <dnebinger <at> joat.com> writes:



> I know iptables/netfilter.  I've worked through all of the online
> documentation, I've read iptables books, I've implemented firewalls using
> just iptables.

got any scripts/ files to share?

> Knowing all of that information, I still suggest using a tool to help manage
> iptables.

OK, after I learn raw iptables/netfilter.

> The reason is this: iptables, like PF on openbsd, allows for fine-grained
> control over every aspect of the network traffic going in and out of the
> box.


> Most folks, however, have little need for such fine-grained control over
> their firewall.  They want a simple set of rules that allow outgoing traffic
> and certain incoming traffic.  They don't care about masquerading vs
> DNAT/SNAT, what to enable/disable on the ICMP packets, which ones to reject
> vs deny, etc.  They don't need a detailed explanation of why the order of
> the addition of rules to the table impact network performance as well as
> whether a certain rule actually disables traffic that a later rule would
> actually allow.

> So why is it so necessary to get down and dirty with iptables when there are
> supporting tools that manage all of these details quite well.

Well, I hack embedded systems, often with only a 
state_machine/executive/min_rtos with a custom IP stack. Being
able to 'analyze code segments' and discern-learn, gives me a solid
specification/understanding to write custom assembler/c code
for micro's or DSPs.

Just one reason. I have many, many more. Finding templates
and scripts for robust IPtable/netfilter rules should not
be like pulling teeth....   I'm not trying to oversimply
or make demunitive comments about iptables/netfilter, I'm
just surprised that someone of your caliber, has not
served up iptables/netfilters in clear, discernable examples,
exclusively specific to iptables/netfilters.
Sure shorewall and other efforts are noble, for the majority
of users, but, surely there are more folks with my sort
of interests in iptables/netfilters.

> Oh, come on.  Using a tool to assist in rules maintenance hardly qualifies
> as being afraid.  Using a tool to assist in rules maintenance means you have
> better things to do with your time than operate at such a low level.

Um, in my opinion, the lowest level, is frequently referred to as
foundation, and that lack of foundation is why many programmers do 
not succeed. They do not have a foundational understanding of kernel, 
processes and files. Iptables/netfilters are as important as the scheduler,
if you are going to network anything with a 2.6 linux kernel.

> Per your idiom, we should throw out higher-level programming languages
> because they take us all away from knowing microcode and assembler.

Beautiful comments. I could not have said it better. Java is useful,
perl is OK, Bourne necessary, but the MASTERS of computer engineering 
do it in assembler.

Ever heard of the smartest or most accomplished Computer Scientist
in our lifetime?  Knuth...... Nobody  even comes close to his
body of work. Not Plauger not anyone. He has virtually cataloged
most know algorithms. Impressive work, all in assembler. Not all
would agree with this assessement, but few, if they bother to look
at his 'body of work' are anything but tolally in awe of this
man and his works. You might want to peruse what he has to say
about high level languages, including C and C++. YMMV.

http://www-cs-faculty.stanford.edu/~knuth

> The tools exist because they are an aid, not a crutch.

tools are better once one has mastered the fundamentals. iptables/netfilters
is fundamental to secure linux(embedded or workstation or server).

> If you think iptables should be so easy to pick up, then go pick it up and
> make it work for you - no one is stopping you from that task.

Agreed. I was just looking to jump-start the process by exuming
robust base-line files to begin the journey.... What are the author
and  title to those books you have refered to and which are 
based on 2.6 kernel technology?

> They are up to the task, which is why linux is used a heck of a lot more
> than openbsd...

This is good. Get fired up. Let's publish some raw, robust iptable/netfilter
scipts, and hack/penetration-test the crap out of the rulesets.
That establishes a proven foundation upon which much confidence can
be built. Surely, more folks other than Russell Coker, know how to
do this, and have publish a few cook_books somewhere. If not, why?

> Iptables, as well, can be quite elaborate.  Discernable is another question
> entirely.

> If you know what you're doing, you can create a discernable set of rules
> using custom chains and appropriate ordering.

> Most often, though, what you'll see is the list of rules in some quasi order
> which is supposed to satisfy security and accessibility requirements, but
> hardly show up as being discernable.

OK, where do I read/learn more? Do you have any books you recommend?

> > If you have ruleset capabilities, then look at this example,
> > and tell me what's deficient with it?
> > http://www.linuxguruz.com/iptables/scripts/rc.DMZ.firewall.txt

> First of all the connection tracking rule is too far down in the INPUT
> chain; it should come close to the top to shorten the amount of rules an
> established connection would need to travel through before being accepted.

> Secondly there's no filtering of traffic headed outbound.  Typically any
> windblows & ipp traffic should be blocked at the router, as well as some
> dhcp and dns traffic, as well as any specific service that you want to allow
> to internal services but deny to external services.

Excellent comments!

http://www.gentoo.org/doc/en/home-router-howto.xml
> You are correct in that it is shallow.  The author gives a 'perfect world'
> iptables script without looking at the bad packet handling and ip address
> spoofing at least partially addressed in the previous script.

> The biggest shortcoming in this document is that, although the author goes
> through great details on how to enable connection tracking support for
> netfilter within the kernel, none of the iptables rules the author provides
> support the use of connection tracking!

> And I don't think that either script handles incoming FTP connections well
> at all.

> This has nothing to do with gentoo or any other linux distribution, it has
> everything to do with iptables and their complexities and nuances.


> > The really sad thing in this whole thread, is nobody
> > has even mentiond which (kernel) sources to use, what
> > to disable/enable and why. Is this some sort of deep secret
> > or is the gentoo community un_caring about those who
> > simply want to learn about iptables/netfilter in a 2.6
> > kernel environment? Hell, if this list and the greater
> > gentoo community do not have this aggregated knowledge
> > then let's develop it and document it and share it.
> > This is how we, as the open_source community distinguish
> > ourselves from the Vulture and his menion_buzzards that inhabit
> > Redmond!

> First of all you didn't ask these questions, you asked for rules themselves.

> So, here goes:

> 1. The latest kernel is typically the best to use because it will contain
> the latest security patches.  Stay away from 2.6.12.2 or 3 (I forget which
> one it is) because they have a problem where they will report invalid packet
> issues because of a patch that was applied to networking in general without
> being applied to the specific tcp layers.  I've been using 2.6.13 and have
> been very happy with it.

> 2. For enabling, I'd go to the gentoo doco you referred to earlier.  It
> covers the basic kernel options that you'll want to include support for.

> 3. It is not a deep dark secret, it is just beyond the typical needs of the
> gentoo/linux crowd.

> 4. The information is out there
> (http://www.tldp.org/HOWTO/HOWTO-INDEX/admin.html#ADMSECURITY) you just need
> to know where to look.

Ah, excellent comments and a very nice reference. 3 days of googling did not
reveal such a site. There a lot of confuse folks and old 2.4 base 
documents, fragmented in how they address (if any) issues related to 2.6.
In short, much is dated material. It'd sure be nice if there was a single
document related to 2.6 based iptables/netfilters issues. Sure it'd have
to be a 'live document' but it sure would be useful. I'm pretty much solely
interested in 2.6 based linux technologies. 2.4 had so many problems,
particularly from an embedded perspective. 

> > sincerely, from a dreamer and a looser, and an simpleton,

> I'd agree with the second and third adjectives.

(WHAM-O) Aw, that one felt good!

> Seriously James, it has nothing to do with being afraid of rulesets, it has
> to do with how much folks need to know to get their systems secure, which
> tends to be very simple rules for the average linux user.

Funny, I have never considered any Linux/BSD user to be average. To me
they encompasse the hope and the future of computing..... Encouragement
and knowledge sharing are our greatest tools.

> Linux offers many, many, many more options than what I think that PF allows
> for.  Each kernel option regarding the target and match support has a fellow
> relationship in the iptables rules.  Many folks don't understand or need to
> know for that matter how to set up MARK support or MAC address support, etc.

Now you teasing an embedded linux hack. ARP/MAC machinations are 
of extreme interest to me.

> Finding the folks that know and understand and can apply all of these things
> means you've wandered into the elite of linux security, not the general
> linux community.

Time to disseminate knowledge?

> I don't know much about the BSDs, so I cannot judge what the average BSDer
> knows about PF.  My guess is that they rely for the most part on the out of
> the box security and have little need to dig any further.

Some do some don't much like linux. VXworks, pretty much the largest 
commercial embedded RTOS vendor in the world, built most of their kernel
technology off of good ole BSD. Sure they re-wrote much of the 
code, but's it's pretty much a BSD derivative with slick marketing
and lawyers up the ..... PF is a relatively recent thing, in the 
BSD timeline.

> The same kinds of things can be said about iptables; most folks can get away
> with the default DENY policies whilst enabling outbound and existing
> connection traffic.

> That's why, when folks post questions regarding how to set up their
> firewalls we all throw out tools for them to use to help set them up -
> they're looking for a general setup that provides the protection they need
> w/o interfering with the access they want to have.  The tools, as aids,
> quickly allow them to do that.  And we don't have to deal with the follow up
> questions like how to enable this service or redirect that service; using
> the tool as an aid simplifies the process in general.

OK, I understand. But from the beginning I have tried to emphasize
iptables/netfilters, not out of ignorance, but out of finally
having a few weeks to drill deeply, build my first (linux) firewall,
and have confidence in iptables/netfilter with a 2.6 kernel.
After that, maybe I'll find time to digest and use shorewall,
or maybe I'll start trying to use gentoo to put iptables/netfilter 
on a MOT:coldfire or 7447 processor.....


A book exclusively on iptables/netfilter/2.6 would be keen.
Since I was not very interested in low level things in 2.4, for
a variety of reasons, I find all of those documents that
are incremental to iptables/netfilter/2.4 to be cumbersome
at best. I'd really like a document/book on iptables/netfilter/2.6
that never mentions or references the 2.4 kernel. In my world,
the 2.4 kernel based technologies are dead, burried and the
their wake is 2.6's debutante'

I need foundation, it's going to be painful, and I can hardly sit
still on this. I can always revert to a trusty Obsd firewall 
if needed.... In the mean time, spending my days with
2.6 kernels and less-than-robust iptables/netfilters scripts
 is wonderful way to spend the day.

A beautiful woman once asked why she married the mechanic
out of all the numerous suitors beckoning to her. She replied
"because he torn it up on the first night, and has been
working on it ever since". I like to tear up low level
code and put it back together, piece by piece, too. That's
how I learn, and I find it throughly enjoyable.


Thanks so very much for your clarity of prose and information.

Sincerest Apologies if I offended you, or any others. I'v  come
to expect quite a lot from the Gentoo community. After all it is
the very best OS and folks I have worked with over the years....

James







-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[gentuxx]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James wrote:

>Dave Nebinger <dnebinger <at> joat.com> writes:
>
>
>
> < BIIIIIIIG SNIP >
>
>
>
>A beautiful woman once asked why she married the mechanic
>out of all the numerous suitors beckoning to her. She replied
>"because he torn it up on the first night, and has been
>working on it ever since". I like to tear up low level
>code and put it back together, piece by piece, too. That's
>how I learn, and I find it throughly enjoyable.


Why not just sit down and read the source?  ;-)

>
>[SNIP]
>
>James
>


- --
gentux
echo "hfouvyAdpy/ofu" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
gentux's gpg fingerprint ==> 34CE 2E97 40C7 EF6E EC40 9795 2D81 924A
6996 0993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDH30HLYGSSmmWCZMRApNRAKDWk+iI4AjWDzWtM4Nhs0jr1abZ0wCbBHv+
8KezxRR8XEe8ZN3/ERM43i4=
=LS3H
-----END PGP SIGNATURE-----

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

gentuxx <gentuxx <at> gmail.com> writes:


> Why not just sit down and read the source?  

I'm sure that's going to happen too. But having a 
working machine with iptables/netfilter is like
having a lab-class to go with the 
(theory) lecture part of the class, methinks.

YMMV.

James



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

On Thu, 8 Sep 2005 01:23:26 +0000 (UTC), James wrote:

> > Why not just sit down and read the source?  
> 
> I'm sure that's going to happen too. But having a 
> working machine with iptables/netfilter is like
> having a lab-class to go with the 
> (theory) lecture part of the class, methinks.

So try out some of the standard configurations in Shorewall. Read the
Shorewall scripts to see what they are trying to do then examine the
iptables rules they create to see how it does it. That gives you exactly
what you were asking for, a set of standard, working iptables rules to
learn from, with no GUI in sight. Shorewall is not an automatic rule
generator like Guarddog, it is more like a compiler, turning your source
rules into iptable rules.

By picking up a bunch of rules from some web site somewhere, you run the
risk of learning from bad rules (like learning HTML by picking apart web
sites). If a well known and well used program like Shorewall generated
bad rules, they'd be picked up immediately.


-- 
Neil Bothwick

ASSISTANT MANAGER: Feminine form of the word manager (q.v.).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: iptables example on Gentoo

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> So try out some of the standard configurations in Shorewall. Read the
> Shorewall scripts to see what they are trying to do then examine the
> iptables rules they create to see how it does it. That gives you exactly
> what you were asking for, a set of standard, working iptables rules to
> learn from, with no GUI in sight. Shorewall is not an automatic rule
> generator like Guarddog, it is more like a compiler, turning your source
> rules into iptable rules.

OK, good point. But several folks have mentioned that shorewall is 
not a one-to-one tool for straight iptables/netfilters implementations.
It has things that are not part of a raw usage of iptables/netfilters.
My goal is to learn as much about iptables/netfilters on a Gentoo X86
firewall, before I plunge into iptables/netfilters on an embedded
processor, most likely not x86.


> By picking up a bunch of rules from some web site somewhere, you run the
> risk of learning from bad rules (like learning HTML by picking apart web
> sites). If a well known and well used program like Shorewall generated
> bad rules, they'd be picked up immediately.

Looking at bad rules, learning why they fail, and watching an attack
(either generated by myself or others) with an IDS and other tools running
can be an excellent learning experience. I'm not sure I'll have Shorewall
running on an embedded platform, nor to I want to generate things on
one system and transfer them to a different system(arch) in an embedded
enivronment, not just yet.

Others have indirectly suggested that Shorewall does not directly generate
iptables/netfilters rulesets. I'm looking to get as close to iptables/netfilters
as I can, rather than an immediate need to have a robust linux base firewall.


So If I use Guarddog or Shorewall to generate rulesets, then I can issue:
/etc/init.d/iptables save

and look at the rules. Then I can manually adjust the rules at the command
line, once again issue '/etc/init.d/iptables save' and look at the rules,
make manual(command line) adjustments and continue the learning and testing
process? If this is true, then I can use an x86 firewall with Gentoo on
it to build and test a firewall and then manually implement the ruleset
on an embedded linux project, and similarly test the ruleset (and the
security robustness of the embedded linux kernel and the ip stack
(note: some of the low level driver code for networking will most likely
be 'non standard' code).

Is this logical and correct?

I do appreciate your input and the input from others. I do apologize if
I have offended any, as I do get a little 'wacked' when I'm frustrated. 

sincerely,
James


-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> So try out some of the standard configurations in Shorewall. Read the
> Shorewall scripts to see what they are trying to do then examine the
> iptables rules they create to see how it does it. That gives you exactly
> what you were asking for, a set of standard, working iptables rules to
> learn from, with no GUI in sight. Shorewall is not an automatic rule
> generator like Guarddog, it is more like a compiler, turning your source
> rules into iptable rules.

OK, good point. But several folks have mentioned that shorewall is 
not a one-to-one tool for straight iptables/netfilters implementations.
It has things that are not part of a raw usage of iptables/netfilters.
My goal is to learn as much about iptables/netfilters on a Gentoo X86
firewall, before I plunge into iptables/netfilters on an embedded
processor, most likely not x86.


> By picking up a bunch of rules from some web site somewhere, you run the
> risk of learning from bad rules (like learning HTML by picking apart web
> sites). If a well known and well used program like Shorewall generated
> bad rules, they'd be picked up immediately.

Looking at bad rules, learning why they fail, and watching an attack
(either generated by myself or others) with an IDS and other tools running
can be an excellent learning experience. I'm not sure I'll have Shorewall
running on an embedded platform, nor to I want to generate things on
one system and transfer them to a different system(arch) in an embedded
enivronment, not just yet.

Others have indirectly suggested that Shorewall does not directly generate
iptables/netfilters rulesets. I'm looking to get as close to iptables/netfilters
as I can, rather than an immediate need to have a robust linux base firewall.


So If I use Guarddog or Shorewall to generate rulesets, then I can issue:
/etc/init.d/iptables save

and look at the rules. Then I can manually adjust the rules at the command
line, once again issue '/etc/init.d/iptables save' and look at the rules,
make manual(command line) adjustments and continue the learning and testing
process? If this is true, then I can use an x86 firewall with Gentoo on
it to build and test a firewall and then manually implement the ruleset
on an embedded linux project, and similarly test the ruleset (and the
security robustness of the embedded linux kernel and the ip stack
(note: some of the low level driver code for networking will most likely
be 'non standard' code).

Is this logical and correct?

I do appreciate your input and the input from others. I do apologize if
I have offended any, as I do get a little 'wacked' when I'm frustrated. 

sincerely,
James


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

> OK, good point. But several folks have mentioned that shorewall is
> not a one-to-one tool for straight iptables/netfilters implementations.
> It has things that are not part of a raw usage of iptables/netfilters.
> My goal is to learn as much about iptables/netfilters on a Gentoo X86
> firewall, before I plunge into iptables/netfilters on an embedded
> processor, most likely not x86.

That is incorrect.  Shorewall is, at it's heart, a scripting engine that 
builds iptables rules based upon the contents of the shorewall configuration 
files.  Once the shorewall engine produces the iptables rules, the process 
goes away (there is no lingering shorewall process after it comes up).

> Looking at bad rules, learning why they fail, and watching an attack
> (either generated by myself or others) with an IDS and other tools running
> can be an excellent learning experience. I'm not sure I'll have Shorewall
> running on an embedded platform, nor to I want to generate things on
> one system and transfer them to a different system(arch) in an embedded
> enivronment, not just yet.
>
> Others have indirectly suggested that Shorewall does not directly generate
> iptables/netfilters rulesets. I'm looking to get as close to 
> iptables/netfilters
> as I can, rather than an immediate need to have a robust linux base 
> firewall.

It does generate iptable rules, but they are customized for shorewall's 
purposes.  For example, my shorewall setup builds the following iptables 
rules:

# Generated by iptables-save v1.3.2 on Thu Sep  8 12:32:48 2005
*nat
:PREROUTING ACCEPT [34942:3100331]
:POSTROUTING ACCEPT [106864:7597940]
:OUTPUT ACCEPT [106858:7597722]
:net_dnat - [0:0]
:w1ad_masq - [0:0]
-A PREROUTING -i w1ad -j net_dnat
-A POSTROUTING -o w1ad -j w1ad_masq
-A net_dnat -p udp -m multiport --dports 
27900,29900,27901,55123:55125,1500:4999,16567 -j DNAT --to-destination 
192.168.0.10
-A net_dnat -p tcp -m multiport --dports 29900,29901,28910,4711 -j 
DNAT --to-destination 192.168.0.10
-A net_dnat -p tcp -m tcp --dport 5000:5201 -j DNAT --to-destination 
192.168.0.10
-A net_dnat -p tcp -m tcp --dport 51000:52000 -j DNAT --to-destination 
192.168.0.10
-A net_dnat -p tcp -m tcp --dport 10023 -j DNAT --to-destination 
192.168.0.10
-A net_dnat -p tcp -m tcp --sport 8086 --dport 8085 -j DNAT --to-destination 
192.168.0.10
-A w1ad_masq -s 255.255.255.255 -j MASQUERADE
-A w1ad_masq -s 192.168.0.0/255.255.255.0 -j MASQUERADE
COMMIT
# Completed on Thu Sep  8 12:32:48 2005
# Generated by iptables-save v1.3.2 on Thu Sep  8 12:32:48 2005
*mangle
:PREROUTING ACCEPT [11532470:15305239824]
:INPUT ACCEPT [10012668:14215875107]
:FORWARD ACCEPT [1519785:1089361813]
:OUTPUT ACCEPT [8826128:782474663]
:POSTROUTING ACCEPT [10353251:1873002122]
:outtos - [0:0]
:pretos - [0:0]
-A PREROUTING -j pretos
-A OUTPUT -j outtos
-A outtos -p tcp -m tcp --dport 22 -j TOS --set-tos 0x10
-A outtos -p tcp -m tcp --sport 22 -j TOS --set-tos 0x10
-A outtos -p tcp -m tcp --dport 21 -j TOS --set-tos 0x10
-A outtos -p tcp -m tcp --sport 21 -j TOS --set-tos 0x10
-A outtos -p tcp -m tcp --sport 20 -j TOS --set-tos 0x08
-A outtos -p tcp -m tcp --dport 20 -j TOS --set-tos 0x08
-A pretos -p tcp -m tcp --dport 22 -j TOS --set-tos 0x10
-A pretos -p tcp -m tcp --sport 22 -j TOS --set-tos 0x10
-A pretos -p tcp -m tcp --dport 21 -j TOS --set-tos 0x10
-A pretos -p tcp -m tcp --sport 21 -j TOS --set-tos 0x10
-A pretos -p tcp -m tcp --sport 20 -j TOS --set-tos 0x08
-A pretos -p tcp -m tcp --dport 20 -j TOS --set-tos 0x08
COMMIT
# Completed on Thu Sep  8 12:32:49 2005
# Generated by iptables-save v1.3.2 on Thu Sep  8 12:32:49 2005
*filter
:AllowFTP - [0:0]
:AllowICMPs - [0:0]
:Drop - [0:0]
:DropDNSrep - [0:0]
:DropSMB - [0:0]
:DropUPnP - [0:0]
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [1:60]
:Reject - [0:0]
:RejectAuth - [0:0]
:RejectSMB - [0:0]
:all2all - [0:0]
:blacklst - [0:0]
:dropBcast - [0:0]
:dropInvalid - [0:0]
:dropNotSyn - [0:0]
:dynamic - [0:0]
:eth1_fwd - [0:0]
:eth1_in - [0:0]
:fw2loc - [0:0]
:fw2net - [0:0]
:loc2fw - [0:0]
:loc2net - [0:0]
:logflags - [0:0]
:net2all - [0:0]
:net2fw - [0:0]
:net2loc - [0:0]
:norfc1918 - [0:0]
:reject - [0:0]
:rfc1918 - [0:0]
:shorewall - [0:0]
:smurfs - [0:0]
:tcpflags - [0:0]
:w1ad_fwd - [0:0]
:w1ad_in - [0:0]
-A AllowFTP -p tcp -m tcp --dport 21 -j ACCEPT
-A AllowICMPs -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
-A AllowICMPs -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A Drop -j RejectAuth
-A Drop -j dropBcast
-A Drop -p icmp -j AllowICMPs
-A Drop -j dropInvalid
-A Drop -j DropSMB
-A Drop -j DropUPnP
-A Drop -p tcp -j dropNotSyn
-A Drop -j DropDNSrep
-A DropDNSrep -p udp -m udp --sport 53 -j DROP
-A DropSMB -p udp -m udp --dport 135 -j DROP
-A DropSMB -p udp -m udp --dport 137:139 -j DROP
-A DropSMB -p udp -m udp --dport 445 -j DROP
-A DropSMB -p tcp -m tcp --dport 135 -j DROP
-A DropSMB -p tcp -m tcp --dport 139 -j DROP
-A DropSMB -p tcp -m tcp --dport 445 -j DROP
-A DropUPnP -p udp -m udp --dport 1900 -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i w1ad -j w1ad_in
-A INPUT -i eth1 -j eth1_in
-A INPUT -j Reject
-A INPUT -j LOG --log-prefix "Shorewall:INPUT:REJECT:" --log-level 6
-A INPUT -j reject
-A FORWARD -i w1ad -j w1ad_fwd
-A FORWARD -i eth1 -j eth1_fwd
-A FORWARD -j Reject
-A FORWARD -j LOG --log-prefix "Shorewall:FORWARD:REJECT:" --log-level 6
-A FORWARD -j reject
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o w1ad -p udp -m udp --dport 67:68 -j ACCEPT
-A OUTPUT -o eth1 -p udp -m udp --dport 67:68 -j ACCEPT
-A OUTPUT -o w1ad -j fw2net
-A OUTPUT -o eth1 -j fw2loc
-A OUTPUT -j Reject
-A OUTPUT -j LOG --log-prefix "Shorewall:OUTPUT:REJECT:" --log-level 6
-A OUTPUT -j reject
-A Reject -j RejectAuth
-A Reject -j dropBcast
-A Reject -p icmp -j AllowICMPs
-A Reject -j dropInvalid
-A Reject -j RejectSMB
-A Reject -j DropUPnP
-A Reject -p tcp -j dropNotSyn
-A Reject -j DropDNSrep
-A RejectAuth -p tcp -m tcp --dport 113 -j reject
-A RejectSMB -p udp -m udp --dport 135 -j reject
-A RejectSMB -p udp -m udp --dport 137:139 -j reject
-A RejectSMB -p udp -m udp --dport 445 -j reject
-A RejectSMB -p tcp -m tcp --dport 135 -j reject
-A RejectSMB -p tcp -m tcp --dport 139 -j reject
-A RejectSMB -p tcp -m tcp --dport 445 -j reject
-A all2all -m state --state RELATED,ESTABLISHED -j ACCEPT
-A all2all -j Reject
-A all2all -j LOG --log-prefix "Shorewall:all2all:REJECT:" --log-level 6
-A all2all -j reject
-A blacklst -s 213.131.253.24 -j LOG --log-prefix 
"Shorewall:blacklst:DROP:" --log-level 5
-A blacklst -s 213.131.253.24 -j DROP
-A blacklst -s 221.12.14.7 -j LOG --log-prefix 
"Shorewall:blacklst:DROP:" --log-level 5
-A blacklst -s 221.12.14.7 -j DROP
-A blacklst -s 59.0.0.0/255.0.0.0 -p tcp -m tcp --dport 25 -j 
LOG --log-prefix "Shorewall:blacklst:DROP:" --log-level 5
-A blacklst -s 59.0.0.0/255.0.0.0 -p tcp -m tcp --dport 25 -j DROP
-A dropBcast -m pkttype --pkt-type broadcast -j DROP
-A dropBcast -m pkttype --pkt-type multicast -j DROP
-A dropInvalid -m state --state INVALID -j DROP
-A dropNotSyn -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A eth1_fwd -m state --state INVALID,NEW -j dynamic
-A eth1_fwd -p tcp -j tcpflags
-A eth1_fwd -o w1ad -j loc2net
-A eth1_in -m state --state INVALID,NEW -j dynamic
-A eth1_in -p udp -m udp --dport 67:68 -j ACCEPT
-A eth1_in -p tcp -j tcpflags
-A eth1_in -j loc2fw
-A fw2loc -m state --state RELATED,ESTABLISHED -j ACCEPT
-A fw2loc -p icmp -j ACCEPT
-A fw2loc -j ACCEPT
-A fw2net -m state --state RELATED,ESTABLISHED -j ACCEPT
-A fw2net -p tcp -m tcp --dport 631 -j DROP
-A fw2net -p tcp -m tcp --dport 2401 -j ACCEPT
-A fw2net -p udp -m udp --dport 2401 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 53 -j ACCEPT
-A fw2net -p udp -m udp --dport 53 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 123 -j ACCEPT
-A fw2net -p udp -m udp --dport 123 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 873 -j ACCEPT
-A fw2net -p udp -m udp --dport 873 -j ACCEPT
-A fw2net -p icmp -j ACCEPT
-A fw2net -d 206.46.232.12 -p tcp -m tcp --dport 25 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 110 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 113 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 119 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 2703 -j ACCEPT
-A fw2net -p udp -m udp --dport 6277 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 80 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 21 -j ACCEPT
-A fw2net -p tcp -m tcp --dport 20 -j ACCEPT
-A fw2net -j AllowFTP
-A fw2net -j all2all
-A loc2fw -m state --state RELATED,ESTABLISHED -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 8085 -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 873 -j ACCEPT
-A loc2fw -p udp -m udp --dport 873 -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 10022 -j ACCEPT
-A loc2fw -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 25 -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 110 -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 113 -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 119 -j ACCEPT
-A loc2fw -p udp -m udp --dport 6277 -j ACCEPT
-A loc2fw -p tcp -m tcp --dport 3306 -j ACCEPT
-A loc2fw -j AllowFTP
-A loc2fw -p udp -m multiport --dports 1026,1027,1028,1029 -j 
LOG --log-prefix "Shorewall:loc2fw:DROP:" --log-level 6
-A loc2fw -p udp -m multiport --dports 1026,1027,1028,1029 -j DROP
-A loc2fw -j ACCEPT
-A loc2net -m state --state RELATED,ESTABLISHED -j ACCEPT
-A loc2net -p tcp -m tcp --dport 631 -j DROP
-A loc2net -j AllowFTP
-A loc2net -p udp -m udp --dport 6346 -j DROP
-A loc2net -p tcp -m tcp --dport 6346 -j DROP
-A loc2net -p udp -m multiport --dports 67,68 -j DROP
-A loc2net -j ACCEPT
-A logflags -j LOG --log-prefix "Shorewall:logflags:DROP:" --log-level 
6 --log-ip-options
-A logflags -j DROP
-A net2all -m state --state RELATED,ESTABLISHED -j ACCEPT
-A net2all -j Drop
-A net2all -j LOG --log-prefix "Shorewall:net2all:DROP:" --log-level 6
-A net2all -j DROP
-A net2fw -m state --state RELATED,ESTABLISHED -j ACCEPT
-A net2fw -p tcp -m tcp --dport 22 -j ACCEPT
-A net2fw -p tcp -m tcp --dport 8085 -j ACCEPT
-A net2fw -p tcp -m tcp --dport 10022 -j ACCEPT
-A net2fw -p tcp -m tcp --dport 8085 -j ACCEPT
-A net2fw -p tcp -m tcp --dport 25 -j ACCEPT
-A net2fw -p tcp -m tcp --dport 110 -j ACCEPT
-A net2fw -p tcp -m tcp --dport 113 -j ACCEPT
-A net2fw -p udp -m udp --dport 6277 -j ACCEPT
-A net2fw -j AllowFTP
-A net2fw -p udp -m udp --dport 6346 -j DROP
-A net2fw -p tcp -m tcp --dport 6346 -j DROP
-A net2fw -p udp -m multiport --dports 1026,1027,1028,1029 -j DROP
-A net2fw -j net2all
-A net2loc -m state --state RELATED,ESTABLISHED -j ACCEPT
-A net2loc -d 192.168.0.10 -p udp -m multiport --dports 
27900,29900,27901,55123:55125,1500:4999,16567 -j ACCEPT
-A net2loc -d 192.168.0.10 -p tcp -m multiport --dports 
29900,29901,28910,4711 -j ACCEPT
-A net2loc -p tcp -m tcp --dport 5000:5201 -j ACCEPT
-A net2loc -d 192.168.0.10 -p tcp -m tcp --dport 5000:5201 -j ACCEPT
-A net2loc -d 192.168.0.10 -p tcp -m tcp --dport 51000:52000 -j ACCEPT
-A net2loc -d 192.168.0.10 -p tcp -m tcp --dport 10023 -j ACCEPT
-A net2loc -d 192.168.0.10 -p tcp -m tcp --sport 8086 --dport 8085 -j ACCEPT
-A net2loc -p udp -m multiport --sports 67,68 -j LOG --log-prefix 
"Shorewall:net2loc:DROP:" --log-level 6
-A net2loc -p udp -m multiport --sports 67,68 -j DROP
-A net2loc -j net2all
-A norfc1918 -s 172.16.0.0/255.240.0.0 -j rfc1918
-A norfc1918 -m conntrack --ctorigdst 172.16.0.0/12 -j rfc1918
-A norfc1918 -s 192.168.0.0/255.255.0.0 -j rfc1918
-A norfc1918 -m conntrack --ctorigdst 192.168.0.0/16 -j rfc1918
-A norfc1918 -s 10.0.0.0/255.0.0.0 -j rfc1918
-A norfc1918 -m conntrack --ctorigdst 10.0.0.0/8 -j rfc1918
-A reject -m pkttype --pkt-type broadcast -j DROP
-A reject -m pkttype --pkt-type multicast -j DROP
-A reject -s 71.114.131.255 -j DROP
-A reject -s 192.168.0.255 -j DROP
-A reject -s 255.255.255.255 -j DROP
-A reject -s 224.0.0.0/240.0.0.0 -j DROP
-A reject -p tcp -j REJECT --reject-with tcp-reset
-A reject -p udp -j REJECT --reject-with icmp-port-unreachable
-A reject -p icmp -j REJECT --reject-with icmp-host-unreachable
-A reject -j REJECT --reject-with icmp-host-prohibited
-A rfc1918 -j LOG --log-prefix "Shorewall:rfc1918:DROP:" --log-level 6
-A rfc1918 -j DROP
-A smurfs -s 71.114.131.255 -j LOG --log-prefix 
"Shorewall:smurfs:DROP:" --log-level 6
-A smurfs -s 71.114.131.255 -j DROP
-A smurfs -s 192.168.0.255 -j LOG --log-prefix 
"Shorewall:smurfs:DROP:" --log-level 6
-A smurfs -s 192.168.0.255 -j DROP
-A smurfs -s 255.255.255.255 -j LOG --log-prefix 
"Shorewall:smurfs:DROP:" --log-level 6
-A smurfs -s 255.255.255.255 -j DROP
-A smurfs -s 224.0.0.0/240.0.0.0 -j LOG --log-prefix 
"Shorewall:smurfs:DROP:" --log-level 6
-A smurfs -s 224.0.0.0/240.0.0.0 -j DROP
-A tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j 
logflags
-A tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j 
logflags
-A tcpflags -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j logflags
-A tcpflags -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j logflags
-A tcpflags -p tcp -m tcp --sport 0 --tcp-flags FIN,SYN,RST,ACK SYN -j 
logflags
-A w1ad_fwd -m state --state INVALID,NEW -j dynamic
-A w1ad_fwd -m state --state INVALID,NEW -j blacklst
-A w1ad_fwd -m state --state NEW -j norfc1918
-A w1ad_fwd -p tcp -j tcpflags
-A w1ad_fwd -o eth1 -j net2loc
-A w1ad_in -m state --state INVALID,NEW -j dynamic
-A w1ad_in -m state --state INVALID,NEW -j blacklst
-A w1ad_in -p udp -m udp --dport 67:68 -j ACCEPT
-A w1ad_in -m state --state NEW -j norfc1918
-A w1ad_in -p tcp -j tcpflags
-A w1ad_in -j net2fw
COMMIT
# Completed on Thu Sep  8 12:32:49 2005

Values unique to my environment:
  w1ad - my ADSL card which is connected to the internet
  fw - The box that is the firewall
  loc - The local network inside the firewall
  net - The internet as a whole.
  eth0 - My DMZ card, currently not being used.
  eth1 - My intranet card, currently in use.

These are all valid rules and are constructed by shorewall.  Would they be 
the same if I hand-coded them?  Absolutely not.  I wouldn't have so many 
custom chains and would probably reorder the rules to give priorities to 
specific services.

And, I would argue that whilst these rules are valid and do perform the 
firewall chores that I want/need, the format of the rules would leave a lot 
to be desired to try to maintain manually via the command line.

>
> So If I use Guarddog or Shorewall to generate rulesets, then I can issue:
> /etc/init.d/iptables save

Don't know about guarddog, but with shorewall the answer is yes (as 
demonstrated by the output above).

> and look at the rules. Then I can manually adjust the rules at the command
> line, once again issue '/etc/init.d/iptables save' and look at the rules,
> make manual(command line) adjustments and continue the learning and 
> testing
> process? If this is true, then I can use an x86 firewall with Gentoo on
> it to build and test a firewall and then manually implement the ruleset
> on an embedded linux project, and similarly test the ruleset (and the
> security robustness of the embedded linux kernel and the ip stack
> (note: some of the low level driver code for networking will most likely
> be 'non standard' code).
>
> Is this logical and correct?
>
> I do appreciate your input and the input from others. I do apologize if
> I have offended any, as I do get a little 'wacked' when I'm frustrated.

You'll soon learn that, whilst this community loves to get people up and 
running using gentoo/linux, we don't respond well to the tones of your 
messages in previous days.  Holly, especially, is a wonderful resource and 
really didn't deserve the response that she got.

-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] Re: iptables example on Gentoo

[Michael Kintzios]

> -----Original Message-----
> From: Dave Nebinger [mailto:dnebinger@joat.com] 
> Sent: 08 September 2005 17:42
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] Re: iptables example on Gentoo
> 
[snip] 
> It does generate iptable rules, but they are customized for 
> shorewall's 
> purposes.  For example, my shorewall setup builds the 
> following iptables 
> rules:
> 
> # Generated by iptables-save v1.3.2 on Thu Sep  8 12:32:48 2005
> *nat
> :PREROUTING ACCEPT [34942:3100331]
> :POSTROUTING ACCEPT [106864:7597940]
> :OUTPUT ACCEPT [106858:7597722]
> :net_dnat - [0:0]
> :w1ad_masq - [0:0]
> -A PREROUTING -i w1ad -j net_dnat
> -A POSTROUTING -o w1ad -j w1ad_masq
> -A net_dnat -p udp -m multiport --dports 

What is the "[34942:3100331]" and "[106864:7597940]" references above?

> These are all valid rules and are constructed by shorewall.  
> Would they be 
> the same if I hand-coded them?  Absolutely not.  I wouldn't 
> have so many 
> custom chains and would probably reorder the rules to give 
> priorities to 
> specific services.
> 
> And, I would argue that whilst these rules are valid and do 
> perform the 
> firewall chores that I want/need, the format of the rules 
> would leave a lot 
> to be desired to try to maintain manually via the command line.

If I understand this right:  Shorewall, firehol, fwbuilder, etc.,
'just-works', but it kludges the iptables?  Some of these 'helpers' may
also require you to learn some additional scripting format other than
the conventional iptables.  I guess that's similar to using some HTML
WYSIWYG instead of hand coding it yourself.
-- 
Regards,
Mick

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Dave Nebinger]

>> # Generated by iptables-save v1.3.2 on Thu Sep  8 12:32:48 2005
>> *nat
>> :PREROUTING ACCEPT [34942:3100331]
>> :POSTROUTING ACCEPT [106864:7597940]
>> :OUTPUT ACCEPT [106858:7597722]
>> :net_dnat - [0:0]
>> :w1ad_masq - [0:0]
>> -A PREROUTING -i w1ad -j net_dnat
>> -A POSTROUTING -o w1ad -j w1ad_masq
>> -A net_dnat -p udp -m multiport --dports
>
> What is the "[34942:3100331]" and "[106864:7597940]" references above?

Without specifying options to iptables-save, it includes the counters in the 
format [packet-counter:byte-counter].  I don't use the counters myself, so I 
don't really know for sure what purpose they serve (I'm sure the doco could 
shed some light on it).  My guess is that they are used for either QOS or 
throttling or something.

>> These are all valid rules and are constructed by shorewall.
>> Would they be
>> the same if I hand-coded them?  Absolutely not.  I wouldn't
>> have so many
>> custom chains and would probably reorder the rules to give
>> priorities to
>> specific services.
>>
>> And, I would argue that whilst these rules are valid and do
>> perform the
>> firewall chores that I want/need, the format of the rules
>> would leave a lot
>> to be desired to try to maintain manually via the command line.
>
> If I understand this right:  Shorewall, firehol, fwbuilder, etc.,
> 'just-works', but it kludges the iptables?  Some of these 'helpers' may
> also require you to learn some additional scripting format other than
> the conventional iptables.

I don't think that 'kludges' is the right word for it.

When hand-coding iptables scripts, it makes sense to create custom chains to 
organize your iptables script somewhat.  Shorewall (and the others although 
I'm not familiar with their direct interactions with iptables) does this as 
well.  The difficulty is that shorewall is capable of handling so many 
different configurations.  The various custom chains that it creates are 
targeted towards someone that's using all of the various parts of shorewall; 
when you scale back to a limited setup with a small set of logical rules, 
shorewall still handles it easily but constructs all of the custom chains 
and interlinkings that would be used in a more complex setup.

Which is why the iptables-save output I posted is a heck of a lot bigger 
than what my logical set of rules contains.

> I guess that's similar to using some HTML
> WYSIWYG instead of hand coding it yourself.

That's a very good analogy, and more apropos to the actual output of 
shorewall et. al.  Although the output of the tool is functionaly similar to 
what you would do by hand, it is typically more complicated and not close to 
what you would have done hand-coding it.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Thu, 8 Sep 2005 16:19:53 +0000 (UTC), James wrote:

> > By picking up a bunch of rules from some web site somewhere, you run
> > the risk of learning from bad rules (like learning HTML by picking
> > apart web sites). If a well known and well used program like
> > Shorewall generated bad rules, they'd be picked up immediately.
> 
> Looking at bad rules, learning why they fail, and watching an attack
> (either generated by myself or others) with an IDS and other tools
> running can be an excellent learning experience.

Only if you know they are bad rules. Bearing in mind that you are
unlikely to find a site that says "here are my iptables rules, aren't
they crap?", how will you know whether you are learning from good or bad
examples?


-- 
Neil Bothwick

What Aussies lack in Humour they make up for in Beer!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Re: iptables example on Gentoo

[Jerry McBride]

On Thursday 08 September 2005 01:23 am, James wrote:
> gentuxx <gentuxx <at> gmail.com> writes:
> > Why not just sit down and read the source?
>
> I'm sure that's going to happen too. But having a
> working machine with iptables/netfilter is like
> having a lab-class to go with the
> (theory) lecture part of the class, methinks.
>
> YMMV.
>
> James

That's what I'm doing just this minute. Old laptop on my home lan, iptables on 
gentoo and a copy of LINUX FIREWALLS 2nd Edition by Robert L. Ziegler.

Pretty heady stuff, but a great way to pass the time before bed.... A little 
brandy doesn't hurt either.

Cheers.

-- 

******************************************************************************
                     Registered Linux User Number 185956
              FSF Associate Member number 2340 since 05/20/2004
             Join me in chat at #linux-users on irc.freenode.net
    Buy an Xbox for $149.00, run linux on it and Microsoft loses $150.00!
     8:51pm  up 52 days, 20:50,  2 users,  load average: 0.00, 0.00, 0.00
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Rumen Yotov]

Hi,
James escreveu:

>Dave Nebinger <dnebinger <at> joat.com> writes:
>
>
>  
>
>>>I think it might be important to point out here how Shorewall
>>>handles/uses these files.  I don't use Shorewall, so I can't really
>>>shed light on it.  But these config files are really only one side of
>>>the mirror.
>>>      
>>>
>
>Sorry, I HAVE ZERO INTEREST IN A GUI, UNLESS THE RESULTING RULESETS
>ARE SIMILAR TO THOSE BUILT MANUALLY with a one-to-one correspondance
>to iptables/netfilter.
>
>  
>
IMHO shorewall isn't a GUI it's just a script (might be wrong here) with 
many config files for many (quite all) possible usages and with a manual 
(in pdf & other formats) which is around 500-600 pages.
All  the configuration is done by editing files in: /etc/shorewall/... 
directory (and they come heavily commented).

>...SKIP...
>OpenBSD + PF is a piece of cake. OpenBSD comes secure right 
>out of the box. If the gentoo experts that peruse this list 
>read this email, surely they can direct one to examples where 
>the details of secure rulesets exist? 
>Surely someone is  confident enough in their 
>iptables/netfilter rulesets to publish them?
>
>  
>
IMO OpenBSD initial goal was just that - to be very secure even in it's 
default install. Haven't seen such claim for Gentoo (plain).

>Maybe the linux security models are not up to the task?
>SElinux etc....?
>  
>
Have some experience with Grsec2+PaX and RSBAC (SElinux brother ;)
IMHO they are significantly better than OpenBSD in overall security.
The "new/next" version of OpenBSD will have some sort of protection 
against memory overflow attacks (writting this by memory only, might not 
be 100% correct) so they are slowing nest release to test this 'new' 
feature - which one and others too are already used by Hardened Gentoo.
Check 'Adamantix' - Debian + PaX (memory protection) + RSBAC (DAC).
Example: see 'gibraltar' router/firewall distro - uses RSBAC-kernel.

>PF rulessets are quite elaborate, but easily discernable.
>
>You know, 'the rat' culture is questionable, but, he's really quite
>talented and reasonable, once you get past the phasic behavior.
>
>OpenBSD comes secure, right out off the installation. Builing a really
>secure firewall is trivial. I thought (gentoo)linux was suppose to
>be equal to or superior to OpenBSD for security and every other
>aspect of computing?
>
>If you have ruleset capabilities, then look at this example,
>and tell me what's deficient with it? 
>http://www.linuxguruz.com/iptables/scripts/rc.DMZ.firewall.txt
>
>It was created for
>2.4 based kernels, but this simple website shows one
>how to prepare a 2.6 kernel as the basis of the firewall:
>http://www.gentoo.org/doc/en/home-router-howto.xml
>It is a bit shallow, but at least this author is
>not scared of iptables/netfilter fundamentals.
>
>(Booo) <this is where the Gentooers mess their britches?>
>
>
>The really sad thing in this whole thread, is nobody
>has even mentiond which (kernel) sources to use, what
>to disable/enable and why. Is this some sort of deep secret
>or is the gentoo community un_caring about those who
>simply want to learn about iptables/netfilter in a 2.6
>kernel environment? Hell, if this list and the greater
>gentoo community do not have this aggregated knowledge
>then let's develop it and document it and share it. 
>This is how we, as the open_source community distinguish 
>ourselves from the Vulture and his menion_buzzards that inhabit
>Redmond!
>
>sincerely, from a dreamer and a looser, and an simpleton,
>
>(but, I'm not afraid of any stinking rule_set, are you?)
>
>James
>
>  
>
No flames please, just my opinion.
HTH. Rumen
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Rumen Yotov <rumen_yotov <at> dir.bg> writes:


> IMO OpenBSD initial goal was just that - to be very secure even in it's 
> default install. Haven't seen such claim for Gentoo (plain).

Huh?

"This release also gives provides two additional x86 LiveCD images, in
combination with the minimal and universal InstallCDs seen in previous
releases: a new x86 LiveCD from the Hardened project "

And the corresponding CD:
http://open-systems.ufl.edu/mirrors/gentoo/experimental/x86/hardened/livecd

> Have some experience with Grsec2+PaX and RSBAC (SElinux brother ;)
> IMHO they are significantly better than OpenBSD in overall security.
> The "new/next" version of OpenBSD will have some sort of protection 
> against memory overflow attacks (writting this by memory only, might not 
> be 100% correct) so they are slowing nest release to test this 'new' 
> feature - which one and others too are already used by Hardened Gentoo.
> Check 'Adamantix' - Debian + PaX (memory protection) + RSBAC (DAC).
> Example: see 'gibraltar' router/firewall distro - uses RSBAC-kernel.

Beautiful Prose! Any  Other contributors care to 'Stand Up'?


> No flames please, just my opinion.
> HTH. Rumen

Rumen, I never flame. I try to inspire, sometimes making
my community and friends ashamed of ourselves and myself. 
Surely, I run the risk of becoming an outcast within a group
of radicals (GENTOO)? Not the first time I've been 86'd
from a place where they never toss out radical and dreamers....

Certainly, there are others feeling the pain of less than fantastic
security on Gentoo! Hacking the raw files will allow migration
of proven security models to countless (embedded) gentoo
devices. Once perfected, the GUI frontends can be honestly tested
and evaluated for robustness.

AT  www.shorewall.net (interestingly not www.shorewall.org)
WE see in big red bold letters:
"Security vulnerability in Shorewall 2.x"

I'll stick with iptables/netfilter directly, until multiple, proven
scripts and configurations are published. Then we can all
play with GUI tools.......

Business vs Integrity(Freedom).....
Funny, Gentoo was very quick to dump XFree for Xorg,
in name of righteous OpenSource propaganda.

Yet the same level of detail with documented usage of a 2.6
kernel and iptables/netfilter alludes us?

Business versus Integrity? or just an oversight?

Common man, we're all guilty. Let's group together, straighten
out this sess_pool, and live with Integrity!

-- the most guilty of all,

James




-- 
gentoo-user@gentoo.org mailing list

RE: [gentoo-user] iptables example on Gentoo

[Bryan Whitehead]

Wow, that is news to me... I've always just banged out iptables rules and 
then saved them...

On Tue, 6 Sep 2005, Dave Nebinger wrote:

>> I've been trying to build a simple firewall with a DMZ for a
>> web server.
>
> Dude, trying to use iptables directly was your first mistake.
>
> Take a spin out and look at shorewall (I'm sure others have different
> recommendations).
>
> Shorewall will get you up and running in no time and will easily handle the
> configuration stuff from your original post.
>
> Trying to manage such a complex config using iptables directly is doomed to
> failure; any mistake in ordering of rules, etc., will break your
> connectivity.  Sticking with a tool like shorewall will simplify rules
> maintenance and pose less of a problem when performing updates later on.
>
> Dave
>
>
>

-- 
Bryan Whitehead
Email:driver@megahappy.net
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: iptables example on Gentoo

[James]

Bryan Whitehead <driver <at> megahappy.net> writes:

> 
> Wow, that is news to me... I've always just banged out iptables rules and 
> then saved them...


Got anything to share? Surely a 3 nic firewall {
WAN(single IP), LAN and DMZ, with a web server and eventually
2 dns servers on the DMZ is not really a big deal?

Which kernel sources did you use? Anything tricky 
in building the kernel?

The system is only going to be a firewall/router
so only minimal necessary packages will be installed.


James

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: iptables example on Gentoo

[Rumen Yotov]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Thu, 2005-09-08 at 01:34 +0000, James wrote:
> Bryan Whitehead <driver <at> megahappy.net> writes:
> 
> > 
> > Wow, that is news to me... I've always just banged out iptables rules and 
> > then saved them...
> 
> 
> Got anything to share? Surely a 3 nic firewall {
> WAN(single IP), LAN and DMZ, with a web server and eventually
> 2 dns servers on the DMZ is not really a big deal?
> 
> Which kernel sources did you use? Anything tricky 
> in building the kernel?
> 
> The system is only going to be a firewall/router
> so only minimal necessary packages will be installed.
> 
> 
> James
> 
Hi James,
Haven't tried all (only for a single card) but on the 'shorewall.net"
site there are sample configs for a single, with two and three Lan card
interfaces (WAN, LAN, DMZ). Used one myself.
In the docs there are even graphical ;) screen-shots of the
kernel-config options which you need to use to get all of shorewall
features. Recommended iptables config.
Don't think you believe there is a piece of software which doesn't have
(now) or didn't have at some point of time a Bug or two or more.
HTH. Rumen

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] iptables example on Gentoo

[Timo Boettcher]

Hi Dave,


* Dave Nebinger <dnebinger@joat.com>, Tuesday, September 6, 2005, 7:39:53 PM:

>> I've been trying to build a simple firewall with a DMZ for a
>> web server.

> Dude, trying to use iptables directly was your first mistake.
no, it wasn't.

I have written some "small" example script
http://forums.gentoo.org/viewtopic.php?p=377447
that (IMO) is quite modular...


 Timo

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] iptables example on Gentoo

[Dave Nebinger]

>> Dude, trying to use iptables directly was your first mistake.
> no, it wasn't.
>
> I have written some "small" example script
> http://forums.gentoo.org/viewtopic.php?p=377447
> that (IMO) is quite modular...

Yes, Timo, it is quite modular and quite thorough.  It represents a great 
job at developing a general set of rules.

But I would raise the following issues:

1. FTP support: You've allowed for the active ftp protocols on ports 20 & 
21, but what about passive?  This traffic will usually be on the higher 
ports (typically a range specified in the configuration for the ftp daemon). 
I do believe that if the ftp daemon tries to open a passive connection 
outbound it's going to get knocked off at the knees.

2. Measure the checks: The more checks that a packet goes through, the 
longer it will take to travel through the iptables stack.  Your script has a 
lot of checks in it.  Consider a pgp packet as it traverses all of the 
chains etc. that you've specified.  You're probably looking at 30+ checks at 
least (although I haven't counted each individual check, but I'm confident 
it is quite a large number).  That's a significant number of hops and means 
the packet is going to be hanging around on the box a lot longer than what 
it really should.

3. No detail on why the checks are ordered in the way they are (is there an 
order?):  As #2 indicates, the increased number of checks that a packet 
needs to be pushed through means it will hang around on the box longer. 
Therefore they should be ordered to give priority to either a) heavily used 
ports or b) ports you want to have processed sooner rather than later.

4. No reason for accepting specific outbound traffic: I tend to prefer 
allowing all outbound traffic and filter on those ports that shouldn't be 
going outbound (i.e. dhcp responses, dns responses, ipp packets, windows 
networking stuff, known trojan/virus ports).  It greatly reduces the number 
of checks outbound traffic needs to go through.

Obviously to improve the throughput you'd have to alter the script to use 
multiple ports on accept lines.  Once you start doing that, though, you lose 
the modularity that you've built into the script.

The point that needs to be made is that there is no 'one iptables script 
fits all'.  Each site, each box for that matter, has it's own set of 
services and it's own usage criteria.  To that end the iptables rules will 
(should) always vary from box to box, whether it is a server, a desktop, a 
gateway, or some combination of the three.

New users looking to get their boxen online grab scripts like this thinking 
they are going to secure it for them, yet they don't understand the nuances 
of the individual rules nor how they are grouped.  How many folks that grab 
the script are going to know what the teamspeak or pgp ports are for and 
whether they need them or not?  How many are going to know that they've 
exposed their system to incoming teamspeak packets, whether they have 
teamspeak or not?

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] iptables example on Gentoo

[Timo Boettcher]

Hi Dave,


* Dave Nebinger <dnebinger@joat.com>, Friday, September 9, 2005, 4:23:07 PM:

>>> Dude, trying to use iptables directly was your first mistake.
>> no, it wasn't.
>>
>> I have written some "small" example script
>> http://forums.gentoo.org/viewtopic.php?p=377447
>> that (IMO) is quite modular...

> Yes, Timo, it is quite modular and quite thorough.  It represents a great
> job at developing a general set of rules.

> But I would raise the following issues:

> 1. FTP support: You've allowed for the active ftp protocols on ports 20 &
> 21, but what about passive?  This traffic will usually be on the higher
> ports (typically a range specified in the configuration for the ftp daemon).
> I do believe that if the ftp daemon tries to open a passive connection
> outbound it's going to get knocked off at the knees.
If I open a ftp-connection from the inside to a ftp-server on the
outside, it should get caught by the iptables-ftp-module and the
RELATED rule.

> 2. Measure the checks: The more checks that a packet goes through, the
> longer it will take to travel through the iptables stack.  Your script has a
> lot of checks in it.  Consider a pgp packet as it traverses all of the
> chains etc. that you've specified.  You're probably looking at 30+ checks at
> least (although I haven't counted each individual check, but I'm confident
> it is quite a large number).  That's a significant number of hops and means
> the packet is going to be hanging around on the box a lot longer than what
> it really should.
Yes, I have MANY checks. I have had no probleems while using this and
some newer versions of this script. However this seems to bee a
problem for users that get many small packets per time-unit... (think
p2p here). As you state below, this is no universal solution, but was
built to be easily reconfigurable.

> 3. No detail on why the checks are ordered in the way they are (is there an
> order?):  As #2 indicates, the increased number of checks that a packet
> needs to be pushed through means it will hang around on the box longer.
> Therefore they should be ordered to give priority to either a) heavily used
> ports or b) ports you want to have processed sooner rather than later.
There was no reason ;-). see above

> 4. No reason for accepting specific outbound traffic: I tend to prefer
> allowing all outbound traffic and filter on those ports that shouldn't be
> going outbound (i.e. dhcp responses, dns responses, ipp packets, windows
> networking stuff, known trojan/virus ports).  It greatly reduces the number
> of checks outbound traffic needs to go through.
I filter outbound for various reasons: generally, I like to know what
happens on my internal network. You can catch misconfigured software
some malware and some bad users with that.

> Obviously to improve the throughput you'd have to alter the script to use
> multiple ports on accept lines.  Once you start doing that, though, you lose
> the modularity that you've built into the script.
You are probably right in that.

> The point that needs to be made is that there is no 'one iptables script
> fits all'.  Each site, each box for that matter, has it's own set of
> services and it's own usage criteria.  To that end the iptables rules will
> (should) always vary from box to box, whether it is a server, a desktop, a
> gateway, or some combination of the three.
Of course.

> New users looking to get their boxen online grab scripts like this thinking
> they are going to secure it for them, yet they don't understand the nuances
> of the individual rules nor how they are grouped.  How many folks that grab
> the script are going to know what the teamspeak or pgp ports are for and
> whether they need them or not?  How many are going to know that they've
> exposed their system to incoming teamspeak packets, whether they have
> teamspeak or not?
Even more: They are exposing their box to ALL packets on the teamspeak
port.
But IMO, it's easier to learn than some gui-things, you don't have to
transfer it over network to your firewall-box (who has X on a
firewall??? :-) ) and its easy to reconfigure.

Thanks for the feedback. really.


 Timo

-- 
gentoo-user@gentoo.org mailing list