Page 15 of 65 FirstFirst ... 5131415161725 ... LastLast
Results 141 to 150 of 650

Thread: General MoBlock thread

  1. #141
    Join Date
    Aug 2008
    Location
    Brazil
    Beans
    12,497
    Distro
    Ubuntu Studio 12.04 Precise Pangolin

    Re: General MoBlock thread

    Quote Originally Posted by noblem View Post
    The allow.p2p file may not have the desired effect as it creates iptables rules to allow traffic out to the allowed range, in from the allowed range and forwarded traffic from either a source or destination of the allowed range.

    This is fine if you want to allow an host/range that's external to the local lan (which I'm guessing was the idea). If your trying to use it to allow traffic from your local lan the in and out will be backwards and all forwarded traffic will bypass moblock totally which probably isn't what you want, especially if the moblock host is doing nat for your internal network.

    The WHITE_LOCAL option may work, but forwarding is still going to be a problem so removing the lan range from the blocklist is probably the safest option
    That's why you can configure /etc/default/moblock with the following rules:

    Code:
    ALLOW_IN="$CONF_DIR/allow-in.p2p"
    ALLOW_OUT="$CONF_DIR/allow-out.p2p"
    ALLOW_FW="$CONF_DIR/allow-fw.p2p"
    This way you can create different allow lists for INBOUND, OUTBOUND and FORWARD traffic.

    BTW, the local network whitelisting feature is still experimental, so again, using the alow lists is the best way.


    EDIT: I forgot to mention that the iptables rules created by the allow lists are related only to traffic marked by moblock, which means that if you want to confine traffic on local ranges to the local network, all you have to do is create iptables that allow local traffic but block external access to those ranges. This can be done manually inserting iptables rules, using a firewall manager like Firestarter or using moblock's custom scripts. This gives a lot of flexibility to control your traffic, as along as you understand how iptables works.
    Last edited by lovinglinux; November 25th, 2008 at 10:23 PM.

  2. #142
    Join Date
    Mar 2008
    Beans
    9

    Re: General MoBlock thread

    @lovinglinux It sounds like your moblock-control script is creating different rules from mine and sounds like it might actually work.
    I think the best advise we can give anyone would be to ensure the iptables rules are sending traffic to moblock and it's actually blocking what you expect. You don't want to inadvertently bypass moblock by excluding the wrong thing

  3. #143
    Join Date
    Mar 2008
    Beans
    9

    Re: General MoBlock thread

    OK, I've now defiantly got the latest moblock-control script, from the (from package 1.0-1 for debian/sid but shouldn't be any different for any other variant). The script adds the following lines for IPs in the allow file(s)
    Code:
    iptables -I moblock_in -m iprange --src-range allow_range -j RETURN
    iptables -I moblock_out -m iprange --dst-range allow_range -j RETURN
    iptables -I moblock_fw -m iprange --dst-range allow_range - j RETURN
    iptables -I moblock_fw -m iprange --src-range allow_range - j RETURN
    Assuming that moblock is running on a gateway box with a LAN interface and a Internet interface, the in and out rules should work fine for traffic in/out of the LAN interface. No traffic with a LAN IP should be sent to the internet, so that's fine
    However any forwarded traffic from or to the LAN will match the rules in the moblock_fw and won't even be sent to moblock.

    The WHITE_LOCAL would seem the more appropriate option to use (even if experimental) but looks like it needs a bit of work.

    I can't see any easy way to correctly whitelist forwarded traffic without messing around with rules in the NAT table but being a bit more selective with the blocking list is probably easier/safer

  4. #144
    Join Date
    Aug 2008
    Location
    Brazil
    Beans
    12,497
    Distro
    Ubuntu Studio 12.04 Precise Pangolin

    Re: General MoBlock thread

    Quote Originally Posted by noblem View Post
    OK, I've now defiantly got the latest moblock-control script, from the (from package 1.0-1 for debian/sid but shouldn't be any different for any other variant). The script adds the following lines for IPs in the allow file(s)
    Code:
    iptables -I moblock_in -m iprange --src-range allow_range -j RETURN
    iptables -I moblock_out -m iprange --dst-range allow_range -j RETURN
    iptables -I moblock_fw -m iprange --dst-range allow_range - j RETURN
    iptables -I moblock_fw -m iprange --src-range allow_range - j RETURN
    Assuming that moblock is running on a gateway box with a LAN interface and a Internet interface, the in and out rules should work fine for traffic in/out of the LAN interface. No traffic with a LAN IP should be sent to the internet, so that's fine
    However any forwarded traffic from or to the LAN will match the rules in the moblock_fw and won't even be sent to moblock.

    The WHITE_LOCAL would seem the more appropriate option to use (even if experimental) but looks like it needs a bit of work.

    I can't see any easy way to correctly whitelist forwarded traffic without messing around with rules in the NAT table but being a bit more selective with the blocking list is probably easier/safer
    I don't have a gateway so my FORWARD rules are all denied. Anyway, as long as I understand, if you don't add the local ranges to allow-fw.p2p, moblock will not RETURN local traffic directed to moblock_fw chain to FORWARD chain, so traffic will be filtered as expected by moblock and no local traffic will be forwarded.

    Even if the local traffic passes through moblock, you still can create FORWARD rules in the iptables to prevent local ranges traffic to be forwarded. Then, local traffic being forwarded will not be marked by moblock and will RETURN to the FORWARD iptables chain, where it will be REJECTed or DROPped.

  5. #145
    Join Date
    Mar 2008
    Beans
    9

    Re: General MoBlock thread

    Adding the LAN range to the allow-fw.p2p will mean it's not passed to moblock and therefor any traffic that's being routed for the moblock host (In my case any traffic from a PC being NATed by the server running moblock) won't be protected. This is probably a bad thing and ensuring traffic passing through the forward chain is passed through moblock would be highly desirable in most cases.

    Traffic entering the forward chain is going to have either a source or destination of a local LAN address and moblock checks both source and destination against the blocklist for traffic in the forward chain. This means that if your LAN range is included in the blocklist it's always going to be flagged as bad.

    Obviously it's possible to add custom iptables rules to control what is or isn't blocked, but I can't think of one that will work in this case s the only option is to ensure your LAN range isn't on the blocklist.

  6. #146
    Join Date
    Aug 2008
    Location
    Brazil
    Beans
    12,497
    Distro
    Ubuntu Studio 12.04 Precise Pangolin

    Re: General MoBlock thread

    Quote Originally Posted by noblem View Post
    Adding the LAN range to the allow-fw.p2p will mean it's not passed to moblock and therefor any traffic that's being routed for the moblock host (In my case any traffic from a PC being NATed by the server running moblock) won't be protected. This is probably a bad thing and ensuring traffic passing through the forward chain is passed through moblock would be highly desirable in most cases.

    Traffic entering the forward chain is going to have either a source or destination of a local LAN address and moblock checks both source and destination against the blocklist for traffic in the forward chain. This means that if your LAN range is included in the blocklist it's always going to be flagged as bad.

    Obviously it's possible to add custom iptables rules to control what is or isn't blocked, but I can't think of one that will work in this case s the only option is to ensure your LAN range isn't on the blocklist.
    I see. I didn't know moblock check both source and destination in the forward chain.

  7. #147
    Join Date
    Jan 2007
    Beans
    770

    Re: General MoBlock thread

    @Sevis:
    With this setup no traffic on port 80 (http) should be blocked! Your config seems to be correct.
    But it seems that your MoBlock daemon was not running, perhaps it crashed. Check /var/log/moblock-control.log and /var/log/moblock.log to see why/if the daemon crashes.
    Please make sure that the daemon is running. Then check in /var/log/moblock.log if MoBlock is really blocking the sites that you want to access.
    ... I just read your next post:
    Quote Originally Posted by Sevis View Post
    At the end, there are quite a few lines like:

    Code:
    Sat Nov 22 13:17:25| OUT: IANA - Private Use [RFC1918],hits: 1,DST: 10.0.0.2
    Seeing as 10.0.0.2 is my DNS, I suppose that this would be the problem - should I unblock it in my defaults file? I have the feeling this would allow everything, but I am not all too good in the area of firewalls.
    I think your right. Just use
    Code:
    WHITE_IP_OUT="10.0.0.2"
    .

    @lovinglinux and noblem:
    Great to have you here! I think you came to the correct conclusions. I've already thiought much about FORWARD, but I don't use it so I could never test it. But you are right (Other readers be careful, this relates only to FORWARD (Moblock is running on a router):
    • Don't use the allowlist or WHITE_IP_FORWARD to whitelist LAN traffic. This would allow all traffic.
    • The automatical whitelisting will whitelist the LAN for FORWARD in other ways: Only traffic with source AND destination in the LAN gets whitelisted here. This solves the above problem, but:
    • ... still leaves you with all forwarded traffic from/to the internet being blocked. So probably it's indeed the best thing to just remove the LAN range, as noblem said.


    @Sevis:
    Quote Originally Posted by Sevis View Post
    On another note, my log file (/var/log/moblock.log) is filled with "Skipping useless range:" and then a name or title.
    That's normal. It's a result of the merging of several blocklists.

    Unrelated comment: You added this to whitelist your LAN:
    Code:
    WHITE_IP_IN="192.168.0.0/24"
    WHITE_IP_OUT="192.168.0.0/24"
    But the automatic whitelisting chose 192.168.1.0/24
    So your entries seem both unnecessary and incorrect.


    @typo99:
    LAN-access-problems have nothing to do with the TBG blocklists. The old default bluetack blocklists had the LAN blocked, too. This is why whitelisting the LAN is necessary, but this happens automatically per default.

    @fixture:
    This is in the documentation (in short words: just make sure MoBlock is started after shorewall and gets restarted after any shorewall change.):
    Since version 0.9, MoBlock no longer conflicts with other firewalls. Make sure
    the following three conditions hold:
    - MoBlock marks non-matched (IP is not in the blocklist)
    packets. (The marking feature is on per default. It
    will be explained and asked for later.)
    - Other firewalls do not mark packets.
    - MoBlock is started after other firewalls. If other
    firewalls are started/reloaded after MoBlock, then you
    need to restart MoBlock again. You will be fine, if the
    iptables rules which send traffic to MoBlock's iptables
    chains (moblock_in, moblock_out and moblock_fw) stand
    before all other iptables rules which ACCEPT traffic.

    You can check your iptables rules with
    iptables -L -nv
    or
    moblock-control status.
    Please post your logfiles and output of commands wrapped in code tags:
    Code:
    [code]output[/code]
    Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.

  8. #148
    Join Date
    Feb 2008
    Location
    The Netherlands
    Beans
    9
    Distro
    Kubuntu 8.10 Intrepid Ibex

    Re: General MoBlock thread

    I\'m sorry for the late reply, but it seems to work very well, thank you! Didn\'t even need to allow MSN separately, worked well enough without it ;

  9. #149
    Join Date
    Feb 2006
    Location
    Hatboro, PA
    Beans
    2,538
    Distro
    Ubuntu Development Release

    Re: General MoBlock thread

    sorry if this has already been handled, but are the bluetack lists down? i can't seem to update...
    Asus EeePC 1005HA: ElementaryOS Luna | Asus X501A: Windows 8.1 & Ubuntu GNOME 14.10 Utopic Unicorn | Apple iMac G4: Ubuntu 14.04 Trusty Tahr | LG Optimus F3: Stock v7 | Nexus 10 Cyanogenmod 11

  10. #150
    Join Date
    Jan 2007
    Beans
    770

    Re: General MoBlock thread

    Quote Originally Posted by moore.bryan View Post
    sorry if this has already been handled, but are the bluetack lists down? i can't seem to update...
    What do you have in your /etc/moblock/blocklists.list?

    The lists from bluetack are indeed partly down, atm. See http://www.bluetack.co.uk/forums/index.php

    I'm working on a release which allows php redirects. Then all lists by iblocklist will be supported and I'll change default lists to TBG instead of bluetack.
    In the meantime you can use the lists from http://tbg.iblocklist.com/Lists or just wait until the bluetack lists are updated again.

    @Sevis: Glad to hear.
    Last edited by jre; December 1st, 2008 at 11:16 PM.
    Please post your logfiles and output of commands wrapped in code tags:
    Code:
    [code]output[/code]
    Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.

Page 15 of 65 FirstFirst ... 5131415161725 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •