DNS tunnelling is just another tunnelling technique. Usually, it is called VPN over DNS too, it is just naming. What it makes it very popular is that not all carriers or network administrators are aware of it or if they are, they don't know exactly how to stop it. Rogers, one of the biggest telecommunication carrier in Canada and Telcel the biggest player of mobile telephony in Mexico, both allow DNS tunnelling (I don't doubt others carriers do as well), so when you run out of data in your plan you can still connect if you configure it in your mobile. This is because smartphones need to connect to some carrier servers regardless if you have right to 2G/3G/4G data access or not; smartphones still have access to the local DNS server. Local networks have the same symptom because DNS is used to access many IT services like the Active Directory, it is very difficult to differentiate between a true legitimate DNS query and DNS tunnelling traffic without proper tools.
Because of this, I am going to describe how this technique works.
This is new to me. Since CentOS 7.3, there have been some security changes. Among those changes, it is the use of the PrivateTmp flag in many services, and of course, Apache is one of them. For those who are more curious about what this flag means, here it is the manual text:
Takes a boolean argument. If true, sets up a new file system namespace for the executed processes and mounts private /tmp and /var/tmp directories inside it that is not shared by processes outside of the namespace. This is useful to secure access to temporary files of the process, but makes sharing between processes via /tmp or /var/tmp impossible. If this is enabled, all temporary files created by a service in these directories will be removed after the service is stopped. Defaults to false. It is possible to run two or more units within the same private /tmp and /var/tmp namespace by using the JoinsNamespaceOf= directive, see systemd.unit(5) for details. Note that using this setting will disconnect propagation of mounts from the service to the host (propagation in the opposite direction continues to work). This means that this setting may not be used for services which shall be able to install mount points in the main mount namespace.
I am going to explain an Issue I had with one of my customer's PBX.
Last week, one of my very best customers asked me to do a dial plan that forwards an incoming call to an external server. So far, that can be done with a bridge statement pointing to sofia/internal/xxxx@server. But it was more complex as it seemed. The system administrator of the remote server claimed that no calls were arriving.
I did put a sniffer with tcpdump and found the SIPI INVITE signal as follows:
23:01:05.856957 IP (tos 0x0, ttl 64, id 8448, offset 0, flags [none], proto UDP (17), length 1541)
999.999.999.999.sip > 888.888.888.888.sip: SIP, length: 1513
Via: SIP/2.0/UDP 999.999.999.999;rport;branch=
CSeq: 102235968 INVITE
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
o=FreeSWITCH 1485122965 1485122966 IN IP4 999.999.999.999
c=IN IP4 999.999.999.999
m=audio 21100 RTP/AVP 0 102 103 9 8 3 101 13
So far so good this seemed pretty wel. However, after some retries, I found this:
23:01:11.683409 IP (tos 0x0, ttl 54, id 29990, offset 0, flags [none], proto ICMP (1), length 576)
888.888.888.888 > 999.999.999.999: ICMP ip reassembly time exceeded, length 556
IP (tos 0x0, ttl 54, id 8445, offset 0, flags [+], proto UDP (17), length 1500)
You do not need to be very smart to realize that this issue is related to IP fragmentation. As I didn't have access to the remote server or any kind of communication, I decided to do the minimizing approach.