Dealing with network covert channel, it would be seriously hard to detect by using purely signature based detection methodologies, you will come to realize that when you can't fingerprint it, you'll have to characterize it. What I mean by characterize is "To be a distinctive trait or mark of; distinguish"(definition from thefreedictionary.com). To be even clear about how it can be done, think behavioural and statistical analysis. I'm coming to this conclusion when I have almost finished reading the papers in the link below -
http://www.gray-world.net/papers.shtmlI most properly agree that covert channel detection can occur by luck when you are monitoring large network. But in small and medium network, you will have higher chance of detecting covert channel if you are implemeting the following -
- Tighten Network Access Control
- Client & Server Services Profiling
- Network Traffic Profiling
Most of the covert channels will try to act as normal legitimate traffics, or it will be more of protocol over protocol tunneling. It doesn't break the protocol, however it will introduce different behaviour in the protocol, the most obvious will be long and continuatious traffic of http, odd sequence numbers usage and so forth. Keep in mind that the attribute of protocol fields may change and the connection states as well.
Tightening network access control can prevent network noise, we are not using network access control to block against covert channel(as you can never block this type of stealthy connections that looks like legitimate one). Client service profiling is defined as what kind of services are allowed to be used by client such as http, https, pop3 and all(outgoing). Server service profiling should be the services that are accessible to the world(incoming). Depends on your network environment, services profiling is a must to identify covert channel because the covert channel will mostly carry over the legitimate services(as I said it bypasses network access control). The network traffic profiling will be the protocol break down and each protocol usages, this is mostly done by using flow/session data collectors, it will generate the statistic of the network flows that allowing you to identify the weird connections by protocols, this is the
lead to analysis of covert channels.
There's a little tool to demonstrate statistical covert channel detection which is called tcpstatflow written by fryxar, you can download it here -
While I don't get it to compiled on FreeBSD, I have luck with Ubuntu. Here's what I have done
geek00l@hell:~/Desktop/Covert-Tools$ cd tcpstatflow/
geek00l@hell:~/Desktop/Covert-Tools/tcpstatflow$ make
geek00l@hell:~/Desktop/Covert-Tools/tcpstatflow$
lsdatalink.c datalink.o flow.c flow.o main.c main.o Makefile README tcpflow.h tcpip.c tcpip.o tcpstatflow util.c util.o
geek00l@hell:~/Desktop/Covert-Tools/tcpstatflow$ ./tcpstatflow
./tcpstatflow[29633]: no suitable device found
geek00l@hell:~/Desktop/Covert-Tools/tcpstatflow$ ./tcpstatflow -h
./tcpstatflow version 1.1 by Fryxar (thanks Jeremy Elson!)
usage: ./tcpstatflow [-hpvD] [-d debug_level] [-f tcptimeout]
[-i iface] [-t statistics_time] [-x bytes_threshold]
[-y time_threshold] [-z packets_threshold] [expression]
-d: debug level; default is 1
-D: start as daemon (log to syslog)
-h: print this help message
-i: network interface to listen
(type "ifconfig -a" for a list of interfaces)
-f: TCP timeout in seconds; default is 7200
-p: don't use promiscuous mode
-v: verbose operation equivalent to -d 10
-t: statistics time; default is 3600, use 0 to disable
-x: cummulative bytes in both senses threshold to report an alarm; default is 50000
-y: duration (in seconds) threshold to report an alarm; default is 86400
-z: cummulative packets in both senses threshold to report an alarm; default is 1000000
expression: tcpdump-like filtering expression
Running my own simple but fast ssh sock proxy channel(Dynamic port forwarding)
geek00l@hell:~/Desktop/Covert-Tools/hcovert-0.5$ ssh -ND 5555 root@1.2.3.4 -p 2222
On the other hand, I also run corkscrew which allowing tunneling ssh through http proxy that I have setup at 1.2.3.4 port 8080. You can install corkscrew by using apt-get on Ubuntu and pkg_add on FreeBSD.
Now I have run the sock proxy and ssh over http proxy, I also connect my browser and other applications to use the sock proxy as well as scp through the http proxy.
Here's the result of my tcpstatflow,
geek00l@hell:~/Desktop/Covert-Tools/tcpstatflow$ sudo ./tcpstatflow -i eth0
Password:
./tcpstatflow[29651]: listening on eth0
Potencial tunnel = 10.0.0.10:2302->1.2.3.4:2222: packets rx=1860 tx=1135, bytes rx=1808079 tx=50182, seconds=234
Stats= mallocs: 9, cleans: 8, reuses: 0, flows: 1, Packets: 4219 drops: 707 (16%)
Potencial tunnel = 10.0.0.10:2496->1.2.3.4:8080: packets rx=3425 tx=4741, bytes rx=50023 tx=5204157, seconds=228
That's pretty neat, but I'm running tcpstatflow in default mode, you can tweak the threshold when coming to detect different kind of covert channels, while you may think that icmp covert channel can bypass this tool, it may be true since this is only for tcp connection, but I believe that icmp covert channel can be restricted with your network access control(Only allow icmp ping echo and reply) and the detection of icmp covert channel can be done via its bytes transfer per flow easily when you have your flow collector in place.
You may check out one of sguil aliance - Victorj, using his mysql-fu, to detect icmp tunnel via Sguil
http://www.inliniac.net/blog/?p=24http://www.inliniac.net/blog/?p=27I have mentioned that monitoring large network can be very headache for covert channel detection, but guess what? Try
ourmon!
Now you know why NSM emphasizes on statistical data as well!!!!!
Enjoy (:])
