ipchains: simple advice needed

ipchains: simple advice needed

Post by mysel » Mon, 05 Feb 2001 04:57:55



I'm using Ziegler's pre-fab firewall, seems solid, but I've got a "deny"
problem. One of his rules is:

ipchains -A input   -s 65.0.0.0/8 -j DENY -l

in the "potentially spoofed packets" section, but the problem is this
denies access to certain roadrunner packets, e.g:

input DENY eth0 PROTO=6 65.32.1.161:80 24.xxx.xx.xxx:1147
input DENY eth0 PROTO=1 65.32.1.161:0 24.xxx.xx.xxx:0

trying to connect to home.tampabay.rr.com, and

input DENY eth0 PROTO=1 65.32.2.34:0 24.xxx.xx.xxx:0

trying to ping atl.mediaone.net. Output is OK on both of above.

I'd like to open it up enough to allow proper input from rr
(65.32.0.0/16-??), but not sure of good rule(s) to accoplish this,
particularly wrt ports. Already had to move POP & SMTP rules higher in
rule heirarchy to connect (65.32.2.34 & 33), so a simpler solution might
help with the clutter? Mail rules are:

# POP client (110)
    # ----------------
    ipchains -A output -i $EXTERNAL_INTERFACE -p tcp  \
             -s $IPADDR $UNPRIVPORTS \
             -d $POP_SERVER 110 -j ACCEPT

    ipchains -A input  -i $EXTERNAL_INTERFACE -p tcp ! -y \
             -s $POP_SERVER 110 \
             -d $IPADDR $UNPRIVPORTS -j ACCEPT

    # ------------------------------------------------------------------

    # SMTP client (25)
    # ----------------
    ipchains -A output -i $EXTERNAL_INTERFACE -p tcp  \
             -s $IPADDR $UNPRIVPORTS \
             -d $SMTP_SERVER 25 -j ACCEPT

    ipchains -A input  -i $EXTERNAL_INTERFACE -p tcp ! -y \
             -s $SMTP_SERVER 25 \
             -d $IPADDR $UNPRIVPORTS -j ACCEPT

I suppose I'm being lazy, but right now I'm tired of struggling with
every little config detail in linux, and would kinda like to move on.

TIA

 
 
 

ipchains: simple advice needed

Post by Davi » Mon, 05 Feb 2001 05:29:22



> I'm using Ziegler's pre-fab firewall, seems solid, but I've got a "deny"
> problem. One of his rules is:

> ipchains -A input   -s 65.0.0.0/8 -j DENY -l

> in the "potentially spoofed packets" section, but the problem is this
> denies access to certain roadrunner packets, e.g:

> input DENY eth0 PROTO=6 65.32.1.161:80 24.xxx.xx.xxx:1147
> input DENY eth0 PROTO=1 65.32.1.161:0 24.xxx.xx.xxx:0

> trying to connect to home.tampabay.rr.com, and

> input DENY eth0 PROTO=1 65.32.2.34:0 24.xxx.xx.xxx:0

> trying to ping atl.mediaone.net. Output is OK on both of above.

> I'd like to open it up enough to allow proper input from rr
> (65.32.0.0/16-??), but not sure of good rule(s) to accoplish this,
> particularly wrt ports. Already had to move POP & SMTP rules higher in
> rule heirarchy to connect (65.32.2.34 & 33), so a simpler solution might
> help with the clutter? Mail rules are:

# Refuse addresses defined as reserved by the IANA.
# Note:  this list includes the loopback, multicast, & reserved
addresses.

# 0.*.*.*           - Can't be blocked for DHCP users.

--
Confucius say: He who play in root, eventually kill tree.
Registered with the Linux Counter.  http://counter.li.org
ID # 123538
Completed more W/U's than 99.036% of seti users. +/- 0.01%

 
 
 

ipchains: simple advice needed

Post by Tim Hayne » Mon, 05 Feb 2001 05:30:27



> I'm using Ziegler's pre-fab firewall, seems solid, but I've got a "deny"
> problem. One of his rules is:

> ipchains -A input   -s 65.0.0.0/8 -j DENY -l

> in the "potentially spoofed packets" section, but the problem is this
> denies access to certain roadrunner packets, e.g:

> input DENY eth0 PROTO=6 65.32.1.161:80 24.xxx.xx.xxx:1147
> input DENY eth0 PROTO=1 65.32.1.161:0 24.xxx.xx.xxx:0

> trying to connect to home.tampabay.rr.com, and


This is the problem with putting in too many of these anti-spoofing lines.
Sure, when Zeigler penned the original, all the IP ranges used were illegal
on the 'Net. That doesn't mean they'll stay that way, and using them does
mean you'll have to keep a track on them all.

Quote:> input DENY eth0 PROTO=1 65.32.2.34:0 24.xxx.xx.xxx:0

> trying to ping atl.mediaone.net. Output is OK on both of above.

> I'd like to open it up enough to allow proper input from rr
> (65.32.0.0/16-??), but not sure of good rule(s) to accoplish this,
> particularly wrt ports.

ipchains -I input -s 65.32/16 -j ACCEPT

just after your other anti-spoofing lines (eg for 10/8, 192.168/16 and
172.16/12) and before the thing that blocks 65/8.

Or you should just remove the 65/8 block altogether, of course.

~Tim
--

And beauty is free / We can still walk          |http://piglet.is.dreaming.org
Through the garden / Our earth was once green   |

 
 
 

ipchains: simple advice needed

Post by Rick Matthe » Mon, 05 Feb 2001 14:20:59



>in the "potentially spoofed packets" section, but the problem is this
>denies access to certain roadrunner packets, e.g:

That's the section that resembles this:

    # Refuse addresses defined as reserved by the IANA.
    # Note:  this list includes the loopback addresses.

    ipchains -A input   -s 1.0.0.0/7 -j DENY -l
    ipchains -A input   -s 2.0.0.0/8 -j DENY -l
    ...

You can keep that section up to date by ocassionally reviewing this
file:

http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space

The only blocks that should be listed in your firewall are the ones
with the comment: IANA - Reserved.

Looking at the file, you'll find that 65.0.0.0/8 is no longer reserved
and was assigned in July of 2000:

...
060/8     IANA - Reserved                       Sep 81
061/8     APNIC - Pacific Rim           Apr 97
062/8     RIPE NCC - Europe             Apr 97
063/8     ARIN                                  Apr 97
064/8     ARIN                                  Jul 99
065/8     ARIN                                  Jul 00
066/8     ARIN                                  Jul 00
067-095/8       IANA - Reserved                 Sep 81
...

Rick Matthews

--
Thought for the day:
<http://mysite.directlink.net/matthews/smiles/started.htm>

 
 
 

ipchains: simple advice needed

Post by Manfred Bart » Mon, 05 Feb 2001 15:20:42



> I'm using Ziegler's pre-fab firewall, seems solid, but I've got a "deny"
> problem. One of his rules is:

> ipchains -A input   -s 65.0.0.0/8 -j DENY -l

Groan...  We've had that discussion before.  :(

There is nothing to be gained by blocking public address ranges that
are not yet allocated.  As you found out new address spaces are being
allocated.  If you value your sanity don't bother trying to keep up
with that.

Fundamental fact:
    You don't control the source address of incoming packets.

Someone who wants to spoof source addresses would pick addresses
by one of these criteria:

1. similar to their real address (same subnet) to make tracing back
   difficult.  This is relatively common and poses no additional
   threat to you.

2. private address spaces which you are likely to use in your LAN
   and may have forgotten to block in your firewall.  Because these
   addresses are not publicly routable, this only works if they are
   on the same subnet as you (same ISP).
   It is important that you address this point.

3. addresses of sites which you are not likely to have blocked.  
   This includes the most popular sites on the net and any other
   addresses that you are likely to give privileges to.

You should also check that packets are actually addressed
*to* your Internet IP address before you accept them:

 ipchains -A input -i eth1 -d ! YourIpAddr/32 -j DENY -l

Any rules allowing DHCP must be before above rule.

--
Manfred
---------------------------------------------------------------
ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>

 
 
 

ipchains: simple advice needed

Post by mysel » Wed, 07 Feb 2001 00:15:29





>>in the "potentially spoofed packets" section, but the problem is this
>>denies access to certain roadrunner packets, e.g:

> That's the section that resembles this:

>     # Refuse addresses defined as reserved by the IANA.
>     # Note:  this list includes the loopback addresses.

>     ipchains -A input   -s 1.0.0.0/7 -j DENY -l ipchains -A input   -s
>     2.0.0.0/8 -j DENY -l
>     ...

> You can keep that section up to date by ocassionally reviewing this
> file:

> http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space

Thanks. Above URL now in bookmarks | internet | security for future
reference...

- Show quoted text -

Quote:> The only blocks that should be listed in your firewall are the ones
> with the comment: IANA - Reserved.

> Looking at the file, you'll find that 65.0.0.0/8 is no longer reserved
> and was assigned in July of 2000:

> ...
> 060/8     IANA - Reserved                  Sep 81
> 061/8     APNIC - Pacific Rim              Apr 97
> 062/8     RIPE NCC - Europe                Apr 97
> 063/8     ARIN                                     Apr 97
> 064/8     ARIN                                     Jul 99
> 065/8     ARIN                                     Jul 00
> 066/8     ARIN                                     Jul 00
> 067-095/8  IANA - Reserved                 Sep 81
> ...

> Rick Matthews

 
 
 

ipchains: simple advice needed

Post by mysel » Wed, 07 Feb 2001 00:24:43





>> I'm using Ziegler's pre-fab firewall, seems solid, but I've got a
>> "deny" problem. One of his rules is:

>> ipchains -A input   -s 65.0.0.0/8 -j DENY -l

>> in the "potentially spoofed packets" section, but the problem is this
>> denies access to certain roadrunner packets, e.g:

>> input DENY eth0 PROTO=6 65.32.1.161:80 24.xxx.xx.xxx:1147 input DENY
>> eth0 PROTO=1 65.32.1.161:0 24.xxx.xx.xxx:0

>> trying to connect to home.tampabay.rr.com, and

> 65/8 must've come off the IANA-reserved list recently, I think.
> Actually,

> This is the problem with putting in too many of these anti-spoofing
> lines. Sure, when Zeigler penned the original, all the IP ranges used
> were illegal on the 'Net. That doesn't mean they'll stay that way, and
> using them does mean you'll have to keep a track on them all.

>> input DENY eth0 PROTO=1 65.32.2.34:0 24.xxx.xx.xxx:0

>> trying to ping atl.mediaone.net. Output is OK on both of above.

>> I'd like to open it up enough to allow proper input from rr
>> (65.32.0.0/16-??), but not sure of good rule(s) to accoplish this,
>> particularly wrt ports.

> ipchains -I input -s 65.32/16 -j ACCEPT

> just after your other anti-spoofing lines (eg for 10/8, 192.168/16 and
> 172.16/12) and before the thing that blocks 65/8.

> Or you should just remove the 65/8 block altogether, of course.

Looks like this is what I'll do, as per your and other's suggestions.
Just wanted to make sure I'm not opening up too much- Thanks.

- Show quoted text -

Quote:> ~Tim

 
 
 

ipchains: simple advice needed

Post by mysel » Wed, 07 Feb 2001 01:03:37





>> I'm using Ziegler's pre-fab firewall, seems solid, but I've got a
>> "deny" problem. One of his rules is:

>> ipchains -A input   -s 65.0.0.0/8 -j DENY -l

> Groan...  We've had that discussion before.  :(

Yikes! didn't mean to cause you pain... but you must have high tolerance
to post such an informative reply. Thanks- article saved
~/docs/security...

Quote:> There is nothing to be gained by blocking public address ranges that are
> not yet allocated.  As you found out new address spaces are being
> allocated.  If you value your sanity don't bother trying to keep up with
> that.

> Fundamental fact:
>     You don't control the source address of incoming packets.

> Someone who wants to spoof source addresses would pick addresses by one
> of these criteria:

> 1. similar to their real address (same subnet) to make tracing back
>    difficult.  This is relatively common and poses no additional threat
>    to you.

> 2. private address spaces which you are likely to use in your LAN
>    and may have forgotten to block in your firewall.  Because these
>    addresses are not publicly routable, this only works if they are  on
>    the same subnet as you (same ISP). It is important that you address
>    this point.

> 3. addresses of sites which you are not likely to have blocked.  
>    This includes the most popular sites on the net and any other
>    addresses that you are likely to give privileges to.

> You should also check that packets are actually addressed
> *to* your Internet IP address before you accept them:

>  ipchains -A input -i eth1 -d ! YourIpAddr/32 -j DENY -l

just so I'm clear- this would deny any packet not specifically addressed
to me? It seems like a good catch-all, I'm surprised I don't have a
similar rule, although a deny-all policy and then dozens of specific
accept rules might do the trick?? I think I'll throw this one in below my
dhcp section as you suggest...

- Show quoted text -

Quote:> Any rules allowing DHCP must be before above rule.

 
 
 

ipchains: simple advice needed

Post by mysel » Wed, 07 Feb 2001 01:08:14





>> I'm using Ziegler's pre-fab firewall, seems solid, but I've got a
>> "deny" problem. One of his rules is:

>> ipchains -A input   -s 65.0.0.0/8 -j DENY -l

>> in the "potentially spoofed packets" section, but the problem is this
>> denies access to certain roadrunner packets, e.g:

>> input DENY eth0 PROTO=6 65.32.1.161:80 24.xxx.xx.xxx:1147 input DENY
>> eth0 PROTO=1 65.32.1.161:0 24.xxx.xx.xxx:0

>> trying to connect to home.tampabay.rr.com, and

>> input DENY eth0 PROTO=1 65.32.2.34:0 24.xxx.xx.xxx:0

>> trying to ping atl.mediaone.net. Output is OK on both of above.

>> I'd like to open it up enough to allow proper input from rr
>> (65.32.0.0/16-??), but not sure of good rule(s) to accoplish this,
>> particularly wrt ports. Already had to move POP & SMTP rules higher in
>> rule heirarchy to connect (65.32.2.34 & 33), so a simpler solution
>> might help with the clutter? Mail rules are:

> # Refuse addresses defined as reserved by the IANA.
> # Note:  this list includes the loopback, multicast, & reserved
> addresses.

> # 0.*.*.*           - Can't be blocked for DHCP users.

Being the first reply in this thread, I thought it somewhat koan-like.
Reading other replies it now makes a little sense <g>.
 
 
 

ipchains: simple advice needed

Post by Manfred Bart » Wed, 07 Feb 2001 04:44:13





> > You should also check that packets are actually addressed
> > *to* your Internet IP address before you accept them:

> >  ipchains -A input -i eth1 -d ! YourIpAddr/32 -j DENY -l

> just so I'm clear- this would deny any packet not specifically
> addressed to me?

Yes.

Quote:> It seems like a good catch-all, I'm surprised I don't have a similar
> rule, although a deny-all policy and then dozens of specific accept
> rules might do the trick?? I think I'll throw this one in below my
> dhcp section as you suggest...

While you are at it you might also want to throw in a rule blocking
packets purporting to come from yourself:

    ipchains -A input -i eth1 -s YourIpAddr/32 -j DENY -l

This assumes eth1 is your Internet interface.

--
Manfred
---------------------------------------------------------------
ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>

 
 
 

ipchains: simple advice needed

Post by mysel » Wed, 07 Feb 2001 08:11:38







>> > You should also check that packets are actually addressed
>> > *to* your Internet IP address before you accept them:

>> >  ipchains -A input -i eth1 -d ! YourIpAddr/32 -j DENY -l

>> just so I'm clear- this would deny any packet not specifically
>> addressed to me?

> Yes.

>> It seems like a good catch-all, I'm surprised I don't have a similar
>> rule, although a deny-all policy and then dozens of specific accept
>> rules might do the trick?? I think I'll throw this one in below my dhcp
>> section as you suggest...

> While you are at it you might also want to throw in a rule blocking
> packets purporting to come from yourself:

>     ipchains -A input -i eth1 -s YourIpAddr/32 -j DENY -l

Yup, got that one covered.

Quote:> This assumes eth1 is your Internet interface.

To be sure. I appreciate your not assuming too much lnowledge on my part;
rest assured I'm adapting suggestions to conform w/ my config! Thanks
again.
 
 
 

1. Moving to iptables from ipchains - need advice

For some time I was running ipchains on a RedHat box (7.2, now 7.3) but it
always had problems.  Although I seemed to have configured ipchains
correctly to act as a NAT, client PC's would stop downloading web pages
before they were complete.  I goggle'd for the problem, and eventually found
a forum post stating that this was a bug in ipchains, and was never going to
be fixed.  So I installed the Dante socks daemon and forgot about ipchains'
web problems.

Unfortunately, a problem with RealPlayer sparked my decision to finally fix
it, by switching to iptables.  After figuring out how to stop ipchains from
starting, so that iptables would start instead, I got a quick 'n' unsafe
iptables config running thanks to the iptables howto.  Wheee, thought I, it
works.  Web pages loaded perfectly sans Dante.

I eventually came up with the following script, based on my knowledge of
ipchains.  However, reading through a few of the iptables howto's it looks
like this may be inadequate.  I'd be grateful if somebody could let me know
what I've missed.

Thanks,
Mark Lord.

#!/bin/sh
IPTABLES="/sbin/iptables"

# Reset default policies...
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT

# Flush all chains
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F

# Remove all custom chains
$IPTABLES -X
$IPTABLES -t nat -X
$IPTABLES -t mangle -X

# Enable masquerade
$IPTABLES -t nat -A POSTROUTING -j MASQUERADE

# Ensure ACCEPT policy
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

# eth0 is trusted (internal network)
$IPTABLES -A INPUT -i eth0 -j ACCEPT
$IPTABLES -A FORWARD -i eth0 -j ACCEPT
$IPTABLES -A OUTPUT -o eth0 -j ACCEPT

# Give lo free reign
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A FORWARD -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

# Explicitly allow icmp through eth1 (cable modem)
$IPTABLES -A INPUT -p icmp -i eth1 -j ACCEPT

# Drop any input to port <= 1024
$IPTABLES -A INPUT -i eth1 -p tcp --dport 0:1024 -j DROP

# Allow any output through eth1 (cable modem)
$IPTABLES -A OUTPUT -o eth1 -j ACCEPT

# Accept forwarding to/from 192.168.0.0/16
$IPTABLES -A FORWARD -s 192.168.0.0/16 -j ACCEPT
$IPTABLES -A FORWARD -d 192.168.0.0/16 -j ACCEPT

# Drop any other forward requests
$IPTABLES -A FORWARD -j DROP

2. direct cable linux<-->win95?(newbe)

3. Simple Example needed: Opening ftp in ipchains

4. group for Darwin

5. need ipchains example for simple network

6. quickres

7. Simple situation, need advice

8. Help

9. In need of simple advice

10. need simple repair advice for Sun (Apple) LaserWriter Plus

11. I Need Advice On Simple Home Network, Please Help

12. Need Simple advice for mail/news setup

13. simple ipchains question