US-CERT releases virtual appliance for MitM attacks

August 24, 2014

Some time ago I wrote a blog post on Burp as a MitM Proxy (Man-in-the-Middle) – now there is for some purposes an even easier way. The US-CERT has released the first version of a virtual appliance with the name Tapioca (Transparent Proxy Capture Appliance). With it, it is easy to check if programs don’t do certificates validation correctly. I really recommend to try it out! Some areas that are often good for a bad implementations are: mobile apps, hardware and embedded devices and generally stuff that needs a high domain specify know how and that often goes with less software engineering know how. 😉

Check if your mailserver is encrypting SMTP to/from other mail servers

August 10, 2014

For  readers with their own mail server (or if you want to check what your provider is doing) – verify that your mail server accepts encrypted communication and that PFS is enabled.  Just click on this link and enter the domain name to test. Some big players goof there ….  It should at least look like in the screen shot. DANE would be cool, but that’s not that easy at this point as you need a working DNSsec DNS server, which not all registrars provide. Sure you can host your own authoritative DNS servers but that is work …

ps: send also a mail to [email protected] to check if sending mails is also encrypted. It should look like this:

My first IPv6 problem – multihoming my home network without NAT

Today I ran into my first IPv6 problem … all was easy so far for some years .. just configured it and it worked … but this weekend I deployed a second Internet connection for my home. With IPv4 and masquerading the internal IP addresses to the one provider-given IP addresses I was able on the router to configure which traffic goes out over which provider. If one provider fails the route is withdrawn and all goes over the other link. But now comes IPv6 and it is not that easy anymore, as my router does not support IPv6 NAT. The problem is described in detail in this nice blog post by Ivan Pepelnjak.

My router is able to do VRF (Virtual Routing and Forwarding) also for IPv6 (at least the documentation says so .. didn’t try it so far). So the “best” option for me seems to advertise both subnets the providers gave me to the clients  and route source based to the providers. Without VRF I would be depended that the providers don’t do a RPF (Reverse Path Forwarding) check, which is also not a good idea. But this leads to the problem that the end device decides which uplink it uses, which is most likely not the one I would choose ….

An other idea was to use one of my servers in a data center to tunnel the traffic through. Basically running two IP tunnels from my router to the server (one via each provider) and using IP addresses that are routed from the Internet to the server. But this is also not a good solution.

Anyway I don’t have good solution so far, maybe one of my readers does.

 

Slow DNS resolving with Linux systems against Windows DNS server

August 1, 2014

In the last days I encountered a problem with the DNS resolution by our Linux systems – must be there for a long time but it took a deep look into a different performance problem to get this one figured out. I did a simple wget to a HTTP site in the same data center and it took sometimes 5 seconds to get DNS name resolved to an IP address. As a network guy I launched tcpdump at once and did see following packets:

10:59:19.264987 IP LinuxClient.51463 > WindowsDnsServer.domain: 57223+ A? xxxx.penz.name. (35)
10:59:19.265056 IP LinuxClient.51463 > WindowsDnsServer.domain: 26702+ AAAA? xxxx.penz.name. (35)
10:59:19.265700 IP WindowsDnsServer.domain > LinuxClient.51463: 26702* 0/1/0 (103)

10:59:24.269981 IP LinuxClient.51463 > WindowsDnsServer.domain: 57223+ A? xxxx.penz.name. (35)
10:59:24.270303 IP WindowsDnsServer.domain > LinuxClient.51463: 57223* 1/0/0 A 10.10.xxx.xxx (51)
10:59:24.270370 IP LinuxClient.51463 > WindowsDnsServer.domain: 26702+ AAAA? xxxx.penz.name. (35)
10:59:24.270557 IP WindowsDnsServer.domain > LinuxClient.51463: 26702* 0/1/0 (103)

As you see the first A query gets not answered but the AAAA does. I changed to an other DNS server (first Windows 2008 R2 and the second Windows 2012 R2)  but with the same results. I did tests with RHEL6/Centos6 and Ubuntu 14.04 .. no difference. As a next step I talked with the Windows guys to look at the Windows 2012 R2 DNS server. They did a packet capture and saw that the Windows server did not send that packet, but a DNS Debug log showed that the DNS server it self did answer it. I than called wget with the “–inet4-only” option, which made sure that only a A query was sent and I was not able to reproduce the problem. So it must be something with the second packet.

Getting a tip from a fellow network admin who said I should look at the source port of the packets I did so. The UDP source ports of the A and AAAA were the same and it looked like that the Linux system gets an answer if the A query is answered before the AAAA arrives on the Windows Server. The next step was to look for a way to change that behavior on the Linux side, which looked to me easier than to change something on the Windows site. 😉

Following resolv.conf option looked promising:

single-request-reopen (since glibc 2.9)
The resolver uses the same socket for the A and AAAA requests. Some hardware mistakenly sends back only one reply. When that happens the client system will sit and wait for the second reply. Turning this option on changes this behavior so
that if two requests from the same port are not handled correctly it will close the socket and open a new one before sending the second request.

And yes – that was the solution. On every system I added

options single-request-reopen

to the /etc/resolv.conf the problem went away. For systems which generate the resolv.conf automatically (like Ubuntu 14.04), which you can check by

ll /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Mai 26 12:35 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

you should add the line to /etc/resolvconf/resolv.conf.d/base instead and call sudo resolvconf -u afterwards.

All together this problem took me many hours to find and I didn’t find anything on the net .. so I thought a post may help other poor admins. 😉