Background

If you have a working BOPM installation, you are trying to prevent abuses of your IRC network effected through anonymity services such as proxies. BOPM has built-in support for scanning for open proxies. It also has support for looking up clients in DNSBLs, which are used to publish lists of misbehaving or malign hosts. One such DNSBL, called TorDNSEL, provides a way to check users connecting through the Tor anonymity service.

As discussed at TorDNSEL’s information page, the purpose of this service is to provide finely-grained information about whether a client’s connection could be through a Tor exit node. Tor exit nodes can be configured with advanced exit policies which specify the sorts of direct outbound connections a Tor exit node is willing to make on behalf of its anonymous client. For example, a Tor exit node administrator could disallow his node to make connections to government sites and disable outgoing connections on common IRC ports. If a Tor exit node is run by an administrator who is interested in also connecting to an IRC network, that administrator would disallow outgoing IRC connections. Thus, any IRC connection made (on a common IRC port) through that node would be a legitimate connection made by a user on that host and not a connection from an anonymous client. The TorDNSEL DNSBL lets—and requires—networks which use it to take this into account.

Prerequisites

This short guide assumes that you have successfully configured BOPM to connect to your IRCd, parse oper notices informing it of client connections, and issue a G/Z:line or SHUN for some other event which identifies a client as using a particular anonymity service.

Configuring BOPM

As TorDNSEL’s information page documents, performing a TorDNSEL lookup requires the IRC client’s IP A.B.C.D, the port of the service being accessed P, and the public IP of the IRCd E.F.G.H. With these parameters, a query would be an A record lookup of the domain name D.C.B.A.P.H.G.F.E.ip-port.exitlist.torproject.org. If the response was NXDOMAIN, then either there is no Tor exit node at A.B.C.D or, if that IP identifies an exit node, that node is unwilling to connect to E.F.G.H on port P because its exit policy forbids such a connection. If the response is 127.0.0.2, then there is a Tor exit node at A.B.C.D which would willying connect to E.F.G.H on port P. From this information, we can produce a BOPM blacklist block:

OPM {
    # …
    blacklist {
        name = "P.H.G.F.E.ip-port.exitlist.torproject.org";
        type = "A record reply";
        reply {
            2 = "Tor exit server";
        };
        ban_unknown = yes;
        # GZLINE issuing a 7-day network-wide zline with UnrealIRCd-compatible syntax
        kline = "GZLINE *@%i 7d :You are connecting from a Tor exit node willing to connect to E.F.G.H:P";
    };
    # …
};

The above blacklist should be copy-pastable into your bopm.conf‘s OPM section. But, remember to replace E, F, G, and H with the respective components of your IRCd’s IP address. In the name line, it is intended that the components of the IP are in reverse order. This is because the right end of a domain is more general and the left end is more specific whereas in the first component of an IP address is most general and the rightmost component is more specific.

Also, note that you shouldn’t copy the … into your bopm.conf; each of these is just a placeholder indicating that you probably already have other blacklist blocks which should be preserved defined inside the OPM block.

One last note about this blacklist entry. If your IRC network, like many networks, allows connections to multiple ports, you must specify a blacklist entry for each port. For example, 6667 is the port an IRC client will try, by default, to use when connecting to an IRCd. But if a client wants to use SSL (without STARTTLS), you might have instructed your IRCd to listen for SSL connections on port 6697. A side effect of TorDNSEL’s specific entries is that a tor exit node may be instructed to deny outbound connections on port 6667 yet allow them on 6697. Since BOPM cannot (AFAIK) be configured to automatically choose a value for P, you must create a blacklist block for each IRCd public IP and port combination.

Breakdown

OPM {
    # …
    blacklist {
        name = "P.H.G.F.E.ip-port.exitlist.torproject.org";

Here you specify your server’s public IP, E.F.G.H, in reverse as H.G.F.E as well as the port your IRCd is listening on, P. BOPM will prepend the IP of the IRC client which connects, A.B.C.D, in reverse order as D.C.B.A when it checks if the client is in this TorDNSEL.

        type = "A record reply";

This specifies that BOMP should take the IP address the DNSBL returns and interpret that as a response. DNSBLs generally use IPs in the reserved localhost range, 127.0.0.0/8, to avoid pointing to IPs owned by third parties.

        reply {
            2 = "Tor exit server";
        };

This is the list of potential DNSBL responses which you anticipate from TorDNSEL. If the DNSBL returns NXDOMAIN (which means, “I don’t know about this doain”), BOPM will ignore the answer and assume the client is not in the DNSBL. However, if the server responds with an IP such as 127.0.0.2, BOPM will subtract 127.0.0.0 from the IP and then look for the result 2 in this reply list. If it finds an entry, it performs the action in kline discussed below.

TorDNSEL currently only defines two possible responses. NXDOMAIN indicates that the node would not connect to E.F.G.H:P on behalf of a Tor client. 127.0.0.2 or, as BOPM interprets it, 2 indicates that there is a Tor exit node at A.B.C.D which is willing to connect to your IRCd.

        ban_unknown = yes;

This line states that, if the DNSBL responds with an IP other than those handled in the reply block, it should assume that the client still should be banned. The TorDNSEL guide states Other A records inside net 127/8, except 127.0.0.1, are reserved for future use and should be interpreted by clients as indicating an exit node. This means that the TorDNSEL project reserves the right to add a new response, such as 127.0.0.3, which would indicate a subtly different sort of tor exit node. Until this new response is defined, all we know is that the IRC client probably should be banned by BOPM.

        # GZLINE issuing a 7-day network-wide zline with UnrealIRCd-compatible syntax
        kline = "GZLINE *@%i 7d :You are connecting from a Tor exit node willing to connect to E.F.G.H:P";

This is the IRC command which BOPM will issue when a client is listed in TorDNSEL. The above command will set a network-wide ban on the user’s IP which will last for 7 days using UnrealIRCd‘s syntax. A Global Z:Line is an efficient ban as the client’s connection can be closed by the IRCd before the IRCd looks up the client’s hostname. The reason listed with the GZ:Line is formulated so that the IRC user will understand exactly why he was banned.

    };
    # …
}; 

Be careful when editing your bopm.conf. Don’t forget any semicolons; even the ones after closing curly braces (}) are ncessary. If you’re reading this guide, you hopefully don’t need this advice ;-).

Testing

Once you have added the necessary configuration directives to your bopm.conf, you should test and check that BOPM catches the Tor exit nodes which are willing to connect to your IRCd. If BOPM was already running, do not forget to rehash it (BOPM’s readme suggests that /KILL BOPM (rehashing) is a convenient way to force BOPM to reread its configuration and reconnect). The following uses BOPM’s in-channel command interface to ask BOPM to scan an IP and check if it would be banned if a client connected from that IP. This requires that you have properly configured BOPM to join a channel with an IRC::channel block. An alternative test would be to just connect to your network through Tor, but that is probably more involved.

To check if your BOPM would detect a Tor IP, first find a Tor exit node (if using list list, ensure to choose an IP for which the “Exit Node?” column has “YES”). Then join the channel where BOPM is and issue the command BOPM check IP, where you replace BOPM with the nickname your BOPM bot is using and replace IP with the Tor exit node IP you looked up. A successful detection will look something like the following:

-!- BOPM2 [~bopm@Clk-NNNNNNNN] has joined #opers
<&binki> BOPM2 check A.B.C.D
< BOPM2> CHECK -> Checking 'A.B.C.D' for open proxies on all scanners
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 6667.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 6697.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> DNSBL -> A.B.C.D does not appear in BL zone 6900.H.G.F.E.ip-port.exitlist.torproject.org
< BOPM2> CHECK -> DNSBL -> A.B.C.D appears in BL zone 7000.H.G.F.E.ip-port.exitlist.torproject.org (Tor exit server)
< BOPM2> CHECK -> All tests on A.B.C.D completed.

In this scenario, the port 6900 was inside of a reject range policy on the Tor exit node I selected. For some odd reason, it seems that this port is part of a range which is commonly disabled in Tor exit nodes. Yet, the Tor exit node I chose admits that it is willing to connect to my IRCd still and will be banned because of one of the other OPM::blacklist blocks I have defined, such as the one for port 6667.

In your own tests, you might encounter Tor exit nodes which BOPM does not flag as needing to be banned. There are multiple reasons for this. First of all, you may have selected a Tor exit node with policies which disallow Tor clients to access IRC through it. Thus, you must try with multiple exit nodes randomly selected from some listing of Tor exit nodes before despairing. If you have checked multiple hosts and your BOPM refuses to recognize them, you may have misconfigured your BOPM’s blacklist entry. Double-check that you have put your correct server’s public IP in reverse order properly along with the correct port in the blacklist::name entry. Test that BOPM’s DNS is working by looking up D.C.B.A.P.H.G.F.E.ip-port.exitlist.torproject.org, perhaps using the getent hosts or dig tools. Remember to rehash BOPM (by /killing it with your /oper powers perhaps) after editing bopm.conf.

I was introduced to the bash builtin /dev/tcp by warg the other day on x-tab#chat. He explained a basic use of this device by demonstrating how to download wget’s compressed tarball. The download process itself can be done with pure bash, but some post-processing of the downloaded file must be done to remove HTTP headers. I document warg’s application of /dev/tcp here because I found the idea fascinating and want this documentation for myself ;-).

Connecting and Downloading

To read about the /dev/tcp builtin for yourself, check out the following:

$ info '(bash) Redirections'

With the exec line we initiate the connection, allocating a file descriptor and storing the numeic file descriptor into the HTTP_FD variable. Then, with the echo line, we send an HTTP request through the descriptor to the server. After sending the request, we process the server’s response with the sed line which skips over the HTTP headers sent by the server and stows the results into wget-latest.tar.gz. Note that this last command will sit around for a while. It is with this command that the builk of the data transfer is performed. And, since you’re using shell redirections to download the file, you cannot see the download progress. Instead, wait for the command to complete. This also involves waiting for the server to time out your connection since it supports pipelining. After this process is completed, the wget-latest.tar.gz file is as your disposal.

$ WGET_HOSTNAME='ftp.gnu.org'
$ exec {HTTP_FD}<>/dev/tcp/${WGET_HOSTNAME}/80
$ echo -ne 'GET /gnu/wget/wget-latest.tar.gz HTTP/1.1\r\nHost: '\
    ${WGET_HOSTNAME}'\r\nUser-Agent: '\
    'bash/'${BASH_VERSION}'\r\n\r\n'  >&${HTTP_FD}
$ sed -e '1,/^.$/d' <&${HTTP_FD} >wget-latest.tar.gz

Now you have a wget source tarball on your machine. As long as you have tar and a compiler on the machine, you are well on your way to downloading stuff using a self-compiled wget. In the commands above, you may replace “gz” with “bz2” or “lzma” for smaller downloads if the machine you’re using has bzip2 or xz-utils installed. And, of course, it should not be too hard to repurpose the above code to download a particular version of wget or even a completely unrelated software package.

Please feel free to point out problems with this approach or give pointers on porting this to other environments :-).

I have a Canon HF200 video camera and it outputs HD video, but it’s in .MTS file format. This is a pain because there are no good free video converters or editors for .MTS files. But using Avidemux, an open-source video converter, I was able to edit and convert my video to .mp4 while keeping my sanity and my money.

If you know your way around avidemux, pay attention to black colored text.

If you need extra help along the way, or I have something pointless to say, it will be in gray.

1 – Open the File

The first thing you have to do is import your video into Avidemux by one of two methods:

1) file –> open –> your-video.MTS

2) drag and drop the video file into avidemux

A dialog will appear saying, “This looks like MPEG, Do you want to index it?”… say “yes”

Avidemux will then tell you that it has detected H.264, say “yes”  to it’s other mode.

2 – Set Encoding Options

For the Video encoder you should use MPEG-4 AVC

For Audio I recommend AAC (Faac) and a bitrate of 192, (I’ll tell you right now AC3 does NOT work with youtube).

Use mp4 for the encapsulation (not avi like in the above pic).

Configure –> General

Use CRF (Constant Rate Factor) around 16 – 20. A CRF of 16 produces a larger file size; the higher the number, the less the quality and file size.

Configure –> Motion

Use UHS (Uneven Hexagonal Search) and SR (Subpixel Refinement) of 9 for best results.

3 – Fix Frame Rate Issues

Here is where everyone has the problem of “Why is the video half speed!?”

Well, that’s because avidemux doesn’t like you, and that Avidemux decided to treat the predictive and reference frames differently.

The way I fixed this was to double the video frame rate:

Main menu –> Video –> Frame Rate

According to my TI-89, 29.97 * 2 = 59.94 (or I just did it in my head, but think the 89 is a powerful tool, especially if you’re an electrical engineer)

Well… now your video is the right speed… but why is the file so large?

Go to video filters, transform –> Resample fps (back to 29.97).

Yeah, I know, I went extra wide screen with my video, so I feel like a ninja when I watch it, big deal.

I used other filters as well to reduce the resolution and trim the unneeded parts of the video to save space.

4 – Save the Video

File –> Save –> Save Video

Make sure you use the .mp4 extension.

That’s all, enjoy your well-compressed .mp4 video!

function getCurrentFile() {
  var filename = document.location.href;
  var tail = (filename.indexOf(".", (filename.indexOf(".org")+1)) == -1) ? filename.length : filename.lastIndexOf(".");
  return (filename.lastIndexOf("/") >= (filename.length - 1)) ? (filename.substring( filename.substring(0, filename.length - 2).lastIndexOf("/")+1, filename.lastIndexOf("/"))).toLowerCase() : (filename.substring(filename.lastIndexOf("/")+1, tail)).toLowerCase();
}

This function returns the current filename (minus the file extension) in all lower-case. Feel free to modify it to suit your needs. It also works properly even when a URL does not have a file extension (such as with some asp-based sites), or when there is no filename present (returns the folder name). This function is great for highlighting menu items based on which page the user is currently browsing. If you don’t understand some of the syntax, note that I’m using javascript’s conditional syntax as shorthand for if/else statements.

The problem: you have a computer sitting behind a firewall. You want to access it from a different location, but you don’t have the ability to forward any ports to it. The answer: SSH tunneling.

The Solution

Using an SSH tunnel, you can reverse-forward ports from one computer to another. To do this, you will need a computer running linux and sshd to reverse-forward the ports to. It is very convenient if this is the computer you will be using to access the remote machine. Otherwise, additional steps must be taken.

The Setup

The easiest way to set up and maintain a reverse port-forwarding tunnel is with ohnobinki’s insurgent script. The script allows you to specify a remote host and the ports you want to reverse-forward. To start off, create a new user on your system, such as insurgent. Log in or start a shell as this user. Assuming you have mercurial installed, run:

hg clone https://ohnopublishing.net/hg/insurgent

Now cd to the newly created insurgent/bin directory. Finally, place the contents of insurgent/share/contab.txt into your crontab (use crontab -e to edit your crontab).

Now you simply need to configure the script. To do so, open insurgent.sh in your favorite editor, and update the REMOTE_HOST and other variables. The format for ports is [remoteport]:hostname:[localport] (ssh(1) ). I recommend starting with reverse-fowarding SSH (port 22), a vnc session (590x where x is the VNC display number), and nfs.

If you have not done so already, you need to set up passwordless public key authentication for the new insurgent user.

You’re Done!

If you’ve gotten this far, you may be ready to go. You should be able to access any port on your insurgent box via the corresponding port on your local box. Have any problems? Drop some comments below or pop into irc.ohnopub.net#protofusion and speak to ohnobinki or normaldotcom.

Image credit: star6. Used under Creative Commons CC BY-SA 2.0

By default, when you exit most IRC clients (including pidgin), the quit message will look something like “normaldotcom has quit (Quit: normaldotcom).” The preferred way to exit out of a channel or an IRC session is using the /quit IRC command. It’s pretty simple, just type “/quit leaving to do something in real life with real people.” This will notify others of your departure, and your reasoning for doing so. It’s just a lot nicer and a lot less annoying. Practice proper IRC etiquette and use /quit !

Classify the problem: Are your fans loud or do they make scraping noises?

Scraping Noises

Scraping noises are often caused by bad bearings, whether it be an oil-sleeve bearing or a ball bearing. Take the label off of your fan, if you see a bearing surrounding the shaft, then you do NOT have an oil-sleeve bearing.

Oil sleeve bearings: Place one drop of light oil (sewing machine oil works quite well) on the spindle, replace the label, and let the fan run for a few minutes. Do not over-oil. If the fan is still noisy, remove the clip from the end of the shaft (if present) and detach the fan blades from the coil/case assembly. Ensure that the spindle and sleeve are clean, then re-assemble and oil.

Ball bearings: Place 1-2 drops of oil on the bearing(s). This may have limited success. If it fails, you can try flushing the bearings with oil, drying with paper towel, then putting on a single drop of oil.

Loud

Have loud fans? Chances are you need to just replace them or throttle them.

Throttling: Check out your bios for settings related to “Quiet n Cool” (for AMD CPU fan throttling) and PWM settings for other 3-pin fans on your system. Don’t have the options or 3-pin fans? Throttling can be done manually with rheostats and resistors, just make sure you don’t over heat your system.

Replacement: Check out eBay or your local junk drawer for any fans that may work as decent replacements. Feel free to use overly large fans on small heatsinks, such as northbridges; if positioned correctly, these may render decent results. Warning: Don’t try this with graphics card heatsinks, as they get much hotter than the average northbridge under load. For case fans, try and get larger (120mm) fans if your case accommodates them. Larger == less rpm == less noise + good airflow.

Any questions, comments, or criticism? Feel free to leave some comments.