Responses interspersed below. At 03:55 PM 6/15/02 -0500, Michael D. Schleif wrote: >Ray => > >Thank you, again . . . > >Ray Olszewski wrote: > > > > Thanks for the additional information. I see you have the rules you were > > describing at the top of the input chain and before the only ACCEPT rule in > > the output chains, so you should not be having order problems with them. > > And all the interface specifications appear to be correct. > > > > The "problem" connections you show below are all from one IP address, > > namely 192.168.13.103 . This causes me to wonder about one (admittedly > > remote) possibility ... do you KNOW that the connections are actually > > active with this ruleset in place? That is, might they be old connections > > that were made before you added the blocking rules and restarted the > > firewall, and are just sitting there idle because they haven't hit the MASQ > > timeout yet? > >Yes, after I read your response, I checked and there are now *NO* >tcp/udp 1214 connections to be found! > >Any idea what this timeout value is?
Not offhand, but the old Ipchains HowTo may report it. I recall it as relatively short by default, maybe 5 minutes or so (short enough that I used to routinely increase it by a lot, back when I used an ipchains-based router). In any case, you set it with the "ipchains -M -S tcp tcpfin udp" command (replace the last 3 entries with numbers for the timeouts, I think in seconds ... I'm running netfilers now so don't have a working ipchains config to check here). >I have been working on this, off and on, since 2200 last night. For >those who are interested, this customer has a T-1 to the internet, and >T-1's between multiple offices and -- omigosh! -- and the two owners' >homes. tcp/udp 1214 is the dreaded Kazaa and we have no interest in >managing security for this business with kids at home poking holes all >over the place ;< Ah yes, a real nightmare even in a pure home setting, let alone a mixed home-business environment. > > This feels to me like grasping at straws, but everything you've posted > > (including the content at the URL you provided) looks right, so I'm reduced > > to long shots. And I do know that restarting a firewall doesn't break > > established MASQ'd connections. > >[ snip ] > >Yes, now, apparently, it works -- the brute force approach. It's that >darn masquerading that confused me. > >Shouldn't we be able to block this inside the masquerading process? I don't think so; if you can, I certainly don't know how to. >To complete this exercise, I want to back out the un-necessary chains. >I should be able to block this at eth0, shouldn't I? Are the wan1 >chains un-necessary? Yes, for a NAT'd LAN. Only responses can come from the outside, not originating connections. So all you *should* need to do is block any packets from eth0 to port 1214 in the input chain, &/or any packets from port 1214 to eth0 in the output chain. Either should suffice, and I'd do the first (I always prefer to solve problems with the input chain if I can). >Also, I should be able to block this on one of many subnets, all >channelled through eth0, right? Yes, and you know how ... the rules you are using are the right form (the input-chain ones, at least). Just replace -s 0.0.0.0/0 with (for example) -s 192.168.13.0/24 in the input-chain rules. >Yes, I can just try this; but, since I am not in control of the tcp/udp >1214 connections, after every change I make, I need to wait and see . . Or if you have access to a LAN client running the Kazaa software, you can try to make a connection yourself. Other than rebooting, I don't know a way to destroy existing MASQ'd connections manually. -- -----------------------------------------------"Never tell me the odds!"-------------- Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] ------------------------------------------------------------------------------------------- _______________________________________________________________ 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
