RE: Odd question with source based blocking

RE: Odd question with source based blocking

[Jason Opperisano]

> I have a brief (hopefully) question.
>
> I currently have a box that sits inline with a firewall setup similiar
> to the following
>
> FORWARD - Policy - DROP
>  * allow DNS
>  * allow DHCP
>  * all WEB
>  * allow all from 192.168.1.0/24 -> BLOCKED
>  * allow all to 192.168.1.0/24 -> BLOCKED
>
> BLOCKED
>  * Block this IP
>  * Block this other IP
>  * etc ...
>
> I've tried setting the default policy of BLOCKED to accept, however it
> doesn't seem to let traffic through that doesn't match any one of the
> 'block this IP rule'.

i'm assuming by all this you mean you have a custom chain named BLOCKED, and your rules are something along the lines of:

iptables -A FORWARD -s 192.168.1.0/24 -j BLOCKED
iptables -A FORWARD -d 192.168.1.0/24 -j BLOCKED

you cannot set the "policy" of a custom chain, policies only apply to the built-in chains; i.e., iptables -P FORWARD DROP...etc...so i'm not sure what you mean by this.

> The only catch is, I remove the 'block this IP' rules from the BLOCKED
> list, so it makes it hard to ensure an ALLOW rule remains at the
> bottom.  Any ideas on how I can do this (default allow traffic not
> hitting a rule on BLOCKED to be ALLOWED?

if a packets jumps to a custom chain, and reaches the end of it--it returns to the calling chain where it left off.  in the above example--a packet with a destination ip of 192.168.1.1 and a src ip of 1.2.3.4 would match the second rule; traverse the BLOCKED chain, and if no rule matches return to the FORWARD chain at the next rule.

without seeing the output of:

iptables -vnL && iptables -t nat -vnL && iptables -t mangle -vnL

it is very difficult to answer your question.

-j

Re: Odd question with source based blocking

[Michael Sconzo]

Hope this provides a bit more Info

On Thu, Aug 26, 2004 at 06:49:07PM -0400, Jason Opperisano wrote:
> 
> you cannot set the "policy" of a custom chain, policies only apply to the built-in chains; i.e., iptables -P FORWARD DROP...etc...so i'm not sure what you mean by this.

That would have been ideal, but I didn't think it was possible either.

> if a packets jumps to a custom chain, and reaches the end of it--it returns to the calling chain where it left off.  in the above example--a packet with a destination ip of 192.168.1.1 and a src ip of 1.2.3.4 would match the second rule; traverse the BLOCKED chain, and if no rule matches return to the FORWARD chain at the next rule.

I don't suspect there is anyway to change this, is there?

> 
> without seeing the output of:
> 
> iptables -vnL && iptables -t nat -vnL && iptables -t mangle -vnL


Chain INPUT (policy ACCEPT 27895 packets, 3015K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0          multiport ports 67,68 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0          multiport ports 53 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0          multiport ports 53 
    0     0 BLOCKED    all  --  *      *       0.0.0.0/0            192.168.0.0/16     
    0     0 BLOCKED    all  --  *      *       192.168.0.0/16       0.0.0.0/0          

Chain OUTPUT (policy ACCEPT 27999 packets, 31M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain BLOCKED (4 references)
 pkts bytes target     prot opt in     out     source               destination         
Chain PREROUTING (policy ACCEPT 512K packets, 702M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 1 packets, 74 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 


Nothing in the Mangle table, and the nat table only has enteries in it
when the blocked table does


-- 
_
_ Michael J. Sconzo
_ Computing & Information Services, Texas A&M University

The New Testament offers the basis for modern computer coding theory,
in the form of an affirmation of the binary number system.
        But let your communication be Yea, yea; nay, nay: for
        whatsoever is more than these cometh of evil.
                -- Matthew 5:37

RE: Odd question with source based blocking

[Jason Opperisano]

> Hope this provides a bit more Info
>
> On Thu, Aug 26, 2004 at 06:49:07PM -0400, Jason Opperisano wrote:
> >
> > you cannot set the "policy" of a custom chain, policies only apply to the built-in chains; i.e., iptables -P FORWARD DROP...etc...so i'm not sure what you mean by this.
>
> That would have been ideal, but I didn't think it was possible either.
>
> > if a packets jumps to a custom chain, and reaches the end of it--it returnsto the calling chain where it left off.  in the above example--a packet with a destination ip of 192.168.1.1 and a src ip of 1.2.3.4 would match the second rule; traverse the BLOCKED chain, and if no rule matches return to the FORWARD chain at the next rule.
>
> I don't suspect there is anyway to change this, is there?

yeah--make the last rule of the chain BLOCKED a DROP rule:

	iptables -A BLOCKED -j DROP

-j

RE: Change of ip addresses continues.... :(

[Jason Opperisano]

> I have been trying various set of rules in various table in order to have packets go over
> the right link. ie. packet's src add should match outgoing link's ip address.YET, there
> are some packets that always tend to go over the wrong link and thus causing ip address
> change. They mostly seem to be ICMP Destination Unreacheable messages or DNS queries.

please verify that the ICMP dest-unreach & DNS queries are not locally generated packets from the firewall machine itself.  everything you're doing thus far applies to packets being routed through the firewall; not from the firewall--that's a whole different story...

> I tried out the rules that Daniel Chemko so generously had provided me with...and they
> don't seem to work. I am probably not doing something right. I just tried thefollowing
> rules with no luck:
>
> iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
> iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT
> iptables -t mangle -A PREROUTING -m mark ! --mark 0 -p icmp -j MARK --set-mark 1
> iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j MARK --set-mark 2
> iptables -t mangle -A PREROUTING -j CONNMARK --save-mark
> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
> ptables -t nat -A POSTROUTING -o ppp1 -j MASQUERADE
>
> Are these rules supposed to create 2 routing tables???? If they do, I don't seem them?
> This is what I see:
>
> [ ]# ip rule list
> 0:      from all lookup local
> 32766:  from all lookup main
> 32767:  from all lookup 253

no--iptables commands do not create extra routing tables--you have to do this yourself.  hopefully, you've been studying up on http://lartc.org/howto/index.html (specifically http://lartc.org/howto/lartc.netfilter.html)

something like:

  echo 500 icmp >> /etc/iproute2/rt_tables
  ip rule add fwmark 1 table icmp
  ip route add default via $ICMP_LINK dev $ICMP_LINK_IF table icmp

will make the packets marked with "--set-mark 1" (icmp packets in your example), get their default gateway from the alternate routing table named "icmp"

again--this applies to packets being routed through the gateway, not to packets coming from the gateway.

-j

RE: Change of ip addresses continues.... :(

[Eric Leblond]

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

On Thu, 2004-08-26 at 23:26, Jason Opperisano wrote:
> > I have been trying various set of rules in various table in order to have packets go over
> > the right link. ie. packet's src add should match outgoing link's ip address.YET, there
> > iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
> > iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT
> > iptables -t mangle -A PREROUTING -m mark ! --mark 0 -p icmp -j MARK --set-mark 1
> > iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j MARK --set-mark 2

There's something weird here : 
-m mark ! --mark 0 
at each line you should better do 
-m mark --mark 0
at the two last lines.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

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

Odd question with source based blocking

[Michael Sconzo]

I have a brief (hopefully) question.

I currently have a box that sits inline with a firewall setup similiar
to the following

FORWARD - Policy - DROP
 * allow DNS
 * allow DHCP
 * all WEB
 * allow all from 192.168.1.0/24 -> BLOCKED
 * allow all to 192.168.1.0/24 -> BLOCKED

BLOCKED
 * Block this IP
 * Block this other IP
 * etc ...

I've tried setting the default policy of BLOCKED to accept, however it
doesn't seem to let traffic through that doesn't match any one of the
'block this IP rule'.

The only catch is, I remove the 'block this IP' rules from the BLOCKED
list, so it makes it hard to ensure an ALLOW rule remains at the
bottom.  Any ideas on how I can do this (default allow traffic not
hitting a rule on BLOCKED to be ALLOWED?

Thanks!
-=Mike

-- 
_
_ Michael J. Sconzo
_ Computing & Information Services, Texas A&M University

The New Testament offers the basis for modern computer coding theory,
in the form of an affirmation of the binary number system.
        But let your communication be Yea, yea; nay, nay: for
        whatsoever is more than these cometh of evil.
                -- Matthew 5:37