Centroid.EU Blog

(this blog is mostly encrypted - adults only)

Wildcarddnsd now has RFC 1996 (Notify) master-only support

May 17th, 2014

I tested this and it seems to work. Unfortunately I wasn't able to test the IPv6 part of it, I lack an IPv6 master server.

0 comments

The NSA, 1 year after Snowden

May 14th, 2014

Before the Snowden revelation there was the Warnings.

and after the Snowden revelation I've expressed:

and Solutions

But in conclusion there is nothing we can do. The NSA will still listen in and backdoor equipment for as long as they can. There really is not much we can do if we want to continue using the Internet. Change will be slowly as recommendations are to phase out american equipment in order to be entirely safe. And then we're still not safe. Take it in stride. At least we have an inner clock that tells us that something is wrong with all this, but we mainly (or I mainly) aren't ready to hear it. It's like meeting aliens for the first time, we won't be ready.

0 comments

OpenBSD load sharing at the switch level

May 13th, 2014

Since I got my new computer I've set up a virtual lab with 5 QEMU vm's. I want to show you an idea of mine that will drastically reduce load on a set of routers seperated by a bridge. The idea is this: the lower you go in OSI layers the less load. So you could have a setup like so:



                                [0]		ISP router (layer 3)
                                 |
                                [1]		switch lev 0 (layer 2)
                               /   \ 
                             [2]   [3]		switch lev 1 (layer 2)
                            /  |   |  \
                          [4] [5] [6] [7]	router lev 0 (layer 3)

Pretend you get a lot of pps (packets per second) or traffic that an OpenBSD box can't handle. The idea in the above picture is to distribute the load on layer 2 which has a lot less overhead than layer 3 (IP routing), so if you have node 1, 2 and 3 be switches that round-robin their frames, the load will be reduced by the time the frames get to nodes 4, 5, 6, and 7. I call a router/switch a node here somethign with 3+ interfaces. So how would that work without causign a mess? Well I set it up in the lab and I only went as far as nodes 0, 1, 2, 3 and 4. The concept should work with another few sets of switch levels but I'm gonna keep it short. Here is the setup on node1:

$ for i in /etc/hostname.*; do echo $i; cat $i; done
/etc/hostname.bridge0
add em0 add trunk0
up
/etc/hostname.em0
inet 10.0.0.2 255.255.255.0
/etc/hostname.em1
up
/etc/hostname.em2
up
/etc/hostname.trunk0
trunkproto roundrobin 
trunkport em1 trunkport em2
up

As you can see I have added interfaces em1 and em2 to trunk0 which round robins and added that with em0 to bridge0. This works! Interface em0 doesn't need an IP but I put one on so I can reach it in the test environment. You can add another interface for out of band access. Now then for nodes 2 and 3 the magic happens: Node2:

$ for i in /etc/hostname.*; do echo $i; cat $i; done
/etc/hostname.carp0
inet 10.20.0.2 255.255.255.0 
vhid 1
up
/etc/hostname.em0
lladdr 00:11:22:33:44:89
up
/etc/hostname.em1
inet 10.20.0.3 255.255.255.0
/etc/hostname.trunk0
inet 10.0.0.24 255.255.255.0
trunkport em0
up
!/usr/sbin/arp -s 10.0.0.2 68:03:09:13:04:07
!/usr/sbin/arp -s 10.0.0.254 fe:e1:ba:d3:a9:46
!/usr/sbin/arp -s 10.0.0.1 68:03:09:13:99:07

Node3:

$ for i in /etc/hostname.*; do echo $i; cat $i; done
/etc/hostname.carp0
inet 10.20.0.2 255.255.255.0
vhid 1
up
/etc/hostname.em0
lladdr 00:11:22:33:44:89
up
/etc/hostname.em1
inet 10.20.0.4 255.255.255.0
/etc/hostname.trunk0
inet 10.0.0.24 255.255.255.0
trunkport em0
up
!/usr/sbin/arp -s 10.0.0.2 68:03:09:13:04:07
!/usr/sbin/arp -s 10.0.0.254 fe:e1:ba:d3:a9:46
!/usr/sbin/arp -s 10.0.0.1 68:03:09:13:99:07

As you can see here the link layer address on both has been set to the same MAC address, and the network layer address as well (10.0.0.24). I had to set static ARP because return packets in the round robin on node 1 would not guarantee that ARP replies would come back to the node that asked for it. It can answer ARP though because for all it cares or knows (on either node 2 or 3) that this is it's own address. Access to these boxes can only be granted on the em1 interface or on an out of band interface. I have carped the em1 interface which goes to node 4 which is a user host. From there I want to show you a ping and a traceroute to node 1.

$ ping -c 4 10.0.0.1 
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=254 time=3.270 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=254 time=3.057 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=254 time=3.172 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=254 time=2.779 ms
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 2.779/3.069/3.270/0.192 ms

$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets
 1  10.20.0.4 (10.20.0.4)  2.653 ms  1.634 ms  1.187 ms
 2  10.0.0.1 (10.0.0.1)  3.364 ms  2.917 ms  2.943 ms

As you can see all packets make it. I had to disable pf(4) on nodes 2 and 3, as there was a state syncronization problem. This can be fixed with pfsync(4) but is another project worth. Also make sure that both CARP interfaces don't go into MASTER mode. Or else this causes DUP!'s (duplicate packets) in ping. This happened to me just as I was wrapping up. I hope you can build extra capability with this idea if only 1 router would not have been enough for the load behind the ISP (node 0).

0 comments

Happy 1400000000

May 13th, 2014

UNIX timestamp just wrapped over a bit more than an hour ago..

# date -r 1400000000
Tue May 13 18:53:20 CEST 2014

The next one is in 3 years and a month or so.

0 comments

Wildcarddnsd now has NAPTR support

May 11th, 2014

I wanted to get this in so I can try out ENUM services. NAPTR (stands for Naming Authority Pointer) Resource Record is used in VOIP a lot. It helps reading the RFC (which I admittedly have not done fully) to get a better idea of what it does. RFC 2915. Joy!

0 comments

Wildcarddnsd now has EDNS0 support

May 10th, 2014

I just committed the last bits. EDNS0 (RFC 6891) allows greater UDP sized packets than the RFC 1035 specification of 512 bytes per answer. This now opens the door for me to do NAPTR RR and DNSSEC which is on my Todo list. BTW RFC 6891 replaces RFC 2671 which was so impossible to figure out that I had to wait until a new RFC came on the scene. Thanks Vixie (at least he polished it)!

0 comments

Administrivia and future plans network wise

May 7th, 2014

I have added ratelimiting to io.solarscale.de which runs nsd. For this the nsd needed a recompile. This literature on the web was very helpful: nsd-ratelimit. I have set it to 12 queries per second, same as wildcarddnsd's ratelimit on americas.centroid.eu.

I have evaluated a lot of scenarios on how I want to reorganize my network and I have decided to get a DSL with static IP's in February 2015 again. I'll be running a wildcarddnsd from home again. Earlier in september 2014 my vps moon.virgostar.net will expire, I'll take it out of active DNS duty possibly in august. I'll run with 2 nameservers from that point on until 2015. In february I'm also going to get rid of the io.solarscale.de vps possibly for a transip.eu (amsterdam) vps instead (which will run OpenBSD). This is still in the clouds (so to speak) so I'm not entirely positive on that.

And to test the transip.eu vps I'll possibly get that in november 2014 possibly after the Wildcarddnsd 0.9.0 BETA release. So a lot of shuffling is taking place, the only thing that won't change is americas.centroid.eu which is prepaid until 2016, unless they figure out how to hypervisor OpenBSD in bhyve, which I will then probably take.

0 comments

Wildcarddnsd now has packet rate limiting

May 5th, 2014

I don't think I've ever had someone use me for an amplification DoS attack, but I don't watch the logs all the time. However it's not impossible so I have added a rate limiting algorithm on the hash of the IP querying my server so that I will drop the query when a threshold is reached. I had given this implementation thought for a while now and finally I wrote out the code. Wildcarddnsd will use more memory depending on the packets per second (details) and the hash of IP addresses is limited to 16 bit, meaning that there can be collisions between unrelated IP addresses that cause the ratelimiting to snare. But a high enough rate limit of say 12 packets per second on a nameserver with a usual TTL of 1 day shouldn't cause a problem. The pps is definable between 1 packet per second and 127 packets per second. The maximum setting will consume up to 120 MB of RAM, but RAM is cheap when we talk about 120 MB's. :-) I'm pretty happy right now.

0 comments

Got OpenBSD 5.5 in the mail yesterday

May 4th, 2014

I got my pre-ordered OpenBSD CD's in the mail. Unfortunately the seal was broken so someone possibly tried these out. Also I already upgraded my entire network to 5.5 on May 1st. Let this be a warning to OpenBSD, release pre-orders early or be faced with us doing ftp installs! We can't wait we're that hooked! However the CD's are quality like always, it's just too bad these become cup coasters after half a year, but that's part of the product that someone should know about.

0 comments

Two "racing" ARP's

April 28th, 2014

OpenBSD is different than other OS's in that it has a reverse ARP channel open alongside a forward ARP channel. I tried to exploit this with one of my programs I wrote, since frames are in sequence and scheduling in the OpenBSD kernel is done in a FIFO manner.

20:33:05.793519 bc:ee:7b:dd:2e:5a ff:ff:ff:ff:ff:ff 0806 60: arp who-has \
192.168.34.1 (ff:ff:ff:ff:ff:ff) tell 192.168.34.5
  0000: ffff ffff ffff bcee 7bdd 2e5a 0806 0001  ........{..Z....
  0010: 0800 0604 0001 bcee 7bdd 2e5a c0a8 2205  ........{..Z..".
  0020: ffff ffff ffff c0a8 2201 3100 0000 0000  ........".1.....
  0030: 0000 0000 0000 0000 0000 0000            ............

20:33:05.793572 bc:ee:7b:dd:2e:5a ff:ff:ff:ff:ff:ff 8035 60: arp who-has \
192.168.34.1 (ff:ff:ff:ff:ff:ff) tell 192.168.34.5
  0000: ffff ffff ffff bcee 7bdd 2e5a 8035 0001  ........{..Z.5..
  0010: 0800 0604 0001 bcee 7bdd 2e5a c0a8 2205  ........{..Z..".
  0020: ffff ffff ffff c0a8 2201 3200 0000 0000  ........".2.....
  0030: 0000 0000 0000 0000 0000 0000            ............

Here you see two outgoing ARP's the first, a forward ARP is .000053 seconds before the second one a reverse ARP (seen here with a 8035 ethernet type).

20:33:05.793773 00:90:0b:19:56:06 bc:ee:7b:dd:2e:5a 0806 60: arp reply \
192.168.34.1 is-at 00:90:0b:19:56:06
  0000: bcee 7bdd 2e5a 0090 0b19 5606 0806 0001  ..{..Z....V.....
  0010: 0800 0604 0002 0090 0b19 5606 c0a8 2201  ..........V...".
  0020: bcee 7bdd 2e5a c0a8 2205 3200 0000 0000  ..{..Z..".2.....
  0030: 0000 0000 0000 0000 0000 0000            ............

20:33:05.793774 00:90:0b:19:56:06 bc:ee:7b:dd:2e:5a 0806 60: arp reply \
192.168.34.1 is-at 00:90:0b:19:56:06
  0000: bcee 7bdd 2e5a 0090 0b19 5606 0806 0001  ..{..Z....V.....
  0010: 0800 0604 0002 0090 0b19 5606 c0a8 2201  ..........V...".
  0020: bcee 7bdd 2e5a c0a8 2205 3100 0000 0000  ..{..Z..".1.....
  0030: 0000 0000 0000 0000 0000 0000            ............

Here you see the return frames. The reverse (indicated by the number 2 in offset 0x2A) beat the forward reverse (indicated by number 1) by 0.000001 seconds, it even made up time in the TCP IP stack on the remote OpenBSD router. The reason this is, is that the reversearp does not get scheduled inside the NETISR and thus is a lot faster, it pre-empts the packet that went in before it.

These are net-games but this can be used to test the network stack load on an OpenBSD host/router to look for how much usage it gets. That in itself isn't an exploitation though.

0 comments