Mr. Blaxell,
--- Zygo Blaxell <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Derrik Pates <[EMAIL PROTECTED]> wrote:
> >It would appear the mangle5hooks patch has been applied to the mainline
> >kernel as part of that update. Now mangle targets can be used on all 5
> >hooks (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING).
>
> Any chance that we could get 'filter' targets in all five places as well?
>
> Suppose I want to migrate rules directly from ipchains to iptables,
> because I don't want to have to rewrite ~235 tested and verified ipchains
> firewall rules from scratch just to use one new iptables feature.
>
> I might use the following mappings:
>
> ipchains input rule -> iptables -t mangle PREROUTING rule
> (except REDIRECT, which is -t nat)
> ipchains forward rule -> iptables -t filter FORWARD rule
> ipchains output rule -> iptables -t mangle POSTROUTING rule
> (unless you are using SNAT or MASQUERADE)
>
> mangle-PREROUTING is called first when all incoming packets are received
> for every packet, so it works reasonably well as a replacement for
> ipchains-compatible input filtering (assuming your actual INPUT chain
> in the forward table has policy ACCEPT). filter-FORWARD is close enough
> to ipchains forward for my purposes (I usually only have one forward
> rule, and never more than four, out of rule sets ranging in size from
> 188 to 312 rules).
>
> For ipchains output rules I seem to be stuck. There is
> mangle-POSTROUTING, which is the closest thing to the ipchains output
> chain, but nat-POSTROUTING is called after it, which means that any
> changes to the packet done by outgoing NAT (especially MASQ) can't be
> filtered at all. Logically, there should be a POSTROUTING chain in the
> filter table which deals with this.
There was a large discussion (I think) early on in the mailinglist about
the priorities of the mangle table. I believe it was eventually agreed that mangle
belongs before nat. As for having the filter table take up allfive hook points, I
don't think that's feasible, IMO.
>
> The first thing in my ipchains output chain is usually a sanity check to
> make sure that I'm not sending packets with an inappropriate source
> address. I seem to have nowhere to put this check in iptables.
>
> Historically this check has been necessary as Linux networking never seems
> to get it right in non-trivial cases--I have dropped many thousands of
> outgoing packets over the years in places where they just should not be.
> Especially bad problems occur when MASQ is combined with dynamic changes
> to the routing table or policy routing, and there was a really mysterious
> bug in the NFS kernel server code that would cause it to start sending
> replies via random interfaces despite the fact that such routing disagrees
> with the interface address, the routing table, the origin of the request
> packet, and all common sense. ipchains could catch all of these bugs
> easily, but I can't have the same confidence in iptables because it lacks
> filter-POSTROUTING.
OK. I understand why you want a POSTROUTING chain for filtration purposes.
But I don't think that the coreteam will auhorize any new patches to change the
location and number of hooks in the current tables. At least I don't think they
will right now; if a good enough reason comes up, maybe they will ;)
>
> I and some of my clients have to deal with some ISP's with fairly
> draconian policies about incorrect source addresses on packets.
> That policy is: disconnect subscriber, wait about six hours, leave
> rude voicemail, close ISP office, wait for someone to call back and ask
> for reconnection during business hours. If Linux starts spewing wrong
> packets on a Friday, I could be offline for an entire weekend.
Well, TBH if you have a strong firewall policy and keep a rigid control
over what packets go in and out, then this scenario may not take place. What sort
of firewall rules do you have in place?
>
> --
> Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
> GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
>
Brad
=====
Brad Chapman
Permanent e-mail: [EMAIL PROTECTED]
Current e-mail: [EMAIL PROTECTED]
Alternate e-mail: [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
