Ray =>
Thank you, for your participation.
Ray Olszewski wrote:
>
> Your report is a bit fragmentary, but even so, the input- and output-chain
> rules you propose look like they should work. (I'm not sure about the
> forward-chain rules because I'm a bit fuzzy on whether and when NAT changes
> the apparent source address).
That is why I did not go into more detail first. I am thinking that I
am missing something very simple, very profound ;>
> But as you know, evaluating rules on a standalone basis doesn't work;
> packets traverse each chain and get handled by the FIRST matching rule, not
> the most specific one. And although you are inserting these rules, you
> don't specify a place in the chain, so they go at the end. My first
> thought, then, is that the offending packets never reach these rules,
> instead being passed by some eariler rule in each chain. The simplest test
> for this hypothesis would be to change the "-I" parts to "-I 1", so each
> candidate rule is the first rule in its chain, not its last.
OK, look here:
<http://www.helices.org/tmP/mcaI/1214.txt>
Since there are several rules involved, I have not tried the '-I 1' yet;
but, looking at these chains, I do not see the necessity.
> Based on the goals you list, I'd try using the input chain to block the
> outgoing 1214 connection and the output chain to block the incoming ones
> (though I'm not exactly clear on how any incoming ones might get in, given
> that the LAN is NAT'd -- you'd need to port forward incoming connections to
> port 1214, no? -- and your "evidence of the failure" only lists outgoing
> connections).
Yes, there is partial success. Clearly, I have successfully blocked
both incoming tcp 1214 and udp 1214 at wan1 -- however, once I find the
all-or-nothing solution, then I want to back off of wan1 and block these
only at eth0 and only for specific subnets attached thereto.
The above link demonstrates my usage of forward, input and output chains
-- yet, internal systems continue to connect to remote tcp 1214 !?!?
What do you think?
> At 10:30 AM 6/15/02 -0500, Michael D. Schleif wrote:
>
> >"Michael D. Schleif" wrote:
> > >
> > > how do we stop masqueraded connections to a given remote port?
> > >
> > > this does not work in /etc/ipchains.forward:
> > >
> > > $IPCH -I forward -j DENY -p udp -s 192.168.0.0/16 -d 0.0.0.0 1214
> > > $IPCH -I forward -j DENY -p tcp -s 192.168.0.0/16 -d 0.0.0.0 1214
> > >
> > > what do you think?
> >
> >I have also tried these _without_ success:
> >
> >$IPCH -I input -j DENY -p udp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i eth0
> >$IPCH -I input -j DENY -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i eth0
> >$IPCH -I input -j DENY -p udp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i wan1
> >$IPCH -I input -j DENY -p tcp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i wan1
> >$IPCH -A output -j DENY -p udp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i eth0
> >$IPCH -A output -j DENY -p tcp -s 0.0.0.0/0 1214 -d 0.0.0.0/0 -i eth0
> >$IPCH -A output -j DENY -p udp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i wan1
> >$IPCH -A output -j DENY -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 1214 -i wan1
> >
> >
> >This is evidence of the failure:
> >
> ># netstat -Mn | grep 1214
> >tcp 137:51.51 192.168.13.103 213.166.63.97 4680 -> 1214
> >(64280)
> >tcp 96:29.21 192.168.13.103 213.166.61.21 4431 -> 1214
> >(63842)
> >tcp 175:44.59 192.168.13.103 64.157.147.70 4732 -> 1214
> >(64369)
> >tcp 195:15.28 192.168.13.103 24.222.82.41 4845 -> 1214
> >(64544)
> >tcp 14:45.23 192.168.13.103 200.243.17.204 4349 -> 1214
> >(63696)
> >tcp 75:17.67 192.168.13.103 67.233.168.173 4565 -> 1214
> >(64089)
> >tcp 92:51.49 192.168.13.103 217.224.26.124 4603 -> 1214
> >(64165)
> >tcp 124:53.85 192.168.13.103 213.166.62.57 4648 -> 1214
> >(64231)
> >tcp 53:51.02 192.168.13.103 80.14.23.48 4504 -> 1214
> >(63975)
> >tcp 40:34.36 192.168.13.103 12.87.135.40 4314 -> 1214
> >(63624)
> >tcp 180:46.91 192.168.13.103 213.166.56.209 4714 -> 1214
> >(64343)
> >
> >
> >This is what I want to accomplish:
> >
> >[1] I do *not* want to block tcp 1214 nor udp 1214 at the external
> >interface (wan1)
> >
> >[2] I want to deny both tcp 1214 and udp 1214 connections _from_ the
> >internal interface (eth0)
> >
> >[3] I want to deny both tcp 1214 and udp 1214 connections _to_ the
> >internal interface (eth0)
> >
> >Any ideas?
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
