How does AFD perform active filtering detection?
Initially, lib-pcap was considered for trying to detect things like TTL differences, RST vs FIN, etc. It was quickly realised that this wasn't needed. The objective was so simple; Is a dynamic filter in place between the tester and the target. The answer is binary - if we believe that the target is dynamically filtered, then its over. If we believe that the target is clean, then the testing is on.
In the program's usage (osstmm-afd -h), the test methodology has been documented this way;
osstmm-afd: What the ..;
afd is the active filtering detector - designed to meet OSSTMM's
requirement for detecting active filtering such as IDP or IPS.
The program works by taking a list of known-ugly signature strings
and requesting them against the target web service, in an attempt
to get locked out.
Return condition -2 means; time-out or prematurely closed
connections, or the inability to establish a new connection.
Condition -2 signifies active filtering, -1 signifies comms
failure, while 0 is a nil result (all ok, and likely to be no
filtering).
By hurling signatures at the target, we hope to invoke a negative response (from anything).
What differentiates a communications failure vs active filtering?
There are a number of trip conditions, and these are dependant on on the calling function (see below). The program has decisions against each function error, pre-programmed into it; determining as to whether the error is likely to be a communications error or a DoS employed by a filter. This is possible as the socket code takes into account network error conditions - such as Connection Refused, Connection Timed Out, Network Unreachable - even the fact that the program is no longer using a socket is a good indicator that the underlying connection (TCP stream) has been shut down.
So, by function;
connect()
DoS in Effect: ENOTSOCK, ECONNREFUSED, ETIMEDOUT, ENETUNREACH
Comms Failure: EFAULT, EISCONN, EADDRINUSE, EINPROGRESS, EAGAIN,
EAFNOSUPPORT, EACCES, EPERM, any other.
send()
DoS in Effect: EBADF, ECONNRESET, ENOTCONN, ENOTSOCK, EPIPE
Comms Failure: EAGAIN, EDESTADDRREQ, EFAULT, EINTR, EINVAL,
EISCONN, EMSGSIZE, ENOBUFS, ENOMEM, EOPNOTSUPP,
any other.
recv()
DoS in Effect: ECONNREFUSED, ENOTCONN, ENOTSOCK
Comms Failure: EBADF, EAGAIN, EINTR, EFAULT, EINVAL, ENOMEM,
any other.
close()
DoS in Effect: EBADF
Comms Failure: EINTR, EIO, any other.
Note that the close() can be used as the the HTTP/1.1 request is issued without the "Close" header - so the connection should remain open up until our close() point, no matter how fast the comms are (or slow the test machine is) - unless the IDP RST the stream, for example.
How can I test osstmm-afd locally?
The fastest valid test for the tool is to hit a port that is known to not be open/running any listener. So try your web server at port 99/TCP
[root@cipher afd-0.7]# osstmm-afd -P HTTP -t www -p 99 -v
Performing active fitering detection against the following target;
HTTP://www:99/
Performing: Nil parameter Requests
Test: 001 / 081
Connecting : 192.168.1.247:99 .. Connection refused [ECONNREFUSED]
Target seems likely to have active filtering running.
Note that as it was the first test that failed, you should
confirm the target, port and protocol parameters.
Compare this to the same test against port 80/TCP;
[root@cipher afd-0.7]# osstmm-afd -P HTTP -t www -p 80 -v
Performing active fitering detection against the following target;
HTTP://www:80/
Performing: Nil parameter Requests
Test: 001 / 081
Connecting : 192.168.1.247:80 .. Connected.
Sending Sig : .. 188 bytes sent.
Validating : Retrieve .. 1400 bytes avail.
Closing : Closed.
Test: 002 / 081
Test Skipped: Test ignored due to protocol mis-match
[........]
Performing: Nil parameter Requests
Test: 080 / 081
Connecting : 192.168.1.247:80 .. Connected.
Sending Sig : .. 188 bytes sent.
Validating : Retrieve .. 1400 bytes avail.
Closing : Closed.
Test: 081 / 081
Test Skipped: Test ignored due to protocol mis-match
Target appears to be clean - no active filtering detected.
This demonstration shows that you are in a good position to assess a halt on communications based on decisions from non-local infrastructure.
One other test worth considering, if you don't have access to an IDP device, is testing against IDS and seeking out the alarm events (the equivalent points where an IDP may have commenced its counter-measure deployment). The test web service is arbitrary (it need only respond to HTTP/1.1 requests).
This
Snort Log file was recorded on a Windows XP PC running Snort, and the Abyss web server - both in default installation condition. As can be seen from the log, 46 of the 48 attack signatures in the original default AFD v0.5 configuration file, were detected by Snort. This is a good indication that an IDP of equivalent "awareness" is likely to have responded to an AFD scan.
Where have the 81 v0.7 AFD signatures come from?
The first (and last) two signature(s) were home made - a simple request for the root HTTP document, or empty SMTP message. This signature type is not considered an attack signature, and is included only to provide a connection test.
The next 53 signatures were taken from this paper at CGI Security;
http://www.cgisecurity.com/papers/fingerprint-port80.txt
The next 20 signatures were taken randomly from this Snort rule list, and then re-engineered back into recognisable attack patterns (10 HTTP and 10 SMTP);
http://www.bleedingsnort.com/bleeding-all.rules
The final 4 signatures were constructed from the Eicar test virus pattern;
http://www.eicar.com/anti_virus_test_file.htm
Here is a sample signature configuration entry for one of the fingerprint-port80 examples;
new.signature cmdexe1
cmdexe1.label "cmd.exe" Commands
cmdexe1.protocol HTTP
cmdexe1.example http://host/x.asp=../../WINNT/system32/cmd.exe?dir+c:\
cmdexe1.parameter ../../WINNT/system32/cmd.exe?dir+c:\
Realistically, any signature could be represented in this format. See the latest source for the most current osstmm-afd.cfg signature file.
Could the tool be extended, perhaps for other protocols?
It could be expanded fairly readily. The tool, was originally designed specifically for HTTP (and not HTTPS). This was primarily due to HTTP being the protocol of choice for users, hackers and security folk, alike. However, in its current form, it supports SMTP and HTTP; and can be further extended for any non-interactive TCP protocol, very easily. The signatures hurled at the target are maintained in the configuration file /usr/local/etc/osstmm-afd.cfg and are entirely flexible.
The one extension that was considered, but has not yet been implemented, is the addition of a timer to each test (or signature hurl). After three tests, the AFD could declare a time average required to perform a test. This could then be used to detect more subtle variations (such as tar-pitting) when things start to slow down.
What other features does the program support, can I embed it?
There are a number of useful features that have been added despite no immediate need or use, that should keep the tool more generally relevant (such as user agent, cgi-path, referer string, silent output for embedding, and virtual host support). The v0.7 command options include the following;
osstmm-afd: Usage;
Long Short Args
~~~~ ~~~~~ ~~~~
--config -c {"string"} Specify the configuration file to use
--dangerous -! Enable dangerous signatures
--debug -D Enable debugging
--help -h Display this help screen
--protocol -P {HTTP|SMTP} Specify the testing protcol
--port -p {1-65535} Specify the target port
--silent -s Report zero output (only error level)
--target -t {"string"} Specify the target hostname or IP
--timeout -T {1-120} Specify the connect timeout in seconds
--verbose -v Display test detail as executed
--version -V Display version and exit
Protocol: HTTP
--agent {"string"} Configure User-agent: header value
--path {"string"} Specify the path, program and variable
--referer {"string"} Configure Referer: header value
--vhost {"string"} Specify the target virtual host name
Protocol: SMTP
--helo {"string"} Specify source server name
--address-all {"string"} Specify all addresses as string
--mail-from {"string"} Specify mail from: address
--rcpt-to {"string"} Specify rcpt to: address
--rfc822-from {"string"} Configure From: address
--rfc822-to {"string"} Configure To: address
--rfc822-subj {"string"} Configure Subject: text
How about an HTTP usage example and its equivalents?
A complex usage example may be;
[root@cipher afd-0.7]# osstmm-afd -P HTTP --timeout 2 \
--agent "NCSA_Mosaic/2.8 (X11; FreeBSD 5.2.1 i686)" \
--referer "http://www.google.com/search?hl=en&q=foo&btnG=Search&meta=" \
--vhost "www.scan.target.com" --path "/app/login.php?user=" \
--target 192.168.1.247 -p 80 -v
Which would produce HTTP/1.1 queries such as this one;
GET /app/login.php?user=../../WINNT/system32/cmd.exe?dir+c:\ HTTP/1.1
Host:
www.scan.target.com
Referer:
http://www.google.com/search?hl=en&q=foo&btnG=Search&meta=
User-agent: NCSA_Mosaic/2.8 (X11; FreeBSD 5.2.1 i686)
X-AFD-INTERFACE-lo: 127.0.0.1
X-AFD-INTERFACE-eth0: 192.168.1.21
Pragma: no-cache
Accept: */*
This query would be functionally equivalent to the following netcat command;
[root@cipher afd-0.7]# nc -w 2 192.168.1.247 80 << EOF
GET /app/login.php?user=../../WINNT/system32/cmd.exe?dir+c:\ HTTP/1.1
Host:
www.scan.target.com
Referer:
http://www.google.com/search?hl=en&q=foo&btnG=Search&meta=
User-agent: NCSA_Mosaic/2.8 (X11; FreeBSD 5.2.1 i686)
X-AFD-INTERFACE-lo: 127.0.0.1
X-AFD-INTERFACE-eth0: 192.168.1.21
Pragma: no-cache
Accept: */*
EOF
