- DNSBL Whitelists support
- HTTP GET proxies scan support
DNSBL Whitelists support
What does it do?
This patch extends Blitzed's excellent Open Proxy Monitor with DNSBL whitelist support. It allows you to specify one or more whitelist DNSBLs that will override all blacklists in use by bopm. However, it will not keep bopm from scanning ports and K-lining/reporting when a positive result is found.
The problem
bopm allows you to specify one or more DNS based blacklists (DNSBLs) to speed up recognition of known open proxies. Many DNSBLs with various targets and characteristics exist, and some of them list open proxies. Most DNSBLs, however, are designed for use by mail systems. They have not been designed with IRC in mind.
Although in general this doesn't matter, one thing where this becomes obvious is in regard to listing dynamic IP ranges. Many people using dialup modems or certain Cable/DSL setups receive a different IP address every time they connect to their Internet Service Provider. When an open proxy is found and abused on one of these dynamic IP addresses, the address can become blacklisted for a large period of time, even while that specific IP address may be in use by a totally different person and system five minutes later, without any sign of an insecure proxy setup at all!
As most DNSBLs are used for blocking spam by mail servers, and most people using dynamic IPs should use their ISP's smarthost mailserver for sending mail, this doesn't cause much trouble. IRC is a different story. When these DNSBLs are used to block known open proxies from abusing IRC networks, they generate a lot of false positives when dynamic IP addresses are listed. opm.blitzed.org addresses this by setting a very low expiration time for IP addresses in known dynamic ranges. Unfortunately, most other DNSBLs do not.
So why not just use opm.blitzed.org, and forget about the rest? In a perfect world, opm.blitzed.org would know of all badly-configured proxies out there, and there would be no need for other DNSBLs. Indeed - in a perfect world, there would be no open proxies, spammers, insecure systems and clueless people, and thus no need for DNSBLs at all ;-). But as we know, this is not the case, and the use of multiple DNSBLs with bopm can be beneficial.
The solution
The problem would be solved when we could get bopm to ignore the blacklists for dynamic IP addresses. After all, DNSBLs are of little use for dynamic addresses, and bopm can still detect open proxies by scanning ports. Therefore, we need a way to specify which IP addresses are dynamic, and which are not. There are lots and lots of these ranges, so specifying and maintaining them in bopm's configuration file would be tedious. But since we're using DNSBLs anyway, why not use the same methodology for whitelisting?
This is where DNSBL whitelists kick in. When used with your own DNSBL (or should I say DNSWL? ;-), listing known dynamic IP ranges used by many chatters, this can greatly reduce the number of false positives, while maintaining the benefits of multiple DNSBLs. Creating your own DNSBL really isn't that hard, provided a little knowledge of DNS is available. And since there are plenty of DNSBLs listing dynamic IPs available (e.g. dynablock.easynet.nl, njabl.org), you even can get away without one.
How does it work?
The patch extends bopm's configuration file with 2 additional boolean options: whitelist and alert. Whitelist configuration is exactly the same as blacklist configuration, except that whitelist = yes has to be specified. Here's an example:
OPM {
blacklist {
name = "dynablock.easynet.nl";
whitelist = yes;
alert = no;
ban_unknown = yes;
type = "A record reply";
reply {
2 = "Dynamic address";
};
};
/* ... other blacklists/whitelists go here ... */
};
Because the bopm channel can get quite noisy when bopm is reporting all whitelist positive results, I added a boolean option alert that specifies whether bopm should tell the channel about positive results for this DNSBL or not. It also works with blacklists, and it doesn't affect logging to file.
When whitelists are in use, bopm will send DNS queries for them, along with queries for regular blacklists. It will immediately start scanning ports as well, just like before. Behaviour is a little different when DNS results come in. Because bopm has to know whether a certain host is whitelisted before it can decide to K-line, it has to wait for all whitelist results. This might delay bopm a little, and you may want to make sure your whitelists are quick to respond, on a fast connection. When bopm is certain the host is not whitelisted, it will use a (possibly queued) blacklist positive result to K-line.
Note that behaviour for scanning ports is totally unaffected by this patch. Whitelists will not (and should not!) override this, as an open proxy found by bopm through actively scanning ports is strong evidence!
Download and installation
- Whitelist patch for BOPM release 3.1.2
- Whitelist patch for BOPM CVS
Note: I will try to adapt this patch to current CVS regularly, but I can't promise it will always apply cleanly.
Download BOPM 3.1.2 and the patch above. Unpack, and apply the patch:
$ tar -zxvf bopm-3.1.2.tar.gz $ cd bopm-3.1.1 $ patch -p0 < ../bopm.whitelists.3.1.2.diff
...and configure/compile BOPM as usual.
HTTP GET scan support
What does it do?
These patches extend bopm (and libopm) with HTTP GET scan support. This can be helpful with (for example) CGIIRC and ircds without PING cookies.
In more detail
When we started using CGIIRC on our network, with - ofcourse - a dedicated bopm to protect it from open proxies, I discovered some abusers using proxies that bopm couldn't detect. After investigating, it turned out that these proxies were open for HTTP GET requests, but denied HTTP CONNECT and HTTP POST commands. There shouldn't be many of these proxies around, as most open HTTP GET proxies will be open for HTTP POST or HTTP CONNECT as well (HTTP GET and HTTP POST are quite similar in this respect). Still, we got enough abuse to warrant writing HTTP GET scan support for bopm.
Please mind that HTTP GET proxies can be (ab)used to get on IRC even without something like CGIIRC. Every protocol line will include a colon (:), but this isn't a problem at all, since most IRC protocol lines include colons. Fortunately, some ircds have PING cookie support, and this stops them (and other non-interactive clients like HTTP POST) quite well.
The bopm patch extends the configuration file with a target_url option for the scanner-section. It needs this, because it has to know a URL it can ask the proxy about and compare with target_string.
To use it, create (for example) a textfile on a webserver, with some random text in it. Point target_url to the URL of this file, and put a corresponding match string in a target_string for the scanner in question. Here's an example:
scanner {
name = "httpget";
/*
* HTTP GET proxies. Although not really a threat for normal IRC,
* they can be abused for CGI:IRC
*/
protocol = HTTPGET:80;
protocol = HTTPGET:3128;
protocol = HTTPGET:8080;
target_url = "http://www.yourwebserver.tld/bopmcheck.txt";
target_string = "4droovDemov-ot@OkTilduntibAvVocneehaidor";
};
user {
mask = "*!*@*";
scanner = "httpget";
};
Note that you don't have to use a separate scanner for it, an existing one is fine as well.
Download and installation
- Combined (bopm/libopm) HTTPGET patch for BOPM release 3.1.2
- HTTPGET patches for BOPM and libopm CVS
Note: I will try to adapt these patches to current CVS regularly, but I can't promise they will always apply cleanly.
Download BOPM 3.1.2 and the patch above. Unpack, and apply the patch:
$ tar -zxvf bopm-3.1.2.tar.gz $ cd bopm-3.1.1 $ patch -p0 < ../bopm.libopm.httpget.3.1.2.diff
...and configure/compile BOPM as usual.
Comments
are welcome on mark AT nedworks.org, and/or the BOPM mailinglist.
Patches & text written and maintained by Mark Bergsma. Design stolen from Taras Young & Tom Gilder.