iptables grep problems

iptables grep problems

[saint]

Hi all,

It seems I'm in a bit of a bother.  Here's my problem:
I have a semi-permanent IP address provided by my ISP
and I can't do one of two things:
1. use eth0, and
2. use a combination of grep, awk, & ifconfig.

Normally, if I issue this from the bash shell:

$ifconfig eth0 | grep 'inet addr' | awk '{print $2}'

I get the intended result i.e the external interface's IP address.
So why can't I get anything when I put this in the firewall script?
Actually, I do get something: ERRORS!

If someone would kindly help me with this problem
and relieve my suffering it'll be very much appreciated.

Thanks.

Santos.
Still learning.

Re: iptables grep problems

[Andre Costa]

Hi Santos,

if you're putting this into /etc/sysconfig/iptables (RH) or any other
ruleset meant to be loaded with iptables-restore, you're out of luck:
shell commands cannot be executed there.

If not, then it's most likely a shell related problem (I mean: it
shouldn't be iptable's fault); post the errors msgs here so that we can
try to help you.

Best,

Andre

On 04 Feb 2003 00:14:11 +1100
saint <nagajuna@optushome.com.au> wrote:

> Hi all,
> 
> It seems I'm in a bit of a bother.  Here's my problem:
> I have a semi-permanent IP address provided by my ISP
> and I can't do one of two things:
> 1. use eth0, and
> 2. use a combination of grep, awk, & ifconfig.
> 
> Normally, if I issue this from the bash shell:
> 
> $ifconfig eth0 | grep 'inet addr' | awk '{print $2}'
> 
> I get the intended result i.e the external interface's IP address.
> So why can't I get anything when I put this in the firewall script?
> Actually, I do get something: ERRORS!
> 
> If someone would kindly help me with this problem
> and relieve my suffering it'll be very much appreciated.
> 
> Thanks.
> 
> Santos.
> Still learning.
> 
> 


-- 
Andre Oliveira da Costa

Consequences

[saint]

There have been a number of problems that I have but I believed
it had nothing to do with syntax errors or any missing rules on 
my behalf.
I'll have to sit back and study these problems taking into
consideration you recommendations ( and Ken's).
How far reaching I not sure yet but I will say that I have conflicting
chains-> different userdefined chains, default policy of DROP
(INPUT/OUTPUT/FORWARD/POST-PRE ROUTING/ MANGLE ) drops everything
as expected and remains dropping everthing eventhough I have the service
exlicitly and carefully enabled are just some of these problems.

I don't know what's causing them because, as I have indicated, syntax &
everthing else is fine.  Ofcourse because I don't know I'm looking for a
possible scapegoat and initialisation + ifconfig stuff is one thing I
haven't comes to terms with yet -> so hence my suspicion that other
things could've been affected by this.

Let you know though when I figure it out.  Personally I want to finish
it before my summer break -> then its back to uni.

Santos


On Tue, 2003-02-04 at 02:09, Andre Costa wrote:
> You're welcome, Santos, I am glad I could be of help =)
> 
> I am curious: what kind of "far-reaching consequences"? Could you
> please ellaborate?
> 
> Happy firewalling ;)
> 
> Andre
> 
> On 04 Feb 2003 01:58:35 +1100
> saint <nagajuna@optushome.com.au> wrote:
> 
> > I think I get it and I think you've just solve a nagging
> > problem that I have.  I have wrote my own script, took me awhile
> > though.
> > 
> > And I think it does have (have been) some far-reaching consequences.
> > 
> > Thanks again.
> > 
> > 
> > On Tue, 2003-02-04 at 01:44, Andre Costa wrote:
> > > Hi Santos,
> > > 
> > > there has been a discussion about this a while ago on this ML, I am
> > > forwarding you the msg which has a nice proposal to solve this.
> > > Basically it involves:
> > > 
> > > * writing your own fw script (e.g. your rc.firewall)
> > > 
> > > * put a symlink to it on /etc/init.d *BEFORE* the iptables link
> > > there, so that your script is called first (this means prepeding the
> > > symlink name with a 'S-number' lower than the one associated to
> > > iptables startup script)
> > > 
> > > Please notice that you might have to remove the initialization part
> > > of/etc/sysconfig/iptables and put it at the beginning of your
> > > rc.firewall script, otherwise iptables-restore might choke or you
> > > might even undo what you have done on rc.firewall (these are wild
> > > guesses, make sure you test it properly). I am talking about all
> > > rules like
> > > 
> > > *filter
> > > :FORWARD DROP [0:0]
> > > :INPUT DROP [0:0]
> > > :OUTPUT ACCEPT [0:0]
> > > 
> > > at the top of /etc/sysconfig/iptables
> > > 
> > > HTH
> > > 
> > > Andre
> > > 
> > > On 04 Feb 2003 01:16:37 +1100
> > > saint <nagajuna@optushome.com.au> wrote:
> > > 
> > > > Thank Andre:  that's makes sense. So what on Earth do I do
> > > > when my firewall reboots and I can't be sure of the IP address?
> > > > Could I put the rc.firewall script in /etc/rc.d/ ? and have run at
> > > > boot time from /etc/init.d/ ? 
> > > > I'm using SuSE 8.1 and I can actually put a line in
> > > > /etc/init.d/boot.local that will execute my rc.firewall.
> > > > 
> > > > Santo.
> > > > Happy to learn.
> > 
> 

RE: Consequences

[Darrell Dieringer]

Hello,

It has been quite awhile since I first set up my rules, so be advised
that my suggestions may be a bit off (and subject to correction by
others, of course)...

As a general rule, you should not do any packet filtering in
PREROUTING / POSTROUTING / MANGLE.  Those chains are for things like
SNAT / DNAT and a variety of other manipulations.  You should only be
dropping traffic in INPUT / OUTPUT / FORWARD (and your user-defined
filter table chains).

I remember having the same problem as you, and I'm pretty sure it was
because I originally tried to use a default DROP policy on
PRE/POSTROUTING & MANGLE.  Unless you duplicate all of your INPUT /
FORWARD rules in PREROUTING, the incoming traffic you wish to permit
will match the default DROP policy there (and subsequently die) before
it ever gets to the filter table.  Same is true for your OUTPUT rules.

I hope this helped.

If you post your rules, I'm sure someone will advise you of the
precise problem.

Darrell Dieringer - Madison, WI

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of saint
> Sent: Monday, February 03, 2003 9:51 AM
> To: Andre Costa; Netfilter Mailing List
> Subject: Consequences
>
>
> There have been a number of problems that I have but I believed
> it had nothing to do with syntax errors or any missing rules on
> my behalf.
> I'll have to sit back and study these problems taking into
> consideration you recommendations ( and Ken's).
> How far reaching I not sure yet but I will say that I have
> conflicting
> chains-> different userdefined chains, default policy of DROP
> (INPUT/OUTPUT/FORWARD/POST-PRE ROUTING/ MANGLE ) drops everything
> as expected and remains dropping everthing eventhough I
> have the service
> exlicitly and carefully enabled are just some of these problems.
>
> I don't know what's causing them because, as I have
> indicated, syntax &
> everthing else is fine.  Ofcourse because I don't know I'm
> looking for a
> possible scapegoat and initialisation + ifconfig stuff is
> one thing I
> haven't comes to terms with yet -> so hence my suspicion that other
> things could've been affected by this.
>
> Let you know though when I figure it out.  Personally I
> want to finish
> it before my summer break -> then its back to uni.
>
> Santos
>
>
> On Tue, 2003-02-04 at 02:09, Andre Costa wrote:
> > You're welcome, Santos, I am glad I could be of help =)
> >
> > I am curious: what kind of "far-reaching consequences"? Could you
> > please ellaborate?
> >
> > Happy firewalling ;)
> >
> > Andre
> >
> > On 04 Feb 2003 01:58:35 +1100
> > saint <nagajuna@optushome.com.au> wrote:
> >
> > > I think I get it and I think you've just solve a nagging
> > > problem that I have.  I have wrote my own script, took me awhile
> > > though.
> > >
> > > And I think it does have (have been) some far-reaching
> consequences.
> > >
> > > Thanks again.
> > >
> > >
> > > On Tue, 2003-02-04 at 01:44, Andre Costa wrote:
> > > > Hi Santos,
> > > >
> > > > there has been a discussion about this a while ago on
> this ML, I am
> > > > forwarding you the msg which has a nice proposal to
> solve this.
> > > > Basically it involves:
> > > >
> > > > * writing your own fw script (e.g. your rc.firewall)
> > > >
> > > > * put a symlink to it on /etc/init.d *BEFORE* the
> iptables link
> > > > there, so that your script is called first (this
> means prepeding the
> > > > symlink name with a 'S-number' lower than the one
> associated to
> > > > iptables startup script)
> > > >
> > > > Please notice that you might have to remove the
> initialization part
> > > > of/etc/sysconfig/iptables and put it at the beginning of your
> > > > rc.firewall script, otherwise iptables-restore might
> choke or you
> > > > might even undo what you have done on rc.firewall
> (these are wild
> > > > guesses, make sure you test it properly). I am
> talking about all
> > > > rules like
> > > >
> > > > *filter
> > > > :FORWARD DROP [0:0]
> > > > :INPUT DROP [0:0]
> > > > :OUTPUT ACCEPT [0:0]
> > > >
> > > > at the top of /etc/sysconfig/iptables
> > > >
> > > > HTH
> > > >
> > > > Andre
> > > >
> > > > On 04 Feb 2003 01:16:37 +1100
> > > > saint <nagajuna@optushome.com.au> wrote:
> > > >
> > > > > Thank Andre:  that's makes sense. So what on Earth do I do
> > > > > when my firewall reboots and I can't be sure of the
> IP address?
> > > > > Could I put the rc.firewall script in /etc/rc.d/ ?
> and have run at
> > > > > boot time from /etc/init.d/ ?
> > > > > I'm using SuSE 8.1 and I can actually put a line in
> > > > > /etc/init.d/boot.local that will execute my rc.firewall.
> > > > >
> > > > > Santo.
> > > > > Happy to learn.
> > >
> >
>
>
>

Re: Consequences

[Joel Newkirk]

On Monday 03 February 2003 10:50 am, saint wrote:
> There have been a number of problems that I have but I believed
> it had nothing to do with syntax errors or any missing rules on
> my behalf.
> I'll have to sit back and study these problems taking into
> consideration you recommendations ( and Ken's).
> How far reaching I not sure yet but I will say that I have conflicting
> chains-> different userdefined chains, default policy of DROP
> (INPUT/OUTPUT/FORWARD/POST-PRE ROUTING/ MANGLE ) drops everything
> as expected and remains dropping everthing eventhough I have the
> service exlicitly and carefully enabled are just some of these
> problems.

You should almost never have anything but ACCEPT policy on any mangle or 
nat table chains.  Only filter-INPUT, filter-OUTPUT and  filter-FORWARD 
chains should ever have policy settings other than ACCEPT.

The number one cause of problems such as the errors you reported is that 
during startup the paths are NOT those you use in a console. 
Specifically, you will usually need to explicitly use /sbin/ifconfig.

 If you use the SysV Init (/etc/init.d, /etc/rc5.d, etc) system to start 
your firewall, which is probably what you want, you have to make sure 
that your startups occur in a reasonable order, based on the Sxx 
prefixes. You have to ensure that the iptables startup and the 
activation of your external interface both take place before your 
script.  Put your script in init.d and a link to it in rc3.d and/or 
rc5.d named Sxx.firewall, where 'xx' is greater than 'xx' for iptables 
and the script that brings up your interface (probably network). For my 
system, I have iptables->network->ADSL->firewall. (I've always had 
problems getting the ADSL interface up in the regular network startup, 
so I added it's own startup script)  I have also modified the iptables 
startup script to set default DROP policies for INPUT/OUTPUT/FORWARD, 
where originally (RedHat) they were ACCEPT.

When I tried your ip-extraction command I got "addr:141.150.238.220" (my 
dyn-ip for the last few days, since 10am Jan 29 actually) which would 
not be a valid string to use in a rule.  In my script (I have a 
semi-dynamic IP on a PPPoE connection) I successfully use:
PPPIP=      \
$(/sbin/ifconfig "$EXTIF" | grep inet | cut -d":" -f 2 | cut -d" " -f 1)

where I have $EXTIF already defined as "ppp0".  I also have a cron job 
running every hour to test if the result of that command matches the IP 
in use for SNAT, and replaces the SNAT rule if necessary.  (Yes, I could 
use MASQUERADE but don't want to, and I track IP changes for other 
purposes as well.)

j

> I don't know what's causing them because, as I have indicated, syntax
> & everthing else is fine.  Ofcourse because I don't know I'm looking
> for a possible scapegoat and initialisation + ifconfig stuff is one
> thing I haven't comes to terms with yet -> so hence my suspicion that
> other things could've been affected by this.
>
> Let you know though when I figure it out.  Personally I want to finish
> it before my summer break -> then its back to uni.
>
> Santos
>
> On Tue, 2003-02-04 at 02:09, Andre Costa wrote:
> > You're welcome, Santos, I am glad I could be of help =)
> >
> > I am curious: what kind of "far-reaching consequences"? Could you
> > please ellaborate?
> >
> > Happy firewalling ;)
> >
> > Andre
> >
> > On 04 Feb 2003 01:58:35 +1100
> >
> > saint <nagajuna@optushome.com.au> wrote:
> > > I think I get it and I think you've just solve a nagging
> > > problem that I have.  I have wrote my own script, took me awhile
> > > though.
> > >
> > > And I think it does have (have been) some far-reaching
> > > consequences.
> > >
> > > Thanks again.
> > >
> > > On Tue, 2003-02-04 at 01:44, Andre Costa wrote:
> > > > Hi Santos,
> > > >
> > > > there has been a discussion about this a while ago on this ML, I
> > > > am forwarding you the msg which has a nice proposal to solve
> > > > this. Basically it involves:
> > > >
> > > > * writing your own fw script (e.g. your rc.firewall)
> > > >
> > > > * put a symlink to it on /etc/init.d *BEFORE* the iptables link
> > > > there, so that your script is called first (this means prepeding
> > > > the symlink name with a 'S-number' lower than the one associated
> > > > to iptables startup script)
> > > >
> > > > Please notice that you might have to remove the initialization
> > > > part of/etc/sysconfig/iptables and put it at the beginning of
> > > > your rc.firewall script, otherwise iptables-restore might choke
> > > > or you might even undo what you have done on rc.firewall (these
> > > > are wild guesses, make sure you test it properly). I am talking
> > > > about all rules like
> > > >
> > > > *filter
> > > >
> > > > :FORWARD DROP [0:0]
> > > > :INPUT DROP [0:0]
> > > > :OUTPUT ACCEPT [0:0]
> > > >
> > > > at the top of /etc/sysconfig/iptables
> > > >
> > > > HTH
> > > >
> > > > Andre
> > > >
> > > > On 04 Feb 2003 01:16:37 +1100
> > > >
> > > > saint <nagajuna@optushome.com.au> wrote:
> > > > > Thank Andre:  that's makes sense. So what on Earth do I do
> > > > > when my firewall reboots and I can't be sure of the IP
> > > > > address? Could I put the rc.firewall script in /etc/rc.d/ ?
> > > > > and have run at boot time from /etc/init.d/ ?
> > > > > I'm using SuSE 8.1 and I can actually put a line in
> > > > > /etc/init.d/boot.local that will execute my rc.firewall.
> > > > >
> > > > > Santo.
> > > > > Happy to learn.

Re: Consequences

[saint]

Thanks Joel: I have correctly set my paths.

On Tue, 2003-02-04 at 05:26, Joel Newkirk wrote:
> On Monday 03 February 2003 10:50 am, saint wrote:
> > There have been a number of problems that I have but I believed
> > it had nothing to do with syntax errors or any missing rules on
> > my behalf.
> > I'll have to sit back and study these problems taking into
> > consideration you recommendations ( and Ken's).
> > How far reaching I not sure yet but I will say that I have conflicting
> > chains-> different userdefined chains, default policy of DROP
> > (INPUT/OUTPUT/FORWARD/POST-PRE ROUTING/ MANGLE ) drops everything
> > as expected and remains dropping everthing eventhough I have the
> > service exlicitly and carefully enabled are just some of these
> > problems.
> 
> You should almost never have anything but ACCEPT policy on any mangle or 
> nat table chains.  Only filter-INPUT, filter-OUTPUT and  filter-FORWARD 
> chains should ever have policy settings other than ACCEPT.
> 
> The number one cause of problems such as the errors you reported is that 
> during startup the paths are NOT those you use in a console. 
> Specifically, you will usually need to explicitly use /sbin/ifconfig.
> 
>  If you use the SysV Init (/etc/init.d, /etc/rc5.d, etc) system to start 
> your firewall, which is probably what you want, you have to make sure 
> that your startups occur in a reasonable order, based on the Sxx 
> prefixes. You have to ensure that the iptables startup and the 
> activation of your external interface both take place before your 
> script.  Put your script in init.d and a link to it in rc3.d and/or 
> rc5.d named Sxx.firewall, where 'xx' is greater than 'xx' for iptables 
> and the script that brings up your interface (probably network). For my 
> system, I have iptables->network->ADSL->firewall. (I've always had 
> problems getting the ADSL interface up in the regular network startup, 
> so I added it's own startup script)  I have also modified the iptables 
> startup script to set default DROP policies for INPUT/OUTPUT/FORWARD, 
> where originally (RedHat) they were ACCEPT.
> 
> When I tried your ip-extraction command I got "addr:141.150.238.220" (my 
> dyn-ip for the last few days, since 10am Jan 29 actually) which would 
> not be a valid string to use in a rule.  In my script (I have a 
> semi-dynamic IP on a PPPoE connection) I successfully use:
> PPPIP=      \
> $(/sbin/ifconfig "$EXTIF" | grep inet | cut -d":" -f 2 | cut -d" " -f 1)
> 
> where I have $EXTIF already defined as "ppp0".  I also have a cron job 
> running every hour to test if the result of that command matches the IP 
> in use for SNAT, and replaces the SNAT rule if necessary.  (Yes, I could 
> use MASQUERADE but don't want to, and I track IP changes for other 
> purposes as well.)
> 
> j
> 
> > I don't know what's causing them because, as I have indicated, syntax
> > & everthing else is fine.  Ofcourse because I don't know I'm looking
> > for a possible scapegoat and initialisation + ifconfig stuff is one
> > thing I haven't comes to terms with yet -> so hence my suspicion that
> > other things could've been affected by this.
> >
> > Let you know though when I figure it out.  Personally I want to finish
> > it before my summer break -> then its back to uni.
> >
> > Santos
> >
> > On Tue, 2003-02-04 at 02:09, Andre Costa wrote:
> > > You're welcome, Santos, I am glad I could be of help =)
> > >
> > > I am curious: what kind of "far-reaching consequences"? Could you
> > > please ellaborate?
> > >
> > > Happy firewalling ;)
> > >
> > > Andre
> > >
> > > On 04 Feb 2003 01:58:35 +1100
> > >
> > > saint <nagajuna@optushome.com.au> wrote:
> > > > I think I get it and I think you've just solve a nagging
> > > > problem that I have.  I have wrote my own script, took me awhile
> > > > though.
> > > >
> > > > And I think it does have (have been) some far-reaching
> > > > consequences.
> > > >
> > > > Thanks again.
> > > >
> > > > On Tue, 2003-02-04 at 01:44, Andre Costa wrote:
> > > > > Hi Santos,
> > > > >
> > > > > there has been a discussion about this a while ago on this ML, I
> > > > > am forwarding you the msg which has a nice proposal to solve
> > > > > this. Basically it involves:
> > > > >
> > > > > * writing your own fw script (e.g. your rc.firewall)
> > > > >
> > > > > * put a symlink to it on /etc/init.d *BEFORE* the iptables link
> > > > > there, so that your script is called first (this means prepeding
> > > > > the symlink name with a 'S-number' lower than the one associated
> > > > > to iptables startup script)
> > > > >
> > > > > Please notice that you might have to remove the initialization
> > > > > part of/etc/sysconfig/iptables and put it at the beginning of
> > > > > your rc.firewall script, otherwise iptables-restore might choke
> > > > > or you might even undo what you have done on rc.firewall (these
> > > > > are wild guesses, make sure you test it properly). I am talking
> > > > > about all rules like
> > > > >
> > > > > *filter
> > > > >
> > > > > :FORWARD DROP [0:0]
> > > > > :INPUT DROP [0:0]
> > > > > :OUTPUT ACCEPT [0:0]
> > > > >
> > > > > at the top of /etc/sysconfig/iptables
> > > > >
> > > > > HTH
> > > > >
> > > > > Andre
> > > > >
> > > > > On 04 Feb 2003 01:16:37 +1100
> > > > >
> > > > > saint <nagajuna@optushome.com.au> wrote:
> > > > > > Thank Andre:  that's makes sense. So what on Earth do I do
> > > > > > when my firewall reboots and I can't be sure of the IP
> > > > > > address? Could I put the rc.firewall script in /etc/rc.d/ ?
> > > > > > and have run at boot time from /etc/init.d/ ?
> > > > > > I'm using SuSE 8.1 and I can actually put a line in
> > > > > > /etc/init.d/boot.local that will execute my rc.firewall.
> > > > > >
> > > > > > Santo.
> > > > > > Happy to learn.
> 
> 

RE: Consequences

[saint]

Thanks for the advice Darell:

Concerning PREROUTING/POST & MANGLE: the only rule that I have are:

# flsuh:
iptables -t nat --flush
iptables -t mangle --flush

# Policy:
iptables -t nat --policy PREROUTING DROP
iptables -t nat --policy OUTPUT DROP
iptables -t nat --policy POSTROUTING DROP
iptables -t mangle --policy PREROUTING DROP
iptables -t mnagle --policy OUTPUT DROP


Thats it.  the thing I just did (above) I learnt from reading "Linux
Firewalls" (RL Ziegler).  It said to be part of a DENY EVERYTHING by
default.  

However, I figured out AFTER going through all my rules for
INPUT/OUTPUT/FORWARD that it wasn't my rules at all, per say, that was
denying all sorts of services, like Internet access to the host & LAN,
SSD, DNS just to mention some common ones. 

What I ended up figuring out AFTER conceptually tracing
PREROUTING,POSTROUTING, etc... i.e the rules above, that if I didn't set
them to ACCEPT nothing gets anywhere in the first place.

So I set them to ACCEPT and all services were restored.  The only thing
is I worry about some packets escaping to the end of the chain and gets
accepted by default.

Everyones comments and suggestions have been helpful and I welcome more
anytime. 

Santos.
I love lively brain powered discussions.
  






On Tue, 2003-02-04 at 04:57, Darrell Dieringer wrote:
> Hello,
> 
> It has been quite awhile since I first set up my rules, so be advised
> that my suggestions may be a bit off (and subject to correction by
> others, of course)...
> 
> As a general rule, you should not do any packet filtering in
> PREROUTING / POSTROUTING / MANGLE.  Those chains are for things like
> SNAT / DNAT and a variety of other manipulations.  You should only be
> dropping traffic in INPUT / OUTPUT / FORWARD (and your user-defined
> filter table chains).
> 
> I remember having the same problem as you, and I'm pretty sure it was
> because I originally tried to use a default DROP policy on
> PRE/POSTROUTING & MANGLE.  Unless you duplicate all of your INPUT /
> FORWARD rules in PREROUTING, the incoming traffic you wish to permit
> will match the default DROP policy there (and subsequently die) before
> it ever gets to the filter table.  Same is true for your OUTPUT rules.
> 
> I hope this helped.
> 
> If you post your rules, I'm sure someone will advise you of the
> precise problem.
> 
> Darrell Dieringer - Madison, WI
> 
> > -----Original Message-----
> > From: netfilter-admin@lists.netfilter.org
> > [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of saint
> > Sent: Monday, February 03, 2003 9:51 AM
> > To: Andre Costa; Netfilter Mailing List
> > Subject: Consequences
> >
> >
> > There have been a number of problems that I have but I believed
> > it had nothing to do with syntax errors or any missing rules on
> > my behalf.
> > I'll have to sit back and study these problems taking into
> > consideration you recommendations ( and Ken's).
> > How far reaching I not sure yet but I will say that I have
> > conflicting
> > chains-> different userdefined chains, default policy of DROP
> > (INPUT/OUTPUT/FORWARD/POST-PRE ROUTING/ MANGLE ) drops everything
> > as expected and remains dropping everthing eventhough I
> > have the service
> > exlicitly and carefully enabled are just some of these problems.
> >
> > I don't know what's causing them because, as I have
> > indicated, syntax &
> > everthing else is fine.  Ofcourse because I don't know I'm
> > looking for a
> > possible scapegoat and initialisation + ifconfig stuff is
> > one thing I
> > haven't comes to terms with yet -> so hence my suspicion that other
> > things could've been affected by this.
> >
> > Let you know though when I figure it out.  Personally I
> > want to finish
> > it before my summer break -> then its back to uni.
> >
> > Santos
> >
> >
> > On Tue, 2003-02-04 at 02:09, Andre Costa wrote:
> > > You're welcome, Santos, I am glad I could be of help =)
> > >
> > > I am curious: what kind of "far-reaching consequences"? Could you
> > > please ellaborate?
> > >
> > > Happy firewalling ;)
> > >
> > > Andre
> > >
> > > On 04 Feb 2003 01:58:35 +1100
> > > saint <nagajuna@optushome.com.au> wrote:
> > >
> > > > I think I get it and I think you've just solve a nagging
> > > > problem that I have.  I have wrote my own script, took me awhile
> > > > though.
> > > >
> > > > And I think it does have (have been) some far-reaching
> > consequences.
> > > >
> > > > Thanks again.
> > > >
> > > >
> > > > On Tue, 2003-02-04 at 01:44, Andre Costa wrote:
> > > > > Hi Santos,
> > > > >
> > > > > there has been a discussion about this a while ago on
> > this ML, I am
> > > > > forwarding you the msg which has a nice proposal to
> > solve this.
> > > > > Basically it involves:
> > > > >
> > > > > * writing your own fw script (e.g. your rc.firewall)
> > > > >
> > > > > * put a symlink to it on /etc/init.d *BEFORE* the
> > iptables link
> > > > > there, so that your script is called first (this
> > means prepeding the
> > > > > symlink name with a 'S-number' lower than the one
> > associated to
> > > > > iptables startup script)
> > > > >
> > > > > Please notice that you might have to remove the
> > initialization part
> > > > > of/etc/sysconfig/iptables and put it at the beginning of your
> > > > > rc.firewall script, otherwise iptables-restore might
> > choke or you
> > > > > might even undo what you have done on rc.firewall
> > (these are wild
> > > > > guesses, make sure you test it properly). I am
> > talking about all
> > > > > rules like
> > > > >
> > > > > *filter
> > > > > :FORWARD DROP [0:0]
> > > > > :INPUT DROP [0:0]
> > > > > :OUTPUT ACCEPT [0:0]
> > > > >
> > > > > at the top of /etc/sysconfig/iptables
> > > > >
> > > > > HTH
> > > > >
> > > > > Andre
> > > > >
> > > > > On 04 Feb 2003 01:16:37 +1100
> > > > > saint <nagajuna@optushome.com.au> wrote:
> > > > >
> > > > > > Thank Andre:  that's makes sense. So what on Earth do I do
> > > > > > when my firewall reboots and I can't be sure of the
> > IP address?
> > > > > > Could I put the rc.firewall script in /etc/rc.d/ ?
> > and have run at
> > > > > > boot time from /etc/init.d/ ?
> > > > > > I'm using SuSE 8.1 and I can actually put a line in
> > > > > > /etc/init.d/boot.local that will execute my rc.firewall.
> > > > > >
> > > > > > Santo.
> > > > > > Happy to learn.
> > > >
> > >
> >
> >
> >
> 
> 

Re: Consequences

[saint]

G'day Andre.

For the past few months I have been writing my firewall from scratch. 
It was a painstaking exercise working line for line but I learnt alot. 
With my userdefine chains and the methods/rules applied on them they are
correct as far as what I wanted to achieve and syntactically sound.

I bet that using a new grep rule to capture info on eth0 and fixing the
initialisation and setting some policy to ACCEPT would solve my
problems.

At the moment I just execute the script from a virtual console and all
works as expected.  I test the netwrok with nmap and the ports that I
expected filtered are filtered.

Santos.
That's why I love number theory: it's akin to gazing at the heavens.



On Tue, 2003-02-04 at 03:45, Andre Costa wrote:
> > There have been a number of problems that I have but I believed
> > it had nothing to do with syntax errors or any missing rules on 
> > my behalf.
> 
> You can count on that. Both iptables and bash are very sensitive to
> syntax errors, you would have noticed them right away. As for missing
> rules, this is a usage error, so it won't be caught by the software, and
> it could indeed cause all kinds of trouble.
> 
> > I'll have to sit back and study these problems taking into
> > consideration you recommendations ( and Ken's).
> > How far reaching I not sure yet but I will say that I have conflicting
> > chains-> different userdefined chains, default policy of DROP
> > (INPUT/OUTPUT/FORWARD/POST-PRE ROUTING/ MANGLE ) drops everything
> > as expected and remains dropping everthing eventhough I have the
> > service exlicitly and carefully enabled are just some of these
> > problems.
> 
> I am affraid I might not be able to help you with your specific setup, I
> am far from being an iptables expert (my fw setup is very simple because
> I am just watching over my own computer -- no subnet behind me,
> therefore I have only INPUT and OUTPUT rules). However, maybe this piece
> of advice can be helpful: maybe you should start from scratch, paying
> special attention to your needs and keeping complexity to a minimum and
> essential level. Struggling to fix something I don't even understand
> anymore is something I try to avoid as hard as I can...
> 
> > I don't know what's causing them because, as I have indicated, syntax
> > & everthing else is fine.  Ofcourse because I don't know I'm looking
> > for a possible scapegoat and initialisation + ifconfig stuff is one
> > thing I haven't comes to terms with yet -> so hence my suspicion that
> > other things could've been affected by this.
> 
> As I was saying above, aside from the fact that your setup might be
> complex by nature, you might also be suffering from non-trivial, hard to
> spot side-effects, and rewriting fw rules from scratch and testing it
> incrementally (if at all possible, of course) might help you avoid these
> pitfalls.
> 
> > Let you know though when I figure it out.  Personally I want to finish
> > it before my summer break -> then its back to uni.
> 
> Please, do so, it would be valuable experience.
> 
> Good luck,
> 
> Andre