Web Application Firewall using DFA - Raptor WAF v0.2

Raptor WAF is a simple web application firewall made in C, using KISS principle, to make poll use select() function, is not better than epoll() or kqueue() from *BSD but is portable,  the core of match engine using DFA to detect XSS, SQLi and path traversal.

No more words, look at the following :

WAF stands for Web Application Firewall. It is widely used nowadays to detect and defend SQL Injections and XSS...

• You can block XSS, SQL injection attacks and path traversal with Raptor
• You can use blacklist of IPs to block some users at config/blacklist ip.txt
• You can use IPv6 and IPv4 at communications
• At the future DoS protector, request limit, rule interpreter and Malware detector at uploads.
• At the future SSL/TLS...

to run:

$ git clone https://github.com/CoolerVoid/raptor_waf
$ cd raptor_waf; make; bin/raptor

Example

Up some HTTPd server at port 80

$ bin/Raptor -h localhost -p 80 -r 8883 -w 4 -o loglog.txt

you can test at http://localhost:8883/test.php

Look the docs

https://github.com/CoolerVoid/raptor_waf/blob/master/doc/raptor.pdf

Tests:

509 of attacks, detect and block 349, 68% of attacks blocked

Steps to create your WAF(web application firewall) in C

Following definition (like OWASP), a WAF is a piece of software intended to protect a web app that is on the level of the application. nowadays, a WAF is not defined by the web app, it’s not a customized solution specific to that application but similarly to a general software firewall, where one that contains parameters to protect against intrusion in a wide variety of frameworks and codes. Trying clear your mind, there is overlap between the different types of firewalls. Software and hardware firewalls are used in their own right to protect networks. However, WAFs with their specialized function for web applications, can take the form input of either of those two main types. Per default, a firewall uses a blacklist, protecting against an individual, previously logged attacks. Additionally, it can also use a white list, providing allowable users and instances of interaction for the application, another function is block SQL Injection attacks and XSS attacks… Another context  WAFs can create random tokens and put in forms to try blocks web robots and automated attacks, this practice can try mitigate CSRF pitfalls. Before you ask “How i can do  it?”, i gotta bring to you some principles, anyway the theory around facts…

Have two common WAFs:

1- Uses plugin in HTTPd to get information of data INPUT or OUTPUT, before finish he gets the request and block some contents, this function focuses at HTTP METHODs POST, GET…  

 2- This way, is my favorite, is a independent reverse proxy server, he bring all requests of the client to the proxy, the proxy makes some analysis in the content, if not block, he send all the information to the external server… 

  

Number One is a cold, this path is not fully portable… other bad thing you need create a diferent plugin each HTTPd, something to apache another to NGINX, IIs, lighttpd…  its not cool! If you are not a good low level programmer… you can try use twisted of python, is easy make reverse proxy with it, but is not good way, because not have good performance in production… if you piss off for it, study the Stevens book of sockets. Its OK, the title of this post is “create waf in C”, Task fully done here and commented and with some documentations in LaTex… relax, you can get it in this repository:

Download Raptor

Read More

Security Auditing Tool for Unix/Linux Systems - Lynis 2.3.2

We are excited to announce this major release of auditing tool Lynis. Several big changes have been made to core functions of Lynis. These changes are the next of simplification improvements we made. There is a risk of breaking your existing configuration.

Lynis is an open source security auditing tool. Used by system administrators, security professionals, and auditors, to evaluate the security defenses of their Linux and UNIX-based systems. It runs on the host itself, so it performs more extensive security scans than vulnerability scanners.

Supported operating systems

The tool has almost no dependencies, therefore it runs on almost all Unix based systems and versions, including:

• AIX
• FreeBSD
• HP-UX
• Linux
• Mac OS
• NetBSD
• OpenBSD
• Solaris
• and others

It even runs on systems like the Raspberry Pi and several storage devices!

Installation optional

Lynis is light-weight and easy to use. Installation is optional: just copy it to a system, and use "./lynis audit system" to start the security scan. It is written in shell script and released as open source software (GPL). 

How it works

Lynis performs hundreds of individual tests, to determine the security state of the system. The security scan itself consists of performing a set of steps, from initialization the program, up to the report.

Steps

1. Determine operating system
2. Search for available tools and utilities
3. Check for Lynis update
4. Run tests from enabled plugins
5. Run security tests per category
6. Report status of security scan

Besides the data displayed on screen, all technical details about the scan are stored in a log file. Any findings (warnings, suggestions, data collection) are stored in a report file.

Opportunistic scanning

Lynis scanning is opportunistic: it uses what it can find.

For example if it sees you are running Apache, it will perform an initial round of Apache related tests. When during the Apache scan it also discovers a SSL/TLS configuration, it will perform additional auditing steps on that. While doing that, it then will collect discovered certificates, so they can be scanned later as well.

In-depth security scans

By performing opportunistic scanning, the tool can run with almost no dependencies. The more it finds, the deeper the audit will be. In other words, Lynis will always perform scans which are customized to your system. No audit will be the same!

Use cases

Since Lynis is flexible, it is used for several different purposes. Typical use cases for Lynis include:

• Security auditing
• Compliance testing (e.g. PCI, HIPAA, SOx)
• Vulnerability detection and scanning
• System hardening

Resources used for testing

Many other tools use the same data files for performing tests. Since Lynis is not limited to a few common Linux distributions, it uses tests from standards and many custom ones not found in any other tool.

• Best practices
• CIS
• NIST
• NSA
• OpenSCAP data
• Vendor guides and recommendations (e.g. Debian Gentoo, Red Hat)

Lynis Plugins

lugins enable the tool to perform additional tests. They can be seen as an extension (or add-on) to Lynis, enhancing its functionality. One example is the compliance checking plugin, which performs specific tests only applicable to some standard.


Changelog

Categories and Groups

Tests are now grouped by their focus area and named 'groups' accordingly. Besides groups, each test will belong to a category (performance, privacy, or security).
Commands: lynis show categories, lynis show groups Options: --tests-from-category, --tests-from-group
Note: You might need to change your scripts if you previously defined the group of tests to scan.
Development

---

A new 'strict' option is available in the profiles and by default enabled for the initialization phases of Lynis. It will perform a strict code check for the tests, to detect any uninitialized variables, improving code quality.

Helpers

With 'lynis update check' you can now check for updates. This is the preferred new method.
The command 'lynis show changelog' allows reviewing the changes. Optionally a release can be specified as additional argument.

Languages

Initial translation for German has been contributed by Kai Raven. The Italian translation by Stefano Marty (stefanomarty). Hungarian translation by Zoltan Paldi (paldiz)

Profiles

Parsing of the profiles has been improved, which prevented some settings from overriding default settings.

Tests

• AUTH-9212 - Added prerequisite to log
• AUTH-9216 - Simplified test and make it more efficient
• AUTH-9218 - Clean ups and improve readability
• AUTH-9226 - Style, text, and removed warning
• AUTH-9228 - Provide just a suggestion instead of warning
• AUTH-9268 - Improve test for readability
• AUTH-9328 - Test /etc/profile.d for umask setting
• AUTH-9406 - Readability and code style changes
• CONT-8102 - Determine if all Docker tests should be performed
• DBS-1880 - Initial support for Redis server
• HTTP-6720 - Readability improvement of test
• KRNL-5830 - Readability and style improvements, ignore rescue images
• MAIL-8818 - Style and refactoring
• PHP-2211 - Readability improvement and code style changes
• PHP-2374 - Changed text and cleanups
• PHP-2376 - Log result to log file instead of report
• PKGS-7383 - Simplified test
• PKGS-7388 - Style and readability improvements
• TIME-3106 - Corrected string to test for status
• TOOL-5102 - Split of fail2ban tests
• TOOL-5104 - Test for enabled fail2ban jails

Languages

Translation of Spanish (es) added Proper display of text strings when accented characters are used More text strings added

General

• Added bold and header as new colors
• Changed header and footer of screen output
• Allow atomic tests to be skipped (e.g. SSH-7408)
• Extended tests database with category (lynis show tests)
• By default Lynis will now run in 'quick mode' and not break after each section. You can get this behavior by adding the --wait option.

Functions

• RemoveColors - New test to clear colors
• DisplayError - Display error on screen in uniform format and colors Use an optional exit code to quit the program
• SkipAtomicTest - This function is now properly working with lowercase strings

Website

Several controls on the website are added or updated, including:

• FILE-6344
• FINT-4315
• FINT-4402
• HTTP-6714
• MACF-6234
• NAME-4018
• NAME-4402
• PHP-2374
• PROC-3612
• TIME-3106

Download Lynis 2.3.2

Read More

Practice Penetration Testing - Labs

I found this page, it has a pretty good mind-map listing all available labs to practice your skill in doing penetration testing.  

Vulnerable Web Applications [36 unique web applications]

OWASP BWA http://code.google.com/p/owaspbwa/
OWASP Hackademic  http://hackademic1.teilar.gr/
Butterfly Security Project  http://thebutterflytmp.sourceforge.net/
Foundstone Hackme Bank  http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx
Foundstone Hackme Books  http://www.mcafee.com/us/downloads/free-tools/hacmebooks.aspx
Foundstone Hackme Casino  http://www.mcafee.com/us/downloads/free-tools/hacme-casino.aspx
Foundstone Hackme Shipping  http://www.mcafee.com/us/downloads/free-tools/hacmeshipping.aspx
Foundstone Hackme Travel  http://www.mcafee.com/us/downloads/free-tools/hacmetravel.aspx
LAMPSecurity  http://sourceforge.net/projects/lampsecurity/
Moth  http://www.bonsai-sec.com/en/research/moth.php
WackoPicko  https://github.com/adamdoupe/WackoPicko
BadStore  http://www.badstore.net/
WebSecurity Dojo  http://www.mavensecurity.com/web_security_dojo/
BodgeIt Store  http://code.google.com/p/bodgeit/
hackxor  http://hackxor.sourceforge.net/cgi-bin/index.pl
SecuriBench  http://suif.stanford.edu/~livshits/securibench/
SQLol  https://github.com/SpiderLabs/SQLol

Vulnerable Operating System Installations [16+ unique OS setups]

Damn Vulnerable Linux  http://sourceforge.net/projects/virtualhacking/files/os/dvl/
Metasploitable v1  http://www.metasploit.com/learn-more/how-do-i-use-it/test-lab.jsp
Metasploitable v2  https://community.rapid7.com/docs/DOC-1875
LAMPSecurity  http://sourceforge.net/projects/lampsecurity/
UltimateLAMP  http://ronaldbradford.com/tmp/UltimateLAMP-0.2.zip
De-ICE, hackerdemia, pWnOS  http://forums.heorot.net/
Holynix  http://pynstrom.net/holynix.php
Kioptrix  http://www.kioptrix.com/
CentOS  http://www.centos.org/

Sites for Downloading Older Versions of Various Software [3 sources]

Old Apps  http://www.oldapps.com/
Old Version  http://www.oldversion.com/
Exploit-DB  http://www.exploit-db.com/

Sites by Vendors of Security Testing Software [8 unique sites]

Acunetix acuforum  http://testasp.vulnweb.com/
Acunetix acublog  http://testaspnet.vulnweb.com/
Acunetix acuart  http://testphp.vulnweb.com/
Cenzic crackmebank  http://crackme.cenzic.com
HP freebank  http://zero.webappsecurity.com
IBM altoromutual  http://demo.testfire.net/
Mavituna testsparker  http://aspnet.testsparker.com
Mavituna testsparker  http://php.testsparker.com

Sites for Improving Your Hacking Skills [16 unique sites]

Google Gruyere  http://google-gruyere.appspot.com/
Hack This Site  http://www.hackthissite.org/
Hacker Challenge  http://www.dareyourmind.net/
HackQuest  http://www.hackquest.com/
Hax.Tor  http://hax.tor.hu/
Hacker Test  http://www.hackertest.net/
OverTheWire  http://www.overthewire.org/wargames/
Root Me  http://www.root-me.org/?lang=en
Smash The Stack  http://www.smashthestack.org/
TheBlackSheep and Erik  http://www.bright-shadows.net/
ThisIsLegal             http://thisislegal.com/
Try2Hack                http://www.try2hack.nl/
EnigmaGroup             http://www.enigmagroup.org/
hACME Game              http://www.hacmegame.org/
Exploit Exercises       http://exploit-exercises.com/
Hacking-Lab             https://www.hacking-lab.com

The link is http://www.amanhardikar.com/mindmaps/PracticewithURLs.html

OffensiveSec Blog

Read More

Collection Of Tools To Detect, Record And Prevent Attacks On Web Applications - Shadowd

Shadow Daemon is a collection of tools to detect , record and prevent attacks on web application. Technically speaking, Shadow Daemon is a web application firewall that intercepts requests and filters out malicious parameters. It is a modular system that separates web application, analysis and interface to increase security, flexibility and expandability.

This is the main component that handles the analysis and storage of requests.

Documentation
For the full documentation please refer to shadowd.zecure.org .

Installation

Preparation
Use cmake to configure and prepare the project. It is a good idea to create a separate directory for this. A typical installation might look like this.

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BUILD_TYPE=Release ..

Compilation
If cmake is successful it creates a makefile. Use it to compile and install the project.

make shadowd
make install

Database
Install and configure a database server. At the moment shadowd officially supports PostgreSQL and MySQL. Afterwards create a new user and database for shadowd and import the correct layout.
If you are using PostgreSQL you can use psql to import the layout.

psql -Ushadowd shadowd < /usr/share/shadowd/pgsql_layout.sql

If you are using MySQL you can use mysql to import the layout. The user requires the CREATE ROUTINE privilege.

mysql -ushadowd -p shadowd < /usr/share/shadowd/mysql_layout.sql

Configuration
The installer copies the configuration file to /etc/shadowd/shadowd.ini . The file is annotated and should be self-explanatory.

Download Shadowd

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

Razorback

The new Razorback platform developed by Sourcefire is basically a tool for tying together the various layers of detection within an organization, including antivirus, IDS/IPS, Web and email gateways, and firewalls, to use in concert to catch and examine potential threats and create mitigations on the fly.

Its creators say it’s not the same thing as a security information management tool, however, because it does more than capture events: “SIM collects events in a vacuum: It takes an AV event and says this host is infected by a virus … It doesn’t know anything about that piece of malware on the box,” says Matt Watchinski, senior director of Sourcefire’s vulnerability research team.

Download Razorback

Read More