1 |
On Jan 3, 2013 1:57 AM, "Michael Orlitzky" <michael@××××××××.com> wrote: |
2 |
> |
3 |
> On 01/02/13 08:38, Tanstaafl wrote: |
4 |
> > Hi all, |
5 |
> > |
6 |
> > This has been bugging me for a while... |
7 |
> > |
8 |
> > I've googled, and can't seem to find a definitive answer to this |
9 |
> > question... |
10 |
> > |
11 |
> > Lots of references to the Mangle table, but nothing that really explains |
12 |
> > what this table is or does, and when or why I would want/need it. |
13 |
> > |
14 |
> |
15 |
> It allows you to mangle the low level bits of a packet. You only need it |
16 |
> for routing gymnastics. |
17 |
> |
18 |
> |
19 |
> > Currently, I have this in my rules (since forever, honestly don't even |
20 |
> > remember where it came from): |
21 |
> > |
22 |
> > *mangle |
23 |
> > :PREROUTING ACCEPT [1378800222:449528056411] |
24 |
> > :INPUT ACCEPT [1363738727:447358082301] |
25 |
> > :FORWARD ACCEPT [0:0] |
26 |
> > :OUTPUT ACCEPT [1221121261:1103241097263] |
27 |
> > :POSTROUTING ACCEPT [1221116979:1103240864155] |
28 |
> > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG |
29 |
> > FIN,PSH,URG -j DROP |
30 |
> > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j |
31 |
> > DROP |
32 |
> > -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP |
33 |
> > -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP |
34 |
> > COMMIT |
35 |
> > # Completed on Sun Dec 11 14:11:01 2011 |
36 |
> > |
37 |
> |
38 |
> The PREROUTING table happens before the routing decision is made. So |
39 |
> those rules happen before the network stack decides what to do with a |
40 |
> packet. |
41 |
> |
42 |
> Suppose, for example, that you forward all packets from your LAN to |
43 |
> wherever they're supposed to go. You might want to alter the source IP |
44 |
> of VPN traffic (which a priori is not from the LAN interface) so that it |
45 |
> appears to come from the LAN before you decide whether or not to forward |
46 |
it. |
47 |
> |
48 |
> The POSTROUTING table is similar, only it happens after the packet's |
49 |
> destination is set in stone. So you can, say, change the source IP |
50 |
> address in the packet and still have it routed wherever it was going to |
51 |
> go originally. |
52 |
> |
53 |
> |
54 |
> > This is on a mail/web server with a static IP, it does not do any NAT |
55 |
> > and does not act as a perimeter firewall, it only protects itself... |
56 |
> > |
57 |
> > Thanks for any pointers to tfm that explains this if there is one, or |
58 |
> > just for a simple explanation if not... |
59 |
> > |
60 |
> |
61 |
> I don't know what you were trying to do there, but it doesn't sound like |
62 |
> you need it. You might have been trying to block packets in an invalid |
63 |
> state. If so, consider using conntrack's --ctstate INVALID to drop them |
64 |
> instead. |
65 |
> |
66 |
|
67 |
Just to add some references... |
68 |
|
69 |
When dealing with iptables (and its kissing cousin, ebtables), I always |
70 |
find these diagrams to be most helpful: |
71 |
|
72 |
Definitive: http://www.wenzk.net/bbs/attachments/PacketFlow_BTgdX6im2Scu.png |
73 |
|
74 |
Complementary: http://linux-ip.net/nf/nfk-traversal.png |
75 |
|
76 |
Rgds, |
77 |
-- |