binfalse

…sts (of course!). Yesterday I just installed a rating plugin, inspired by these stackexchange platforms.

Searching through the WordPress plugin directory didn’t make me happy. All existing plugins lack of desired features. After some tests I decided to modify UpDownUpDown of Dave Konopka. It’s a nice plugin, but still didn’t match my criteria. For example guests were not allowed to vote, there were some XHTML bugs and I didn’t like the style. So I created a patch (it’s attached..) and sent it to Dave (I don’t yet have a github account). He told me that he’ll take a look at it and might apply it to the official plugin, so if you also want to use this rating plugin with my additional features just keep the URL in mind and watch out for a new version.

The special version I’m using here right now has of course some more slight changes, to have it perfectly matched to my own blog. So you are now able to vote for articles, positive or negative, to give me a hint what my visitors like to read ;-)

I additionally installed a further page that lists my articles sorted by votes: top. So you can get a smart overview of best/worst content.

With this in mind: Happy voting! ;-)

Ever worried about these disgusting packets leaving your network interface!? Why not creating your own packets?

Of course it’s more than nonsense creating all packets on your own, but sometimes there might be a reason making you wish you could.. For ex. for my last article I searched for a possibility to modify some contents of a packet. First I thought about using iptables , but than I found a nice tool: scapy!

With scapy you can create your own packets, IP/TCP/UDP whatever! It is very heavy but comes with an user-friendly interface. Using Debian/Ubuntu you need to install python-scapy :

aptitude install python-scapy

To open the interface just run scapy . You can easily create an IP packet by typing something like this:

>>> ippacket=IP()
>>> ippacket.dst='binfalse.de'
>>> ippacket.ttl=12
>>> ippacket
<IP  ttl=12 dst=Net('binfalse.de') |>

So an IP packet is stored in the variable ippacket . This packet will be send to binfalse.de and has a ttl of 12 (if there are more than 12 network nodes between your machine and the target it will disappear and never arrive at the target). Let’s create some TCP stuff:

>>> tcpcrap=TCP()
>>> tcpcrap.sport=1337
>>> tcpcrap.dport=80
>>> tcpcrap
<TCP  sport=1337 dport=www |>

We stored some TCP information in tcpcrap . This packet will be send through your port 1337 and hopefully arrive at port 80 (in general a webserver is listening on port 80 ). That’s it for the networking part. Last but not least we will create some data to send:

>>> data='GET / HTTP/1.1 \\nHost: binfalse.de\\n\\n'
>>> data
'GET / HTTP/1.1 \\nHost: binfalse.de\\n\\n'

Combining all parts we’ll get a very nice packet, sending it will trigger my webserver to send the main page of my website (Sending exactly this packet won’t ever result in any website from my webserver. Why? Just think about…):

>>> whole=ippacket/tcpcrap/data
>>> whole
<IP  frag=0 ttl=12 proto=tcp dst=Net('binfalse.de') |<TCP  sport=1337 dport=www |<Raw  load='GET / HTTP/1.1 \\nHost: binfalse.de\\n\\n' |>>>
>>> send(whole)
.
Sent 1 packets.

Well done! Ok, that’s very much to do. But fortunately it’s just that much code for explanation, you can send the same packet in a single line:

>>> send(IP(ttl=12,dst='binfalse.de')/TCP(sport=1337,dport=80)/'GET / HTTP/1.1 \\nHost: binfalse.de\\n\\n')
.
Sent 1 packets.

Very smart, isn’t it? You can also sniff whooshing packets! But something like this I won’t explain, find out by yourself ;-)

I often here people saying something like

SSH to your home PC? Sitting behind a NAT? A snowball's chance in hell...

But is it really impossible?

What is a NAT?

NAT (network address translation) is a technique to cover multiple clients behind one router. Kristian Köhntopp explained the technology very well in his article NAT ist kein Sicherheitsfeature (GER). But let me summarize some things. Here is a small image to visualize the topology of an example network:

You see, the NAT represents something like a bridge between it’s clients (in network 10.0.0.0/24 ) and the rest of the world. The connections of the clients are translated by this router. Assuming client 10.0.0.3 wants to speak to my webserver 87.118.88.39 , he sends a packet containing, among others, the following information:

Source:      10.0.0.3:39478
Destination: 87.118.88.39:80

So all machines on the way from 10.0.0.3 to 87.118.88.39 know whom to send the packet next. When this packet arrives at the NAT, the NAT will rewrite it. The NAT stores a table for all recent connections. Each entry consists of a client IP, client port and a local port on its public interface. For our example the table entry for this example might look like:

The resulting port on the NAT is arbitary, it’s just one free port.. Each packet arriving on port 1234 of the public interface of the NAT is forwarded to 10.0.0.3:39478 . Our rewritten packet 10.0.0.3->87.118.88.39 now contains the following informations:

Source:      88.66.88.66:1234
Destination: 87.118.88.39:80

and is send to the next node in the world wide web. Nobody out of 10.0.0.0/24 will ever know that there is a machine 10.0.0.3 requesting a website from 87.118.88.39 . The webserver on 87.118.88.39 will send it’s answer to the pretended source, 88.66.88.66:1234 , and the NAT will forward the traffic according to its table entry to 10.0.0.3 .

Why do NAT’s exists? The solely plausible reason seem to be the lack of IPv4 addresses. With a NAT an ISP just need to offer a single IP address for a huge bunch of clients. Hopefully this will change in times of IPv6!

Why does it seem to be impossible?

Since the private network 10.0.0.0/24 is not known by the outer world (it is simply not route-able in the Internet, see wikipedia), you cannot connect from outside 10.0.0.0/24 straight to 10.0.0.3 . The WWW will only see 88.66.88.66 as source for all the clients. That means all clients in 10.0.0.0/24 have the same public IP for each machine that is not in 10.0.0.0/24 . So how to access 10.0.0.3 ? Speaking to 88.66.88.66 will result in crap, you don’t know which port will be forwarded to whom!? If it is forwarded at all…

How is it nevertheless possible?

Method one...

…is not very nice, if you are looking for a real solution please skip this paragraph and continue with solutions two and three ;-) Since there is no entry in the NAT table that specifies an outside target, you can send packets from any location to 88.66.88.66:1234 and the NAT will forward them to 10.0.0.3:39478 (according to my example). So to create a path from outside to 10.0.0.3 ‘s SSH server you just need to send a packet from 10.0.0.3:22 to any server outside that informs you about the source IP and source port that was reported by the NAT (it’s the address that will be forwarded to the client). If you immediately connect to this address, and if a SSH server is listening on 10.0.0.3:22 , you should be able to establish a SSH session. Simple isn’t it ;-) To get this working you could try something like repeating the following commands frequently:

# stop SSH to free the port
/etc/init.d/ssh stop

# send a packet to somewhere that is configured to notify you about the NAT settings
# the foreign side should instantaneously close the connection
# so the netcat command doesn't block your script
netcat -p 22 binfalse.de 1337

# restart SSH to get ready for connections
/etc/init.d/ssh stop

Of course you can also install some iptables rules to rewrite the TCP packets. So you can send the packets from some other ports than 22 , iptables will rewrite them so the target machine (and the NAT) thinks they came from :22 . With this setup you don’t have to stop SSH, because you don’t need the free port… But just hack it your way ;-)

Method two...

…is much more comfortable. You can set up a reverse SSH tunnel! Again you need another machine outside the NAT, that has a SSH server running and will act as your gateway. Just connect to it from your local machine behind the NAT:

ssh -R 1337:localhost:22 you@your.server

That will open the port 1337 on your.server . All packets arriving at this port are transferred through the SSH tunnel to your home PC. Run something like screen or top on the server to always transfer packets (otherwise the connection will be closed after some time), with -o ServerAliveInterval=XXX you can adjust the threshold for closing the SSH connection. Surround it with a while loop and you’ll reestablish closed connections (network errors or something like that):

while [ 1 ]; do ssh -o ServerAliveInterval=60 -R 1337:localhost:22 you@your.server; done

By default the opened port is just bound to 127.0.0.1 (the servers loopback interface), so you can only send packets from the server itself (or need some more network hacking). To have this hack listening to 0.0.0.0 (all interfaces) add the following to your /etc/ssh/sshd_config on your.server :

GatewayPorts yes

and restart the daemon.

Method three...

…might be the most elegant. Set up a VPN! But that’s too much for now, request some explanations from 3dfxatwork, he’s your OpenVPN guy!, and take a look at Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space

So you see, no hasty prejudices ;-)

One of my PC’s is covered behind a firewall and just one port is opened. I want to serve SSH and HTTPS, but as you know it’s not easy to get both listening on the same port, so what should I do?

Of course one possibility is to decide for the more important application and forget about the other. But there is another solution! But first of all let’s have a look at both protocols.

If you connect to a SSH server he immediately welcomes you with the running SSH-version, for example:

usr@srv % telnet binfalse.de 22
Trying 87.118.88.39...
Connected to binfalse.de.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6

Here it is SSH-2.0-OpenSSH_5.5p1 Debian-6 . So your client connects and just waits for an answer from the server. In contrast The HTTP protocol doesn’t greet:

usr@srv % telnet binfalse.de 80
Trying 87.118.88.39...
Connected to binfalse.de.
Escape character is '^]'.

The server is programmed to just answer request. So if we ask for anything it will give some feedback:

usr@srv % telnet binfalse.de 80
Trying 87.118.88.39...
Connected to binfalse.de.
Escape character is '^]'.
GET / HTTP/1.1
host: binfalse.de

HTTP/1.1 200 OK
Date: Sun, 26 Jun 2011 15:17:00 GMT
Server: Apache
X-Pingback: /xmlrpc.php
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
[...]

You see, the web server responds with code 200 , indicating everything is fine.

These differences in both protocols can be used to set up a proxy. If the client starts to send something it seems to speak HTTP, otherwise the client seems to wait for some SSH greetings. Depending on the client behavior the proxy should forward the packets to the relevant application. There is a nice Perl module to implement this easily: Net::Proxy .

First of all both applications need to be configured to not use the open port. Without loss of generality let’s assume port 443 is opened by the firewall, SSH listens on it’s default port 22 and your webserver is configured to listen on 8080 . The following piece of code will split the requests:

#!/usr/bin/perl -w
###############################
#
#   Creating a dual proxy w Perl
#
#   written by Martin Scharm
#     see http://binfalse.de
#
###############################

use warnings;
use strict;
use Net::Proxy;

# for debugging set verbosity => dumping to stderr
# Net::Proxy->set_verbosity (1);

my $proxy = Net::Proxy->new (
	{
		in =>
		{
			# listen on 443
			type => 'dual', host => '0.0.0.0', port => 443,
			# if client asks for something direct to port 8080
			client_first => { type => 'tcp', port => 8080 },
			# if client waits for greetings direct to port 22
			server_first => { type => 'tcp', port => 22 },
			# wait for 2 seconds for questions by clients
			timeout => 2
		},
		# we don't use out...
		out => { type => 'dummy' }
	}
);

$proxy->register ();
Net::Proxy->mainloop ();

Some notes:

• To listen on ports < 1024 you need to be root!
• Debians need to install libnet-proxy-perl .
• Some protocols that wait for the client: HTTP, HTTPS
• Some protocols that greets the clients: SSH, POP3, IMAP, SMTP

Ja, es ist Deutsch! Warum? Ich habe mich heute bei der Verwertungsgesellschaft WORT registriert ;-)

Was ist denn VG WORT?

Die VG WORT verwaltet die Tantiemen aus Zweitverwertungsrechten an Sprachwerken. Die Unternehmen, die Kopierer oder Drucker oder CD’s oder Ähnliches verkaufen, müssen einen gewissen Betrag an die VG WORT bezahlen. Die VG WORT sammelt das Geld und gibt es an Journalisten, Schriftsteller, Verleger etc. weiter. Publiziert also jemand etwas, das öffentlich zugänglich ist, kann er sich einen kleinen Beitrag von der VG WORT abholen. Das gilt natürlich nicht nur für große Arbeiten (Diplom, Dr. oder Journal-Beitrag), auch Blogger können mitmachen!

Wie geht das?

Als Blogger kann man für Texte mit mind. 1.800 Anschlägen eine Vergütung bekommen. Es gibt zwei Arten der Vergütung:

• Teilnahme an der Sonderausschüttung
• Vergütung basierend auf den Leserzahlen

Für die Sonderausschüttung gibt es sehr viel weniger Geld, sobald man Zugriff auf den Quelltext des Textes im Netz hat kann man auch nicht daran teilnehmen. So bleibt für uns Blogger nur die Vergütung basierend auf den Leserzahlen. Dazu bekommt man von der VG WORT sogenannte Zählmarken. Das sind nichts anderes als 1x1 Pixel, die man in seinen Artikel integriert. Ließt ein Besucher dann diesen Artikel, lädt er sich auch diese “Bild” vom Server der VG WORT und die zählen dann für diesen Beitrag eins hoch. So funktioniert übrigens auch der Facebook Like-Button: Wenn ihr den irgendwo seht könnt ihr davon ausgehen, dass Facebook weiß, dass ihr diese Seite besucht habt. Mir ist bewusst, dass ich damit die Privatsphäre meiner Leser einschränke, daher auch gleich die Lösung: Wenn ihr nicht wollt, dass die VG WORT euch trackt solltet ihr eurem Browser das Laden von Bildern verbieten, oder diverse Plugins so konfigurieren, dass sie die Bilder mit der URL http://vg\\d{2}.met.vgwort.de/.* blocken. Im Zweifel wisst ihr schon wie das läuft.

Wo gibt es das Geld?

Als Blogger muss man sich als erstes bei der VG WORT registrieren. Das kann man in der Oberfläche T.O.M. erledigen. Dann kommt ein wenig Bürokratie: Formulare ausfüllen, unterschreiben, abschicken… Ist dies erledigt, kann man sich diese Zählpixel bestellen, die kommen auch sofort per Mail. Gezählt wird immer vom 1. Januar bis zum 31. Dezember des selben Jahres. Im Folgejahr wird dann die Vergütung berechnet und man kann eine Auszahlung beantragen. Wenn das was ich so im Netz gelesen habe stimmt, gibt es für 1.500 Zugriffe 15 Euro, für 3.000 Besucher gibt es 20 Euro und sollten mehr als 10.000 Browser euren Artikel ausliefern gibt es 30 Euro. Die 10k werde ich wohl erst einmal nicht ins Auge fassen, 1500 Besucher sollte aber Möglich sein ;-)

Es werden im Übrigen nur Besucher aus Deutschland gezählt. Daher ist dieser Artikel auch auf Deutsch. Fragt mich nicht, wie die Leute festlegen ob ein Klick aus Deutschland kommt oder nicht, ich denke im Zweifel wird er nicht gezählt. Auch Pixel die in verschiedene Akregatoren wie den GoogleReader ausgeliefert werden zählen nicht. Daher wäre es nett wenn ihr auch hin und wieder einmal auf die Seite durch klickt.

All in all

Ich betrachte das als Experiment (dieses Jahr werde ich wohl nicht mehr als 20 Pixel verbauen) und erwarte keine größeren Einnahmen, aber wer weiß. Das Geld schüttet die VG WORT sowieso aus, warum soll ich also nicht auch die Hände aufhalten!? Wer sich seine Vergütung nicht abholt ist selbst Schuld ;-)

Result

Von den gelisteten Artikeln haben es 4 geschafft die Mindestbesucherzahl zu erreichen. Habe dafür von der VG WORT 40 € bekommen: Danke an alle Besucher :D Im Endeffekt hat sich das natürlich nicht wirklich rentiert, eher ein kleiner Bonus. Es war aber ein nettes Experiment, das mittlerweile auch schon beendet wurde. Alle Zählpixel wurden zugunsten der Privacy entfernt. Ihr dürft aber trotzdem fleißig weiter klicken!