Page 49 of 65 FirstFirst ... 39474849505159 ... LastLast
Results 481 to 490 of 650

Thread: General MoBlock thread

  1. #481
    Join Date
    Dec 2006
    Beans
    163
    Distro
    Kubuntu Development Release

    Re: General MoBlock thread

    The lists are available again now.
    Official update from the site owner http://forums.peerblock.com/read.php?3,9886

  2. #482
    Join Date
    Dec 2008
    Beans
    355
    Distro
    Ubuntu 10.04 Lucid Lynx

    Re: General MoBlock thread

    Not sure what's going on but my moblock isn't working Jr.

    Here's the result of "moblock status" details
    Code:
    Current IPv4 iptables rules (this may take a while):
    Chain INPUT (policy ACCEPT 174 packets, 30733 bytes)
    pkts bytes target prot opt in out source destination
    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    Chain OUTPUT (policy ACCEPT 212 packets, 23865 bytes)
    pkts bytes target prot opt in out source destination
    Please check if the above printed iptables rules are correct!
    moblock is not running. ... failed!
    blockcontrol.wd is not running. ... failed!

  3. #483
    Join Date
    Jan 2007
    Beans
    772

    Re: General MoBlock thread

    Please check /var/log/blockcontrol.log
    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.

  4. #484
    Join Date
    Dec 2008
    Beans
    355
    Distro
    Ubuntu 10.04 Lucid Lynx

    Thumbs down Re: General MoBlock thread

    I got the problem: I had sweep-cleaned my "Desktop" that was full of clutter but one of the files that were there was "custom-blocklist.p2p"

    New file created and problem solved!
    Last edited by Jerriy; April 23rd, 2011 at 07:15 AM.

  5. #485
    Join Date
    Apr 2011
    Beans
    8

    Question Re: General MoBlock thread

    First and foremost, thanks for this awesome piece of software. This is by far the best utility in it's category.

    I have a quick question about how incoming packets are handled. Are they dropped or blocked? From my understanding, with blocked packets the sender is responded to and with dropped packets the sender receives nothing. In the file blockcontrol.defaults I see the section stating

    Code:
    # Set what happens to matched packets (IP is in the blocklist).
    # 0 - DROP them directly (as in MoBlock 0.8).
    # 1 - MARK them. Further iptables rules decide what happens to them. E.g. this
    #     allows to REJECT packets to avoid the long timeout, which occurs when
    #     packets are DROPped, see below. This setting is also necessary for
    #     iptables logging to syslog, see below.
    REJECT="1"
    but I'm confused as to the exact meaning. Does this mean if I set REJECT="0" iptables could over-rule this setting? Just in case, here's the relevant section in my blockcontrol.defaults.

    Code:
    # Set how traffic is sent to the IP block daemon.
    # 0 - Don't set any iptables rules.
    #     You or another script/firewall has to do this!
    # 1 - Place the iptables rules in separate iptables chains (blockcontrol_in,
    #     blockcontrol_out and blockcontrol_fw). Afterwards the custom iptables
    #     scripts will be executed (if they exist).
    # 2 - Only set custom iptables rules
    #     (/etc/blockcontrol/iptables-custom-insert.sh and
    #     /etc/blockcontrol/iptables-custom-remove.sh)
    IPTABLES_SETTINGS="1"
    
    # Activate the iptables chains?
    # This section works only for IPTABLES_SETTINGS="1"
    # 0 - Do nothing. You or another script/firewall has to do this!
    # 1 - Send all NEW traffic to the iptables chains (blockcontrol_in,
    #     blockcontrol_out and blockcontrol_fw). These iptables rules are inserted
    #     at the head of the chains INPUT, OUTPUT and FORWARD. It is safe to only
    #     check NEW traffic.
    # 2 - Send all traffic to the iptables chains (blockcontrol_in, blockcontrol_out
    #     and blockcontrol_fw). These iptables rules are inserted at the head of the
    #     chains INPUT, OUTPUT and FORWARD. Checking all (not only NEW) traffic
    #     might cause problems, because the IP block daemon has to check much more
    #     traffic then. Further, whitelisting gets more complicated, since you have
    #     to think of both directions, incoming and outgoing. Only do this, if you
    #     are sure that you want to.
    IPTABLES_ACTIVATION="1"
    
    # Set what happens to matched packets (IP is in the blocklist).
    # 0 - DROP them directly (as in MoBlock 0.8).
    # 1 - MARK them. Further iptables rules decide what happens to them. E.g. this
    #     allows to REJECT packets to avoid the long timeout, which occurs when
    #     packets are DROPped, see below. This setting is also necessary for
    #     iptables logging to syslog, see below.
    REJECT="1"
    
    # Set the corresponding MARK
    REJECT_MARK="10"
    
    # Set the iptables target for "marked block" packets.
    # This section works only for IPTABLES_ACTIVATION="1"
    # REJECT_IN is useless for the unpatched MoBlock source (0.8 and 0.9RC2), since
    # there matched incoming packets are dropped directly. So the DROP rule in
    # the iptables chain blockcontrol_in will never be met.
    # Valid values are all iptables targets. Be careful: senseless values are also
    # accepted.
    # REJECT: The sender of the packet is notified that the packet was blocked.
    # DROP: The sender of the packet is not notified that the packet was blocked.
    REJECT_IN="DROP"
    REJECT_OUT="REJECT"
    REJECT_FW="DROP"
    I'm asking this because this morning (via mobloquer) I noticed a non-stop flood of incoming attempts being blocked from a chinese IP address, and since I'd prefer to eliminate all chinese traffic (as it's mostly hackers and spammers) I added list.iblocklist.com/lists/cn to my blocklists. This got me to wondering if I'm actually replying (thus making myself visible) to these attempts.

  6. #486
    Join Date
    Jan 2007
    Beans
    772

    Re: General MoBlock thread

    Short story: everything is as you want it

    With REJECT="1" incoming traffic gets handled by REJECT_IN="DROP". This means traffic is dropped, and this is exactly what you want (same result as for REJECT="0").
    So the chinese sender tried to connect, but didn't get any answer so he tried again.

    So with your setting REJECT_IN="DROP" (the default setting) you are in "stealth mode" from the outside world (e.g. incoming traffic from China). But at the same time you actively tell your applications that you don't want to connect (REJECT_OUT="REJECT") to China, and thus avoid long waiting periods until the apps give up with a timeout.
    Last edited by jre; May 13th, 2011 at 05:02 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.

  7. #487
    Join Date
    Apr 2011
    Beans
    8

    Re: General MoBlock thread

    Excellent! Thank you very much jre.

  8. #488
    Join Date
    Sep 2009
    Beans
    3

    Re: General MoBlock thread

    recently i just started getting these bogon blocks with moblock, but they aren't bogon addresses. the lists appear to block everything or almost everything. what is going on? i uninstalled and reinstalled and it does the same thing. if i stop using the bogon list, it finds it under some malware list.
    Attached Images Attached Images

  9. #489
    Join Date
    Jan 2007
    Beans
    772

    Re: General MoBlock thread

    blockcontrol merges all single lists that are specified in /etc/blockcontrol/blocklists.list to one master blocklist. Overlapping and continuous IP ranges are merged to one IP range. IIRC only the description of the first range is kept for the whole new merged range. This explains why an IP is reported by its description to be part of an unrelated range.
    I don't know though, why you get so many "bogon" hits. This may be normal (see above), but you may also have a look at the master blocklist /var/lib/blockcontrol/guarding.p2p to see if there are any other IP range descriptions.

    You can find out the real IP range by executing
    Code:
    blockcontrol search $IP
    Where $IP is the blocked IP. This will show you the original IP range and the blocklist where it was specified.
    Since this is a very simple search function that just executes a "grep $IP" on the single blocklists it may be necessary to try a more common search term (Start it with ":" which separates the description and the IP. And just use the beginning of the IP). Repeat this until you find the matching range. E.g.
    Code:
    blockcontrol search :222.108.161.19
    blockcontrol search :222.108.161
    blockcontrol search :222.108.
    I agree that this should be improved
    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.

  10. #490
    Join Date
    Sep 2009
    Beans
    3

    Re: General MoBlock thread

    here is what i get:

    example "bogon" IP: 66.96.99.10

    Code:
    # blockcontrol search "\:66\.96\."
    Checking your currently used blocklists for "\:66\.96\." (case-insensitive):
    
    atma_atma (list.iblocklist.com/lists/atma/atma)
    2011-05 Malware .....................:66.96.145.103-66.96.145.103
    2011-04 Malware .....................:66.96.145.103-66.96.145.105
    2011-05 Malware .....................:66.96.145.105-66.96.145.105
    2011-05 Malware .....................:66.96.207.161-66.96.207.161
    2011-05 Malware .....................:66.96.207.207-66.96.207.207
    2011-05 Malware .....................:66.96.212.230-66.96.212.230
    2011-05 Malware .....................:66.96.212.86-66.96.212.86
    2011-03 Malware .....................:66.96.214.134-66.96.214.134
    2011-03 Malware .....................:66.96.214.215-66.96.214.215
    2011-04 Malware .....................:66.96.215.214-66.96.215.214
    2011-04 Malware .....................:66.96.215.76-66.96.215.76
    2011-05 Malware .....................:66.96.218.85-66.96.218.85
    2011-05 Malware .....................:66.96.220.5-66.96.220.5
    2011-05 Malware .....................:66.96.221.5-66.96.221.5
    2011-05 Malware .....................:66.96.222.152-66.96.222.152
    2011-05 Malware .....................:66.96.223.40-66.96.223.40
    2011-05 Malware .....................:66.96.240.245-66.96.240.245
    2011-03 Malware .....................:66.96.241.38-66.96.241.38
    2011-05 Malware .....................:66.96.245.68-66.96.245.68
    2011-05 Spammer .....................:66.96.215.214-66.96.215.214
    2011-05 Spammer .....................:66.96.215.76-66.96.215.76
    2011-03 Spammer .....................:66.96.248.199-66.96.248.199
    2011-05 SSH Attack ..................:66.96.201.178-66.96.201.178
    2011-05 SSH Attack ..................:66.96.255.69-66.96.255.69
    
    Bluetack_badpeers (list.iblocklist.com/lists/bluetack/bad-peers)
    test p2p abusers:66.96.18.9-66.96.18.9
    
    TBG_Business_ISPs (list.iblocklist.com/lists/tbg/business-isps)
    E. I. Catalyst:66.96.16.0-66.96.31.255
    Equant, Inc.:66.96.32.0-66.96.63.255
    HIVELOCITY VENTURES CORP:66.96.80.0-66.96.95.255
    Packet Clearing House:66.96.112.0-66.96.127.255
    Endurance International Group:66.96.128.0-66.96.191.255
    Network Operations Center Inc:66.96.192.0-66.96.255.255
    
    TBG_General_Corporate_Ranges (list.iblocklist.com/lists/tbg/general-corporate-ranges)
    SEGUROS LA PREVISORA:66.96.56.96-66.96.56.127
    Ket Partners Net Solutions:66.96.207.0-66.96.207.255
    Redlight.org:66.96.208.225-66.96.208.254
    Alex Beschetnov:66.96.211.192-66.96.211.207
    Incyber Advertising Incorporation:66.96.212.2-66.96.212.99
    ems10.your-freedom.de:66.96.216.181-66.96.216.181
    interservers:66.96.231.115-66.96.231.124
    Seventennet Partners:66.96.237.0-66.96.237.255
    interservers:66.96.244.5-66.96.244.34
    vpn4.world-secure-channel.com:66.96.249.101-66.96.249.101
    
    TBG_Primary_Threats (list.iblocklist.com/lists/tbg/primary-threats)
    Schlumberger Network Solutions:66.96.46.0-66.96.47.255
    Eternity:66.96.214.135-66.96.214.149
    Aspiration Hosting/anti-p2p activity:66.96.224.37-66.96.224.37
    Seventennet Partners/anti-p2p activity:66.96.237.251-66.96.237.251
    DediCatedNEW/anti-p2p activity:66.96.248.53-66.96.248.53
    Network Operations Center/anti-p2p activity:66.96.251.26-66.96.251.32
    
    "\:66\.96\." was found in these lists:
    atma_atma (list.iblocklist.com/lists/atma/atma)
    Bluetack_badpeers (list.iblocklist.com/lists/bluetack/bad-peers)
    TBG_Business_ISPs (list.iblocklist.com/lists/tbg/business-isps)
    TBG_General_Corporate_Ranges (list.iblocklist.com/lists/tbg/general-corporate-ranges)
    TBG_Primary_Threats (list.iblocklist.com/lists/tbg/primary-threats)
    
    If you don't want to block the above shown ranges, then you may add
    "\:66\.96\." to IP_REMOVE in /etc/blockcontrol/blockcontrol.conf.
    Or you may remove some of these lists from /etc/blockcontrol/blocklists.list.
    This seems to mean that it's not found, but somehow it's getting blocked anyway. my assumption based on what i'm witnessing is that there is a 0.0.0.0/0 block somewhere in the mix that is auto-blocking everything. this only started recently.

    Thanks.

Page 49 of 65 FirstFirst ... 39474849505159 ... 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
  •