the Nmap Project's packet sniffing library for Windows - Npcap

Npcap is an update of WinPcap to NDIS 6 Light-Weight Filter (LWF) technique. It supports Windows Vista, 7, 8 and 10 . It is sponsored by the Nmap Project and developed by Yang Luo under Google Summer of Code 2013 and 2015 . It also received many helpful tests from Wireshark and NetScanTools .

Features

1. NDIS 6 Support : Npcap makes use of new NDIS 6 Light-Weight Filter (LWF) API in Windows Vista and later (the legacy driver is used on XP). It's faster than the deprecated NDIS 5 API, which Microsoft could remove at any time.
2. Extra Security : Npcap can be restricted so that only Administrators can sniff packets. If a non-Admin user tries to utilize Npcap through software such as Nmap or Wireshark, the user will have to pass a User Account Control (UAC) dialog to utilize the driver. This is conceptually similar to UNIX, where root access is generally required to capture packets.
3. WinPcap Compatibility : If you choose WinPcap Compatible Mode at install-time, Npcap will use the WinPcap-style DLL directories c:\Windows\System32 and servcie name npf , allowing software built with WinPcap in mind to transparently use Npcap instead. If compatability mode is not selected, Npcap is installed in a different location C:\Windows\System32\Npcap with a different service name npcap so that both drivers can coexist on the same system. In this case, applications which only know about WinPcap will continue using that, while other applications can choose to use the newer and faster Npcap driver instead.
4. Loopback Packet Capture : Npcap is able to sniff loopback packets (transmissions between services on the same machine) by using the Windows Filtering Platform (WFP) . After installation, Npcap will create an adapter named Npcap Loopback Adapter for you. If you are a Wireshark user, choose this adapter to capture, you will see all loopback traffic the same way as other non-loopback adapters. Try it by typing in commands like ping 127.0.0.1 (IPv4) or ping ::1 (IPv6).
5. Loopback Packet Injection : Npcap is also able to send loopback packets using the Winsock Kernel (WSK) technique. User-level software such as Nping can just send the packets out using Npcap Loopback Adapter just like any other adapter. Npcap then does the magic of removing the packet's Ethernet header and injecting the payload into the Windows TCP/IP stack.
6. Raw 802.11 Packet Capture : Npcap is able to see 802.11 packets instead of fake Ethernet packets on ordinary wireless adapters. You need to select the Support raw 802.11 traffic (and monitor mode) for wireless adapters option in the installation wizard to enable this feature. When your adapter is in Monitor Mode , Npcap will supply all 802.11 data + control + management packets with radiotap headers. When your adapter is in Managed Mode , Npcap will only supply 802.11 data packets with radiotap headers. Moreover, Npcap provides the WlanHelper.exe tool to help you switch to Monitor Mode on Windows. See more details about this feature in section For softwares that use Npcap raw 802.11 feature . See more details about radiotap here: http://www.radiotap.org/

Documentation

Npcap Users' Guide

Build

Run installer\Build.bat : build all DLLs and the driver. The DLLs need to be built using Visual Studio 2013 . And the driver needs to be built using Visual Studio 2015 with Windows SDK 10 10586 & Windows Driver Kit 10 10586 .

Packaging

Run installer\Deploy.bat : copy the files from build directories to deployment directories and sign the files. Generate an installer named npcap-nmap-%VERSION%.exe using NSIS large strings build with the SysRestore plug-in (special build for Npcap) and sign the installer.

Generating debug symbols (optional)

Run installer\Deploy_Symbols.bat : copy the debug symbol files (.PDB) from build directories to deployment directories and package them into a zip file named npcap-nmap-<VERSION>-DebugSymbols.zip using 7-Zip .

Download Npcap

Read More

Monitor APs and Wifi clients on selected channel (Monitor Mode) for Window - WifiChannelMonitor

WifiChannelMonitor is a utility for Windows that captures wifi traffic on the channel you choose, using Microsoft Network Monitor capture driver in monitor mode, and displays extensive information about access points and the wifi clients connected to them. WifiChannelMonitor also allows you to view the information about wifi clients that are not connected to any access points, including the list of SSIDs (network names) that they are trying to connect.

For every access point, the following information is displayed: SSID, MAC Address, Device Manufacturer , PHY Type, Channel, RSSI, Security, Beacons Count, Probe Responses Count, Data Bytes, Retransmitted Data Bytes, and more...

For every client, the following information is displayed: MAC Address, Device Manufacturer, SSID list that the client tries to connect, Sent Data Bytes, Received Data Bytes, Probe Requests Count, and more...

System Requirements

• Windows 10/Vista/7/8/2012 - 32-bit or 64-bit. (In previous version of Windows , there is no support for wifi monitor mode)
• Microsoft Network Monitor 3.x - You can download and install it from this Web page or from this Web page .
• Wireless network adapter and a driver that works properly in 'monitor mode' under Windows. See the remarks about that in the 'Known Problems' section below, it's very important !!

You can also use WifiChannelMonitor to watch wifi information offline by importing a capture pcap file created under Linux with airodump-ng or wireshark. In this case, there is no need for capture driver and you can also use it under Windows XP.

WifiChannelMonitor vs Other Tools

Capturing data using monitor mode allows WifiChannelMonitor to show information that other wifi tools cannot get:

• Detect and show all wifi clients (Tablets, Smartphones, computers with wifi adapter, and so on... ), Including wifi clients that are not connected to any access point, but only tries to connect...
• For wifi clients that try to connect to one or more APs - WifiChannelMonitor displays the list of network names (SSIDs) that the wifi client tries to connect.
• WifiChannelMonitor can also detect clients with a wired connection to the router.
• WifiChannelMonitor shows the number of sent/received data bytes for every access point and for every wifi client connected to the access point.
• WifiChannelMonitor can show the name of hidden network. (The name is detected only when somebody connects this wireless network)

Start Using WifiChannelMonitor

Before you start capturing wifi data with WifiChannelMonitor, you have to install the Microsoft Network Monitor 3.x from this Web page or from this Web page. Except of the Microsoft Network Monitor driver, there is no need for any installation process or additional dll files.

In order to start using WifiChannelMonitor, simply run the executable file - WifiChannelMonitor.exe

After running WifiChannelMonitor, press F6 to start capturing in wifi monitor mode. On the 'Capture Options' window, you have to choose the correct wireless network adapter and the channel number you want to monitor. It's recommended to start monitoring with one of the 3 major wifi channels - 1, 6, or 11.

After choosing the channel and adapter, click the Ok button to start monitoring. After a few seconds, you should see the access points information in the upper pane. If you don't see any information , stop the capture (F7) , go to the 'Capture Options' window (F9) and try to change from 802.11n to 802.11g. After that press F6 to start the capture again.

Wifi Clients Modes (Lower Pane)

There are 3 different modes that you can view the wifi clients in the lower pane:

• Show Clients Of Selected AP:In this mode, WifiChannelMonitor only displays the wifi clients that are connected to the access point you select in the upper pane.
• Show All Clients:In this mode, WifiChannelMonitor displays all detected clients.
• Show All Clients Without AP:In this mode, WifiChannelMonitor displays all clients that are not connected to any access point.
• Show All Clients With AP:In this mode, WifiChannelMonitor displays all clients that are connected to access point.
• Show Only Clients+APs In My List:In this mode, WifiChannelMonitor displays only the clients and APs that appear in the MAC Addresses List (Ctrl+F8)

AP Columns Description

• SSID:The name of the wireless network
• MAC Address:MAC address of the access point.
• Company:Company that manufactured this access point, determined according to the MAC address.
• PHY Type:802.11g, 802.11n, and so on...
• Frequency:Channel frequency in MHz.
• Channel:Channel number.
• RSSI:Specifies the signal strength, in dBm. Some drivers don't provide the correct RSSI values in monitor mode.
• Security:None, WPA-PSK, WPA2-PSK, WPA-PSK + WPA2-PSK, WPA-EAP, WPA2-EAP, WPA-EAP + WPA2-EAP, or WEP.
• Cipher:None, WEP, TKIP, CCMP, TKIP+CCMP.
• Beacons:The total number of beacons sent by the access point. Beacon is a packet sent frequently by the access point and contains essential information that the wifi client need to identify and connect it.
• Probe Responses:The total number of times that the access point responded to a probe request sent by a wifi client.
• Data Bytes:Total number of data bytes sent and received by this access point.
• Retransmitted Data:Total number of retransmitted data bytes sent and received by this access point.
• Device Name:The name of the device. This value is displayed only for devices that support WPS.
• Device Model:The device model. This value is displayed only for devices that support WPS.
• WPS:Specifies the WPS status: No (No WPS Support), Configured, Not Configured, or Locked.
• Start Time:Displays the last time that access point was possibly started/restarted/rebooted. Be aware that some access points reset their timestamp periodically without restart/reboot action, and thus for these APs, the time value displayed on this column doesn't represent the correct start time.
• First Data Detected On:The first time that sent/received data was detected for this AP.
• Last Data Detected On:The last time that sent/received data was detected for this AP.

Wifi Client Columns Description

• MAC Address:MAC address of the wifi client.
• Company:Company that manufactured this wifi client, determined according to the MAC address. For example, if the wifi client is iPhone or iPad, you'll see 'Apple' in this column.
• RSSI:Specifies the signal strength, in dBm. Some drivers don't provide the correct RSSI values in monitor mode.
• SSID List:When wifi client tries to connect one or more access points, this field will display the list of network names (SSIDs) that this client tries to connect.
• Sent Data Bytes:Total number of data bytes sent by the client.
• Received Data Bytes:Total number of data bytes received by the client.
• Retransmitted Sent:Total number of retransmitted data bytes sent by the client.
• Retransmitted Received:Total number of retransmitted data bytes received by the client.
• Client Type:Wifi Client, Router, or Unknown. 
  Wifi Client means that this client uses wireless connection. 
  Router means that this client is the router (Yes... the router is also displayed as a client in the network). 
  Unknown means that this client uses wired connection or wireless connection.
• Device Name:The name of the device. This value is displayed only for devices that support WPS.
• Device Model:The device model. This value is displayed only for devices that support WPS.
• WPS:Specifies the WPS status: No (No WPS Support), Configured, Not Configured, or Locked.
• PHY Type:802.11g, 802.11n, and so on...
• Security:None, WPA-PSK, WPA2-PSK, WPA-EAP, WPA2-EAP, or WEP. This field is filled only when the client tries to connect the access point.
• Cipher:None, WEP, TKIP, CCMP, TKIP+CCMP. This field is filled only when the client tries to connect the access point.
• Probe Requests:Total number of probe requests sent by this client.
• First Detected On:The first date/time that this client was detected.
• Last Detected On:The last date/time that this client was detected.
• Association Status Code:Specifies the last Association Status Code that might be useful to disgnose wifi connection problems. You can find the meaning of these codes in this Web page.
• Deauthentication Code:Specifies the last Deauthentication Code that might be useful to disgnose wifi connection problems. You can find the meaning of these codes in this Web page.
• Association Requests:Specifies the number of association requests sent by the client.
• Device DescriptionIf the MAC address of the device is identical a MAC address in your MAC Addresses List (Ctrl+F8), then the description of the device in this list is displayed in this column.

Meaning of Icons

• Green Icon - The AP or wifi client sent or received data in the last 10 seconds. (You can change the number of seconds in the 'Advanced Options' window)
• Orange Icon - The AP or wifi client sent or received data in the last 60 seconds. (You can change the number of seconds in the 'Advanced Options' window)
• Red Icon - No sent/received data in the last 60 seconds.

Command-Line Options

/cfg <Filename>

Start WifiChannelMonitor with the specified configuration file. For example: WifiChannelMonitor.exe /cfg "c:\config\wf.cfg" WifiChannelMonitor.exe /cfg "%AppData%\WifiChannelMonitor.cfg"

Download WifiChannelMonitor

Read More

Multifunctional Network Toolkit for Android - Intercepter-NG v1.9

Intercepter-NG is a multifunctional network toolkit for various types of IT specialists. It has functionality of several famous separate tools and more over offers a good and unique alternative of Wireshark for android.

The main features are:

• Network discovery with OS detection
• Network traffic analysis
• Passwords recovery
• Files recovery

WARNING! You need ROOT access (SUPERSU ONLY) and BUSYBOX to use this application. Please you Google to learn how to get it on your device!
Also, if you face any problems reinstall busybox and supersu!

What's New

1.9 New:

• + Port Scanner (long click on IP)
• + DNS Spoofing
• + Improvements and fixes

1.8b New:

• + 'Gateway not found' fixed
• + Support for intel\arm x32\x64 devices
• + Clipboard usage for Cookies
• + Improvements and fixes

1.7 New:

• + Netmask bug fixed
• + Subnet scanning improved
• + Address bar in Cookie Viewer
• + Data view in Raw Mode

1.6 New:

• + Updated scanning engine
• + Android 5 support
• + Portrait mode compatibility
• + Fixed sdcard issues
• + Cookie Killer
• + Forced Download
• + Fast poisoning

ScreenShots

Download Intercepter-NG

Read More

Burp Suite JavaScript Beautifier - BurpSuiteJSBeautifier

Most of the websites compress their resources such as JS files in order to increase the loading speed. However, security testing and debugging a compressed resource is not an easy task. This is a Burp Suite open source extension which makes it possible to beautify most of the resources properly. Therefore, it will help the web application security researchers to view the compressed resources easier. It also helps them to have the decompressed versions of the resources (such as JS, CSS, HTML, XML, and so on) inside the browsers to debug them without any problem.

Using the application:

Step 0- (Downloading) Download "jsbeautifier.jar" file and "libs" directory.

Step 1- (Adding Libraries) Now under "Extender" tab, click on the "Options" tab; in "Java Environment" section, click on "Select folder ..." button and select the "libs" folder that contains "js.jar" and "rsyntaxtextarea.jar".

Step 2- (Adding Extension) In Burp Suite, click on the "Extender" tab, then click on "Add" button and select "jsbeautifier.jar" file.

Step 3- (Testing Extension) Now you should be able to see "JSBeautifier Settings" tab in burp suite. You can also manually beautify requests/responses by using right click and selecting the "Beautify This!" option. If it cannot beautify anything, check your Burp Suite extension settings and make sure that you have added the requested libraries; Unload/Load the extension and try again.

Features:

• Works with the latest version of Burp Suite (tested on 1.5.21)
• Manual beautifying the requests/responses
• Automatic beautifying the responses in proxy
• Automatic beautifying the responses in all tabs
• Can support Burp suite scope
• Mimicking exact behaviour of JSBeautifier.org website by using Rhino library
• Supporting multiple file types (JS, CSS, HTML, and so on)
• Detecting packers and obfuscators (based on JSBeautifier.org)
• Syntax highlighter in the read-only editor by using Fifesoft RSyntaxTextArea library
• Open Source

This extension is based on the following modules/libraries (included in repository):

• JS files of http://jsbeautifier.org/ - Written by Einar Lielmanis, einar@jsbeautifier.org
• Rhino library - http://www.mozilla.org/rhino/
• Fifesoft RSyntaxTextArea library: http://fifesoft.com/rsyntaxtextarea/

Limitations:

• Limitations of jsbeautifier.org
• Only support UTF-8 for texts

Reporting bugs:

If you have found an issue, please use “Debug Mode” option and attach the extension's Output and Error files to your report. I may not be able to replicate the issue without having this information.

Tested on:

This extension has been tested on Burp Suite Pro v1.5.21 with Java v7ux. If you are using an older version of Burp Suite, you may be able to use version 0.1a of this extension which is located at https://code.google.com/p/burp-suite-beautifier-extension/

Some screenshots:

Download BurpSuiteJSBeautifier

Read More

Encrypted DNS With - DNSCrypt

A protocol for securing communications between a client and a DNS resolver.

Disclaimer

dnscrypt-proxy verifies that responses you get from a DNS provider have been actually sent by that provider, and haven't been tampered with.

This is not a VPN. It doesn't mask your IP address, and if you are using it with a public DNS service, be aware that it will (and has to) decrypt your queries.

If you are using it for privacy, it might do the opposite of what you are trying to achieve. If you are using it to prevent VPN "leaks", this isn't the right tool either: the proper way to prevent VPN "leaks" is to avoid sending data to yet another third party: use a VPN service that operates its own DNS resolvers.

Description

dnscrypt-proxy provides local service which can be used directly as your local resolver or as a DNS forwarder, authenticating requests using the DNSCrypt protocol and passing them to an upstream server.

The DNSCrypt protocol uses high-speed high-security elliptic-curve cryptography and is very similar to DNSCurve, but focuses on securing communications between a client and its first-level resolver.

While not providing end-to-end security, it protects the local network, which is often the weakest point of the chain, against man-in-the-middle attacks.

dnscrypt-proxy is only a client-implementation of the protocol. It requires a DNSCrypt server on the other end.

Download and integrity check

dnscrypt-proxy can be downloaded here: dnscrypt-proxy download

Note: dnscrypt.org is now blocked by the Great Firewall of China. But the source code can also be downloaded on Github, in the "releases" section.

After having downloaded a file, compute its SHA256 digest. For example:

$ openssl dgst -sha256 dnscrypt-proxy-1.6.1.tar.bz2

Verify this digest against the expected one, that can be retrieved using a simple DNS query:

$ drill -aD TXT dnscrypt-proxy-1.6.1.tar.bz2.download.dnscrypt.org

or

$ dig +dnssec TXT dnscrypt-proxy-1.6.1.tar.bz2.download.dnscrypt.org

If the content of the TXT record doesn't match the SHA256 digest you computed, please file a bug report on Github as soon as possible and don't go any further.

Signatures can also be verified with the Minisign tool:

$ minisign -VP RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3 -m dnscrypt-proxy-1.6.1.tar.bz2

Installation

The daemon is known to work on recent versions of OSX, OpenBSD, Bitrig, NetBSD, Dragonfly BSD, FreeBSD, Linux, iOS (requires a jailbroken device), Android (requires a rooted device), and Windows (requires MingW).

Install libsodium. On Linux, don't forget to run ldconfig if you installed it from source.

A "minimal" build of libsodium (--enable-minimal) works equally well as a full build with this proxy.

On Fedora, RHEL and CentOS, you may need to add /usr/local/lib to the paths the dynamic linker is going to look at. Before issuing ldconfig, type:

# echo /usr/local/lib > /etc/ld.so.conf.d/usr_local_lib.conf

Now, download the latest dnscrypt-proxy version and extract it:

$ bunzip2 -cd dnscrypt-proxy-*.tar.bz2 | tar xvf -
$ cd dnscrypt-proxy-*

Compile and install it using the standard procedure:

$ ./configure && make -j2
# make install

Replace -j2 with whatever number of CPU cores you want to use for the compilation process.

The proxy will be installed as /usr/local/sbin/dnscrypt-proxy by default.

Command-line switches are documented in the dnscrypt-proxy(8) man page.

GUIs for dnscrypt-proxy

If you need a simple graphical user interface in order to start/stop the proxy and change your DNS settings, check out the following project:

ºSimple DNSCrypt: an all-in-one, standalone client - using DNSCrypt on Windows has never been so simple.

ºDNSCrypt WinClient: Easily enable/disable DNSCrypt on multiple adapters. Supports different ports and protocols, IPv6, parental controls and the proxy can act as a gateway service. Windows only, written in .NET.

ºDNSCrypt Windows Service Manager: Assists in setting up DNSCrypt as a service, configure it and change network adapter DNS settings to use DNSCrypt. It includes the option to use TCP/UDP protocol, IPV4/IPV6 connectivity, choice of network adapter to configure, as well as configurations for currently available DNSCrypt providers.

ºDNSCrypt OSXClient: Mac OSX application to control the DNSCrypt Proxy.

ºDNSCrypt Tools for Linux: A set of tools for dnscrypt-proxy. Features a start and stop button as well as options to enable or disable from startup. Developed for Porteus Linux.

DNSCrypt-enabled resolvers

To get started, you can use any of the public DNS resolvers supporting DNSCrypt.

This file is constantly updated, and its minisign signature can be verified with the following command:

minisign -VP RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3 -m dnscrypt-resolvers.csv

If you want to add DNSCrypt support to your own public or private resolver, check out DNSCrypt-Wrapper and dnsdist. These are server-side proxies that work with any name resolver.

A DNSCrypt server Docker image is also available to deploy a non-logging, DNSSEC and DNSCrypt-capable resolver without having to manually compile or configure anything.

Usage

Having a dedicated system user, with no privileges and with an empty home directory, is highly recommended. For extra security, DNSCrypt will chroot() to this user's home directory and drop root privileges for this user's uid as soon as possible.

The easiest way to start the daemon is:

# dnscrypt-proxy --daemonize --resolver-name=<resolver name>

Replace <resolver name> with the name of the resolver you want to use (the first column in the list of public resolvers).

The proxy will accept incoming requests on 127.0.0.1, tag them with an authentication code, forward them to the resolver, and validate each answer before passing it to the client.

Given such a setup, in order to actually start using DNSCrypt, you need to update your /etc/resolv.conf file and replace your current set of resolvers with:

nameserver 127.0.0.1

Other common command-line switches include:

º--daemonize in order to run the server as a background process.
º--local-address=<ip>[:port] in order to locally bind a different IP address than 127.0.0.1
º--logfile=<file> in order to write log data to a dedicated file. By default, logs are sent to stdout if the server is running in foreground, and to syslog if it is running in background.
º--loglevel=<level> if you need less verbosity in log files.
º--max-active-requests=<count> to set the maximum number of active requests. The default value is 250.
º--pidfile=<file> in order to store the PID number to a file.
º--user=<user name> in order to chroot()/drop privileges.
º--resolvers-list=<file>: to specity the path to the CSV file containing the list of available resolvers, and the parameters to use them.
º--test in order to check that the server-side proxy is properly configured and that a valid certificate can be used. This is useful for monitoring your own dnscrypt proxy. See the man page for more information.

The --resolver-address=<ip>[:port], --provider-name=<certificate provider FQDN> and --provider-key=<provider public key> switches can be specified in order to use a DNSCrypt-enabled recursive DNS service not listed in the configuration file.

Running dnscrypt-proxy using systemd

On a system using systemd, and when compiled with --with-systemd, the proxy can take advantage of systemd's socket activation instead of creating the sockets itself. The proxy will also notify systemd on successful startup.

Two sockets need to be configured: a UDP socket (ListenStream) and a TCP socket (ListenDatagram) sharing the same port.

The source distribution includes the dnscrypt-proxy.socket and dnscrypt-proxy.service files that can be used as a starting point.

Installation as a service (Windows only)

The proxy can be installed as a Windows service.

See README-WINDOWS.markdown for more information on DNSCrypt on Windows.

Using DNSCrypt in combination with a DNS cache

The DNSCrypt proxy is not a DNS cache. This means that incoming queries will not be cached and every single query will require a round-trip to the upstream resolver.

For optimal performance, the recommended way of running DNSCrypt is to run it as a forwarder for a local DNS cache, such as unbound or powerdns-recursor.

Both can safely run on the same machine as long as they are listening to different IP addresses (preferred) or different ports.

If your DNS cache is unbound, all you need is to edit the unbound.conf file and add the following lines at the end of the server section:

do-not-query-localhost: no

forward-zone:
  name: "."
  forward-addr: 127.0.0.1@40


The first line is not required if you are using different IP addresses instead of different ports.

Then start dnscrypt-proxy, telling it to use a specific port (40, in this example):

# dnscrypt-proxy --local-address=127.0.0.1:40 --daemonize

IPv6 support

IPv6 is fully supported. IPv6 addresses with a port number should be specified as [ip]:port.

# dnscrypt-proxy --local-address='[::1]:40' ...

Queries using nonstandard ports / over TCP

Some routers and firewalls can block outgoing DNS queries or transparently redirect them to their own resolver. This especially happens on public Wifi hotspots, such as coffee shops.

As a workaround, the port number can be changed using the --resolver-port=<port> option.

By default, dnscrypt-proxy sends outgoing queries to UDP port 443.

In addition, the DNSCrypt proxy can force outgoing queries to be sent over TCP. For example, TCP port 443, which is commonly used for communication over HTTPS, may not be filtered.

The --tcp-only command-line switch forces this behavior. When an incoming query is received, the daemon immediately replies with a "response truncated" message, forcing the client to retry over TCP. The daemon then authenticates the query and forwards it over TCP to the resolver.

--tcp-only is slower than UDP because multiple queries over a single TCP connections aren't supported yet, and this workaround should never be used except when bypassing a filter is actually required.

Public-key client authentication

By default, dnscrypt-proxy generates non-deterministic client keys every time it starts, or for every query (when the ephemeral keys feature is turned on).

However, commercial DNS services may want to use DNSCrypt to authenticate the sender of a query using public-key cryptography, i.e. know what customer sent a query without altering the DNS query itself, and without using shared secrets.

Resolvers that should be accessible from any IP address, but that are supposed to be used only by specific users, can also take advantage of DNSCrypt to only respond to queries sent using a given list of public keys.

In order to do so, dnscrypt-proxy 1.6.0 introduced the --client-key (or -K) switch. This loads a secret client key from a file instead of generating random keys:

# dnscrypt-proxy --client-key=/private/client-secret.key

This file has to remain private, and its content doesn't have to be known by the DNS service provider.

Versions 1 and 2 of the DNSCrypt protocol use Curve25519 keys, and the format of this file for Curve25519 keys is a hexadecimal string, with optional :, [space] and - delimiters, decoding to 34 bytes:

01 01 || 32-byte Curve25519 secret key

Server-side, a short TTL for certificates is recommended when using this system.

EDNS payload size

DNS packets sent over UDP have been historically limited to 512 bytes, which is usually fine for queries, but sometimes a bit short for replies.

Most modern authoritative servers, resolvers and stub resolvers support the Extension Mechanism for DNS (EDNS) that, among other things, allows a client to specify how large a reply over UDP can be.

Unfortunately, this feature is disabled by default on a lot of operating systems. It has to be explicitly enabled, for example by adding options edns0 to the /etc/resolv.conf file on most Unix-like operating systems.

dnscrypt-proxy can transparently rewrite outgoing packets before authenticating them, in order to add the EDNS0 mechanism. By default, a conservative payload size of 1252 bytes is advertised.

This size can be made larger by starting the proxy with the --edns-payload-size=<bytes> command-line switch. Values up to 4096 are usually safe, but some routers/firewall/NAT boxes block IP fragments.

If you can resolve test-tcp.dnscrypt.org, increasing the maximum payload size is probably fine. If you can't, or just to stay on the safe side, do not tweak this; stick to the default value.

A value below or equal to 512 will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.

The hostip utility

The DNSCrypt proxy ships with a simple tool named hostip that resolves a name to IPv4 or IPv6 addresses.

This tool can be useful for starting some services before dnscrypt-proxy.

Queries made by hostip are not authenticated.

Plugins

dnscrypt-proxy can be extended with plugins. A plugin acts as a filter that can locally inspect and modify queries and responses.

The plugin API is documented in the README-PLUGINS.markdown file.

Any number of plugins can be combined (chained) by repeating the --plugin command-line switch.

The default distribution ships with some example plugins:

ºlibdcplugin_example_ldns_aaaa_blocking: Directly return an empty response to AAAA queries

Example usage:

# dnscrypt-proxy ... \
--plugin libdcplugin_example_ldns_aaaa_blocking.la

If IPv6 connectivity is not available on your network, this plugin avoids waiting for responses about IPv6 addresses from upstream resolvers. This can improve your web browsing experience.

ºlibdcplugin_example_ldns_blocking: Block specific domains and IP addresses.
This plugin returns a REFUSED response if the query name is in a list of blacklisted names, or if at least one of the returned IP addresses happens to be in a list of blacklisted IPs.

Recognized switches are:

--domains=<file>
--ips=<file>

A file should list one entry per line.

IPv4 and IPv6 addresses are supported.

For names, leading and trailing wildcards (*) are also supported (e.g. *xxx*, *.example.com, ads.*)

# dnscrypt-proxy ... \
--plugin libdcplugin_example,--ips=/etc/blk-ips,--domains=/etc/blk-names

ºlibdcplugin_example-logging: Log client queries

This plugin logs the client queries to the standard output (default) or to a file.

# dnscrypt-proxy ... \
--plugin libdcplugin_example_logging,/var/log/dns.log

ºExtra plugins

Additional plugins can be found on Github:

ºMasquerade plugin
ºGeoIP plugin.

Download DNSCrypt

Read More