The lists are available again now.
Official update from the site owner http://forums.peerblock.com/read.php?3,9886
The lists are available again now.
Official update from the site owner http://forums.peerblock.com/read.php?3,9886
Not sure what's going on but my moblock isn't working Jr.
Here's the result of "moblock status" detailsCode: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!
Please check /var/log/blockcontrol.log
Please post your logfiles and output of commands wrapped in code tags:Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.Code:[code]output[/code]
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.
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
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 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"
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.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"
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:Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.Code:[code]output[/code]
Excellent! Thank you very much jre.
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.
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
Where $IP is the blocked IP. This will show you the original IP range and the blocklist where it was specified.Code:blockcontrol search $IP
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.
I agree that this should be improvedCode:blockcontrol search :222.108.161.19 blockcontrol search :222.108.161 blockcontrol search :222.108.
Please post your logfiles and output of commands wrapped in code tags:Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.Code:[code]output[/code]
here is what i get:
example "bogon" IP: 66.96.99.10
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.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.
Thanks.
Bookmarks