Tag Archives: FreeBSD

Tarpit support in Pen

Pen 0.32 will have built-in tarpit support in its Direct Server Return mode. The feature is enabled by specifying an access control list against which incoming requests are matched. Matching destination addresses will make Pen do two things:

1. Reply to ARP requests to such addresses.
2. Reply to TCP SYN with SYN+ACK.

The idea behind tarpitting is to slow down network scanning by giving lots of false positives. Pen does this with very little load and without having to manage any state.

Here is an example command line.

pen -df -O “acl 1 permit 192.168.2.11” -O “tarpit_acl 1” -O “dsr_if eth1” 192.168.2.10:80 192.168.2.2 192.168.2.3

Let’s go through that option by option.

acl 1 permit 192.168.2.11 creates an entry in access list 1 which matches IP address 192.168.2.11. All other IP addresses will be rejected.

tarpit_acl 1 makes Pen use access list 1, the one with 192.168.2.11 as its sole entry, to match destination addresses.

dsr_if eth1 makes Pen use eth1 as the network interface where all direct server return processing is performed.

192.168.2.10:80 is the address and port where Pen listens for legitimate requests. They will be forwarded to the backend servers.

192.168.2.2 and 192.168.2.3 are the backend servers. They have web servers listening on port 80 and IP address 192.168.2.10 configured on a loopback interface. See the Wiki.

Let’s try making a legitimate request.

ulric@debtest:~/Git/pen$ curl http://192.168.2.10/cgi-bin/remote_addr
192.168.1.1

That worked fine. Frames from us go to Pen, Pen forwards them to one of the web servers, the web server replies directly to us. In Wireshark we see:

dsr

But what happens when we try the same thing on a tarpitted address?

ulric@debtest:~/Git/pen$ curl http://192.168.2.11/cgi-bin/remote_addr
^C

It just hangs. We send SYN, Pen replies with SYN+ACK, we send ACK and think that the TCP handshake is done. So we send the HTTP request, which Pen ignores. We send it again. Pen ignores it again, and so on. Here’s what that looks like in Wireshark:

tar

Access control lists are a very flexible way to control the tarpit functionality in Pen and have it tarpit every address in a subnet (except those that shouldn’t). As an example, think of a network with the following hosts:

192.168.2.1 gateway
192.168.2.2 web server 1
192.168.2.3 web server 2
192.168.2.10 load balanced address

The corresponding ACL would be created like this:

acl 1 deny 192.168.2.1
acl 1 deny 192.168.2.2
acl 1 deny 192.168.2.3
acl 1 deny 192.168.2.10

Anything Pen sees that is not destined for one of these addresses will be tarpitted.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Direct Server Return for UDP

Pen has supported Direct Server Return for TCP for some time. Support for UDP has now been added, suitable for load balancing e.g. DNS.

Here, debian2 is the DNS client and debian uses Pen in DSR mode to load balance between debian3 and debian4 running Bind.

Pen command line:

ulric@debian:~/Git/pen$ sudo ./pen -df -U -O poll -O “dsr_if eth1” -S 2 -r 192.168.100.1:0 192.168.100.3 192.168.100.4
As of 0.28.1 the server table is expanded dynamically,
making the -S option obsolete
2015-08-03 16:24:09: read_cfg((null))
2015-08-03 16:24:09: Before: conns = (nil), connections_max = 0, clients = (nil), clients_max = 0
2015-08-03 16:24:09: expand_conntable(500)
2015-08-03 16:24:09: After: conns = 0x1ac4600, connections_max = 500, clients = 0x7f6428d5c010, clients_max = 2048
2015-08-03 16:24:09: pen 0.29.0 starting
2015-08-03 16:24:09: servers:
2015-08-03 16:24:09: 0 192.168.100.3:0:0:0:0:0
2015-08-03 16:24:09: 1 192.168.100.4:0:0:0:0:0

As far as debian2 can see, the responses are coming from a single DNS server:

dsr-udp-client

But tcpdump on debian3 and debian4 shows requests and replies being load balanced across the hosts:

dsr-udp-server1

dsr-udp-server2

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Pen 0.29.0 released

Available here:

http://siag.nu/pub/pen/

And also here:

https://sourceforge.net/projects/penloadbalancer/files/Source/

Pen 0.29.0 introduces transparent reverse proxying on supported platforms,
which currently means Linux, FreeBSD and OpenBSD. This allows the backend
servers to see the client’s real address. It can be used in combination
with SSL termination.

Another improvement is that the server table size is no longer fixed
at startup but grows dynamically as servers are added. The -S option is
still accepted but doesn’t do anything. The client and connection tables
can also be expanded on the fly, reducing the number of restarts.

Full list of changes from 0.28.0:

150608 Released 0.29.0.

150528 Transparent reverse proxy support for Linux, FreeBSD and OpenBSD.

150527 Allow the client table size to be updated on the fly. Default size still 2048.
Allow the connection table size to be updated in the fly. Default still 500.
See penctl.1, options clients_max and conn_max.

150526 Introduced the macro NO_SERVER to be used instead of -1 to signify
error conditions and such.
Removed the fixed server table size along with the -S option.

150525 Fixed cosmetic bug in startup code which required port to be specified
on backend servers even if it was the same as the listening port.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Transparent Reverse Proxy on FreeBSD

A previous post described how to get transparent reverse proxy to work with Pen on Linux. The same functionality is available on FreeBSD.

The FreeBSD host running Pen has IP addresses 192.168.100.11 on em1 and 192.168.101.11 on em2. Like before, the client debian2 has IP address 192.168.100.2 and the server debian3 has IP address 192.168.101.3.

FreeBSD requires far less in the way of special preparations than Linux did in the earlier post; in fact, a single firewall rule is all we need:

ipfw add 10 fwd 127.0.0.1 tcp from any 5001 to any in recv em2

The Pen command is the same whether on Linux or FreeBSD:

sudo ./pen -df -O transparent 192.168.100.11:5001 192.168.101.3

And as before, the client sees a connection from 192.168.100.2 to 192.168.100.11, while the server sees a connection from 192.168.100.2 to 192.168.101.3.

transparent-client-freebsd

transparent-server-freebsd

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Pen 0.28.0 released

Available here:

http://siag.nu/pub/pen/

And also here:

https://sourceforge.net/projects/penloadbalancer/files/Source/

Pen 0.28.0 brings Direct Server Return on Linux and FreeBSD.

It also brings the Windows code up to speed.

Full list of changes from 0.27.5:

150520 Released 0.28.0.

150513 Numerous updates to support the madness that is Windows.

150501 Fix from Vincent Bernat: segfault when not using SSL.

150427 DSR support using Netmap on FreeBSD.
Unbroke DSR on Linux.

150424 Replaced all calls to perror with debug(…, strerror(errno);
Updated penlog and penlogd to use diag.[ch].

150422 More refactoring: broke out conn.[ch], client.[ch], server.[ch],
idler.[ch].
Made a hash index such that the load balancer may balance load.

150420 Broke out Windows code from pen.c into windows.c. Added windows.h.

150419 Broke out public definitions for dsr into dsr.h.
Broke out memory management into memory.[ch].
Broke out dignostic and logging functions into diag.[ch].
Broke out settings into settings.[ch].
Broke out access lists into acl.[ch].
Broke out event initialization into event.[ch].
Added pen_epoll.h, pen_kqueue.h, pen_poll.h, pen_select.h.
Broke out pen_aton et al into netconv.[ch].

150416 Added dsr.c

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Comparing Raw Networking on Linux and FreeBSD

Direct Server Return requires raw access to network traffic. There is no portable way to do that, so Pen supports it so far only on Linux and FreeBSD.

On Linux, the probe into the network stack is created pretty much like any other socket:

fd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);

It works literally like a probe, the packets are duplicated out and received both by the kernel and by the program creating the socket, Pen in this case. Care must be taken to prevent the kernel from interferring, for example by responding to TCP traffic.

Reading and writing is as usual:

recvfrom(fd, buf, MAXBUF, 0, NULL, NULL);
sendto(fd, b, len, 0, NULL, 0);

FreeBSD has a totally different solution called Netmap:

d = nm_open(ifname, NULL, 0, 0);

Here, d is not a socket but a “netmap descriptor” and reading and writing is done to rings of buffers, matching what is available in the network card. The regular network stack is cut off from the traffic. The details are hidden behind a pcap-like api:

nm_nextpkt(d, &h);
nm_inject(d, b, len);

Now, wouldn’t it be fun to compare these two? Of course it would!

Two VMs are prepared with Apache and the address 192.168.100.1 on a loopback interface.

One VM runs ApacheBench like this:

ab -c 20 -n 10000 http://192.168.100.1/1000k

One Linux and one FreeBSD VM are prepared with the latest Pen from Git. On Linux the command line looks like:

sudo ./pen -df -O poll -O "dsr_if eth1" -S 2 -r 192.168.100.1:0 192.168.100.3 192.168.100.4

And on FreeBSD:

sudo ./pen -df -O poll -O "dsr_if em1" -S 2 -r 192.168.100.1:0 192.168.100.3 192.168.100.4

I.e. exactly the same, only the interface name differs.

Linux results here, ~0.9 Gbps:

ab-linux

And FreeBSD results, ~1.4 Gbps:

ab-freebsd

Facebooktwittergoogle_plusredditpinterestlinkedinmail