We can set up a socks proxy on top of a SSH tunnel. Besides the common proxy functions, such as web browsing, the proxy on top of SSH tunnel also ensures the security between the browser and the proxy server (the SSH server). In this post, we introduce and explain how to set up a proxy over SSH tunnel and the mechanism of it.

A simple example

Let’s start with a simple example. We can access a sshd server sshd_server and we want to use it as a socks5 proxy server. It is simple by using ssh:

$ ssh -D 8080 username@sshd_server

After that, set the browser such as firefox’s proxy option to use socks5 proxy That’s it!

Then, check whether your IP is from the proxy from the websites’ view: Who am I.


While reading about DNS servers and BIND9, I came across the concept of Caching-Only DNS servers. I’m not going to go into great detail about how DNS works, but simply put, a Caching-Only DNS, well, caches DNS query results for the domain name being queried. The results are stored for a period of time known as the time-to-live, or TTL, which is specified on the name servers of the particular queried domain. Most computers and routers query the ISP’s DNS servers each time by default.

To really get a good understanding of how DNS works, I’ve found the following quite helpful:
– DNS and BIND (you can pickup a used copy for fairly cheap, or even get the previous version for even less!)
– DNS & BIND Cookbook (supplement to the above; has many great examples and configurations for various DNS setups)
– Otherwise there are many good resources online; I’ve used StackOverflow to help guide me in the right direction and many other web pages for help and information.

What you are going to need:
– A Computer to host the Caching-Only DNS server (I’ll be deploying this in a VM as there is no need for a powerful computer to run a small DNS server)
– A Linux distribution (I’ll be using Ubuntu Server 8.04)
– Some basic Linux knowledge as well as networking knowledge


Last time we covered a very basic setup. Multiple people have contacted me so far requesting an explanation on how to move towards a slightly more sophisticated authentication setup. Usually involving a php script to authenticate against. Maybe you want to use an existing mySQL or mariaDB database to set up users and channels? Fear not, this is not that complicated to start out with.

Server side configuration

Starting from this example, we set up a basic rtmp section:

rtmp {
  server {
    listen 1935;
	ping 30s;
	notify_method get;
	application stream {
	  live on;
	  on_publish http://yourdomain.com/rtmp_auth.php;
	  record off;


Most people who stream enjoy using services such as Twitch.tv or Ustream to deliver video to viewers, and that works well enough. But sometimes you want some more control over your stream, or you want other people to be able to stream to you, or you want to stream to multiple places, or any number of things that requires you to have access to an actual RTMP stream from an RTMP server. This guide will cover the very basics of setting up a simple RTMP server on a Linux computer. Don’t worry, it’s not too complicated, but having familiarity with Linux will certainly help.

A couple things you can do with your own RTMP server that you might be interested in:

Alright, so how do you do these kinds of things?


Heute mal was nützliches.
Natürlich dürft ihr das nachfolgende Wissen nicht anweden, wenn ihr nicht die Erlaubnis dazu habt.
Aber wer würde das denn schon tun? 😉

Reverse SSH Shell
Ihr habt bestimmt davon schonmal gehört.

Einen SSH-Revere Tunnel benötigt man um beispielsweise auf einen Rechner zuzugreifen, der hinter einem Firewallsystem steht und zwar selbst ins Internet kommt, jedoch eine sogenannte private IP-Adresse besitzt. Da man den Rechner von ausserhalb nicht erreichen kann, muss dieser von innen einen SSH-Tunnel (ggf. durch die Firewall) zu einem externen Rechner aufbauen. Bis dahin wäre das ein „normaler“ SSH-Tunnel. Dieser wird aber so eingerichtet, dass er auch Verbindungen von externen Rechner nach innen zulässt.

Beispielsweise Verwendungszwecke:
– Testserver im Unternehmen an dem man von daheim weiterarbeiten möchte
– Heimserver im Studentenwohnheim
Backdoor in gehackten Geräten (natürlich macht das keiner) 😉