#307 pgmcmd(.lib) handles non-standard FWD options incorrectly

PeerGuardian_Linux
closed
jre-phoenix
Settings (19)
5
2012-11-11
2010-09-01
Athanasius
No

insert_iptables() in /usr/lib/pgl/pglcmd.lib has the following in the case... FORWARD) section:

CMD_WHITE_IP="--source --destination"
CMD_ALLOW="--src-range --dst-range"

which is just plain wrong as it results in the attempted command:

iptables -I pgl_fwd -m iprange '--src-range --dst-range' - -j RETURN

for configured values of and .

Basically the whole handling of forwarding options needs rethinking and recoding.

For now I've changed the ALLOW_FILES bit for FORWARD to have:

CMD_WHITE_IP="--destination"
CMD_ALLOW="--dst-range"

as that suits my purposes. The code likely wants entirely changing to put in separate source and destination commands though.

Discussion

  • jre-phoenix
    jre-phoenix
    2010-09-05

    So I'm back from holiday and am just looking into this. I don't use FORWARD myself, so I'm glad to have someone who is using it. The changes that cause the problem were introduced in pgl 2.0.2, so previous versions are not affected.
    If I see it correctly my implementation of whitelisting IPs with WHITE_IP_FWD already does what it should: 2 iptables rules based on CMD_WHITE_IP:
    iptables -I pgl_fwd -source -j RETURN
    iptables -I pgl_fwd -destination -j RETURN

    For the allow file with IP ranges the code is already correct, except that at that point the IFS is set to newline. I'll fix that, so that we will really get 2 iptables rules for each LINE:
    iptables -I pgl_fwd -m iprange --src-range - -j RETURN
    iptables -I pgl_fwd -m iprange --dst-range' - -j RETURN

    While we are on that topic: The FORWARD port witelisting (WHITE_TCP_FWD and WHITE_UDP_FWD) is working correctly, right!?

     
  • jre-phoenix
    jre-phoenix
    2010-09-05

    Done and commited to the git repository. This will be part of pgl 2.0.3.

     
  • Athanasius
    Athanasius
    2010-09-12

    The port WHITE_TCP_FWD and WHITE_UDP_FWD were already working correctly, yes, as they specify no source/destination IP(range).

    However testing 2.0.3 with NOT listing the ip blocks in allow.p2p (which was my workaround before), and having:

    WHITE_FWD="82.69.184.120/29 192.168.1.0/24 192.168.11.0/24"

    has resulted in:

    17:04:45 2$ iptables -nvL pgl_fwd
    Chain pgl_fwd (1 references)
    pkts bytes target prot opt in out source destination
    0 0 RETURN esp -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 RETURN 41 -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 RETURN all -- * * 192.168.11.0/24 192.168.11.0/24
    0 0 RETURN all -- * * 192.168.1.0/24 192.168.1.0/24
    0 0 RETURN all -- * * 0.0.0.0/0 127.0.0.1
    0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa LOG flags 0 level 6 prefix `fwr-pg:'
    0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port-unreachable
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 209.20.67.240-209.20.67.241
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 209.20.67.240-209.20.67.241
    1 76 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 193.62.22.98-193.62.22.99
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 193.62.22.98-193.62.22.99
    1 76 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 212.23.8.6-212.23.8.7
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 212.23.8.6-212.23.8.7
    6 360 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 81.94.195.193-81.94.195.198
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 81.94.195.193-81.94.195.198
    0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport ports 27000:27500,60072,53
    0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport ports 27000:27500
    42 2520 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport ports 60072,43,30000:30100,42,20,21,5050,1863,5222,5190,53,22,443,80
    10 512 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

    i.e. it's still doing "If it's from this net back to itself", which is wrong. It should be one line for 'source' with 0.0.0.0/0 for the destination and then another rule with those swapped.

    Ah, hang on, that's the default "what interfaces do we have?" code doing that. You changed WHITE_FWD to WHITE_IP_FWD it seems. Using that new/changed variable has this working now it seems:

    pkts bytes target prot opt in out source destination
    0 0 RETURN esp -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 RETURN 41 -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 RETURN all -- * * 0.0.0.0/0 127.0.0.1
    0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa LOG flags 0 level 6 prefix `fwr-pg:'
    0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port-unreachable
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 209.20.67.240-209.20.67.241
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 209.20.67.240-209.20.67.241
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 193.62.22.98-193.62.22.99
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 193.62.22.98-193.62.22.99
    1 76 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 212.23.8.6-212.23.8.7
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 212.23.8.6-212.23.8.7
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 81.94.195.193-81.94.195.198
    0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 81.94.195.193-81.94.195.198
    0 0 RETURN all -- * * 0.0.0.0/0 192.168.11.0/24
    0 0 RETURN all -- * * 192.168.11.0/24 0.0.0.0/0
    0 0 RETURN all -- * * 0.0.0.0/0 192.168.1.0/24
    0 0 RETURN all -- * * 192.168.1.0/24 0.0.0.0/0
    2 118 RETURN all -- * * 0.0.0.0/0 82.69.184.120/29
    4 240 RETURN all -- * * 82.69.184.120/29 0.0.0.0/0
    0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport ports 27000:27500,60072,53
    0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport ports 27000:27500
    0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport ports 60072,43,30000:30100,42,20,21,5050,1863,5222,5190,53,22,443,80
    0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

     
  • Athanasius
    Athanasius
    2010-09-12

    My, that's annoying paste behaviour... inserting line breaks at the width of this input box, so one just before 'box' then ?

     
  • Athanasius
    Athanasius
    2010-09-12

    Checking this over one last time I think you will want to fix up the "auto whitelist local networks" code to not do what's described below. The IN/OUT stuff works fine, but those FWD rules expecting the traffic to come and go to the same net are wrong. If that's fixed I can likely get away with not using WHITE_IP_FWD at all.

    Basically you either want to do something like:

    for
    for
    If
    next loop iteration
    else
    insert rule between these two IP ranges, source from outer loop, destination from inner loop
    endif
    endloop
    endloop

    OR just loop over them all once and use 0.0.0.0/0 for the other source/desintation. I think the loop above is technically more correct. You only want to white list communication that is purely on the local LAN(s), not open all those IPs up to *any* communication when forwarding. The latter would mean pgl only protecting the machine it's on! (Slightly offset by any such local LAN ranges usually being RFC1918).

     
  • Athanasius
    Athanasius
    2010-09-12

    Ugh, actually when it's working properly I'll still have to use WHITE_IP_FWD because Spotify is a pain in the ass. It uses random source *and* destination ports for its P2P, so I really just have to whitelist the IP I use it on for forwarding (always a my desktop, with pgl on the server it uses as gateway). I'll test things again with other than that, and hopefully when the new code is in git pre-release this time!

     
  • Athanasius
    Athanasius
    2010-09-12

    In case I didn't say before, the reason I find these bugs is I now have a network that looks like this:

    Server with:
    ethpub - direct connection to my ADSL router which has 82.69.184.120/29 on the 'inside' from my ISP. As far as my server is concerned it has this entire /29 itself. There is a slight wrinkle in that I put that on the ethpriv... but then have proxyarp and host routes to put .122 (linux desktop) and .124 (windows desktop) on ethpriv. I can worry about that if needs be, but it's simple to not have pgl in the way just by only specifying networks on FWD rules *not* interfaces as well.
    ethpriv - direct connection to my desktop, 192.168.1.0/24 network
    ethwap - direct connection to my WiFi Access Point (WAP), 192.168.11.0/24 network

    And I've also recently setup an IPSec L2TP tunnel, but that also ends up on the 192.168.1.0/24 network (actually 192.168.1.16/28) so it doesn't add any further wrinkles as far as pgl is concerned.

    However this does mean I may want my phone on 192.168.11.4 to talk freely with my desktop on 192.168.1.161 (or .4 when in windows). Thus I have a case of two local networks where I do want free communication between all hosts. Thus just whitelisting their ranges on IN and OUT isn't enough, FWD really does have to also be correct.

    I generally only run P2P on the server (rtorrent). Any P2P that might run on the desktop occasionally I'm willing to forgo protection for (it has Comodo as a s/w firewall and is all 100% legal and not likely to get accidental fingers pointed at it due to being things like Blizzard WoW patches).

    So what I need is:

    1) Anything IN/OUT on 82.69.184.120/29 protected.
    2) Anything FWD on the internal networks just allowed.
    3) Anything FWD to anywhere else protected (because, hey, why not?).

     
  • jre-phoenix
    jre-phoenix
    2010-10-21

    I implemented your suggestion from "2010-09-12 16:25:07 UTC". Thanks! You'll find it in the git repository.

    I changed it in so far that I also add whitelisting rules from and to the same network (same ranges). Or did I miss any point why this shouldn't be necessary?

    I think that solves all remaining issues for FORWARD. I hope you are still interested, and thus am looking forward to your feedback.

     
  • This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • jre-phoenix
    jre-phoenix
    2010-11-09

    Just saw that this tracker was closed for commenting, so I reopened it. Feedback is of course still welcome.