Centroid.EU Blog

Wildcarddnsd 0.9.0 Beta Release next Week

November 8th, 2014

One more week. I did some finishing touches today and then next week the BETA_9 release will be done. Be sure to download your copy if you've been using Wildcarddnsd, then. Also this may be the last release with the Wildcarddnsd name, I've been thinking of renaming it to avoid confusions that happen to pop up once in a while. The wildcarddnsd home page is at wildcarddns.centroid.eu.

0 comments

---

Graphing DNS queries

November 5th, 2014

DNS doesn't take much traffic when the TTL is high enough. (like mine). I have graphed a few weeks worth of wildcarddnsd data, spikes are probably when I wrote to a mailing list.

I was graphing most of yesterday and decided to do the above today as well. RRDTOOL++!

0 comments

---

Careful of a FritzBox downgrade!

November 2nd, 2014

I downgraded my Fritzbox from 6.20 to 6.04, and it turns out the saved config is not backwards compatible. So after a lot of trying and not finding the DSL access codes I had to take it back to 6.20 and restore the config. It's a good thing that was possible. I then utilized my UDPTUNNEL program this morning and it's working like a charm. I guess the FB analyses TCP and does bad things with it.

0 comments

---

Upgraded Uranus(computer) to OpenBSD 5.6

October 30th, 2014

With patches (errata) applied, it looks like this:

# sysctl kern.version
kern.version=OpenBSD 5.6 (URANUS.MP) #0: Thu Oct 30 09:57:34 CET 2014
    pjp@uranus.centroid.eu:/usr/src/sys/arch/i386/compile/URANUS.MP

I'll do the rest on saturday when packages are available.

0 comments

---

Proud owner of 5.6 CD's

October 29th, 2014

I have made prepwork to make mercury 5.6 tomorrow and I'll do the rest of the network here on saturday I guess. Yes OpenBSD!

0 comments

---

When TCP is blocked/manipulated...

October 26th, 2014

then we tunnel! In the following article I showed proof that the DTAG network is screwed up. The problem persists, and I have done a new thing to circumvent this screwing up. I have started to tunnel.

$ ifconfig gif0
gif0: flags=8051 mtu 1280
        priority: 0
        groups: gif
        tunnel: inet 149.210.171.149 -> 84.170.171.225
        inet6 fe80::ca5:8ff4:dd1c:99fb%gif0 ->  prefixlen 64 scopeid 0x6
        inet 10.0.0.2 --> 10.0.0.1 netmask 0xff000000

right now everything works as it should and I have none of the retransmission and delays I was talking about earlier. This is further proof that DTAG is using some sort of Deep Packet Inspection that causes these screwups.

# ping 10.0.0.2 
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=58.851 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=62.127 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=64.028 ms
--- 10.0.0.2 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 58.851/61.668/64.028/2.157 ms

Nuff said.

0 comments

---

On my Christmas wish list: Book of PF

October 25th, 2014

The third edition of the Book of PF is out. I'm putting this on my christmas wishlist, if not then, then I'll buy it next year as my book budget for this years is exhausted.

0 comments

---

Mytd, my tcp traceroute daemon

October 22nd, 2014

Yesterday I programmed this daemon based on last months tcp traceroute server. It's actually pretty cool, it sandboxes a lot of processes and uses descriptor passing when a function needs root credentials, the socket in question is always passed back to the non-privileged process. Here is a traceroute in process this is how it looks:

$ ps auxwww|grep mytd 
root     13350  0.0  0.1   412   644 ??  Ss     9:52AM    0:00.00 mytd: master (mytd)
nobody   18672  0.0  0.1   476   808 ??  S      9:52AM    0:00.00 mytd: icmp listener (mytd)
root     29102  0.0  0.1   444   680 ??  S     10:59AM    0:00.00 mytd: ttl setter (mytd)
nobody   14652  0.0  0.1   624   924 ??  S     10:59AM    0:00.00 mytd: connection from 188.174.195.165 (mytd)

It's a looking glass traceroute, the traceroute looks a little like this:

mercury$ telnet supercluster.virgostar.net 1111
Trying 2a01:7c8:aaac:365::1...
telnet: connect to address 2a01:7c8:aaac:365::1: No route to host
Trying 149.210.171.149...
Connected to supercluster.virgostar.net.
Escape character is '^]'.
now sending you the traceroute, please wait...
now sending you the traceroute, please wait...
1 149.210.171.1
2 87.253.141.241
3 80.249.208.212
4 82.197.128.21
5 217.71.96.118
6 217.71.96.6
7 217.71.97.150
8 188.174.195.165
9 188.174.195.165
10 188.174.195.165
done.
Connection closed by foreign host.

I'm making the source code of this available here. Enjoy.

0 comments

---

I have a new VPS!

October 19th, 2014

I'm very excited to give you the news. This one is called supercluster.virgostar.net and I got it from transip.eu. The VPS was almost immediately available but I had to install the OS on a HTML5 console (wicked!). It costs me about 10 euros a month.

0 comments

---

Wiping Keys / Secrets (so important)

October 18th, 2014

I examined some software the other day that encrypts passwords. This particular software doesn't wipe it's master key after use on the stack, so I was able to write a proof-of-concept on my raspberry pi, that reads the key from the stack when the database is accessed. Not knowing which is the key though one must run through all offsets in the dumpfile in order to crack the database, but that shouldn't be expensive in processor time.

The authors of Cryptography Engineering, write about this too in section 21.10, that wiping keys after they are done with should be wiped "as soon as a secret is no longer needed".

Some security concious programs even store sensitive keys privsep'ed process and wipe as much as possible.

So lessons learned are:

1. don't share your UNIX account with anyone else
2. wipe keys when finished with them
3. privsep keys when possible

Who would I like to thank? Everyone that helped me get to this conclusion.

0 comments

---