Hello All
Since many of standard services can be made to

listen on any port on the server side, and proxies

with custom configuration can be used in cases

otherwise, how effective is a firewall if it blocks

based on standard service ports? Is there a way

in which the application protocols being used can

be detected and then this knowledge be used to

let pf know what to filter and what not?  So, is

there some way to ensure that traffic to port 53

is in fact not from a program like iodine and what

goes to port 80 is only HTTP/HTTPS, and so on

for all the common protocols? With my little bit

of knowledge what I figure is that we need some

piece of software(s) which understands each protocol

thoroughly, can look at raw packets in real-time

and detect the protocol being used. Even then,

it may get bypassed in cases like 'protocol obfuscation'

feature of eMule being used, or if sufficient amount

of random garbage traffic is generated to deter proper

analysis.
Please correct if I am wrong or the question itself

is impertinent to this list.
Any help will be great. Thanks in advance.
Srikant Tangirala.

On Fri, 9 May 2008 10:40:18 +0530
Hello All,
You can do it using open-source software as "Bro" (http://bro-ids.org),

it's an open-source, Unix-based Network Intrusion Detection

System (NIDS) that passively monitors network traffic and looks for

suspicious activity.

"Bro" has the "DPD" (dynamic protocol detection) feature and can

reports (confirmed) uses of protocols on non-standard ports.
Please see : http://www.icir.org/robin/papers/usenix06.pdf for more

informations about this.
Last thing, it builds and works perfectly on OpenBSD. :-)
With regards,
Jean-Philippe.

<snip>

Thanks a lot jean-philippe !

Will give it a try immediately.
Regards

Srikant Tangirala.

ah, i'm just looking at your mail again - you a are kidding, there is

no way to do content inspection in "real-time". go and use linux where

you can use stupid and dangerous stuff in the kernel. this is not what

openbsd is about.
reyk

There are actually commercial products that can do this. The ones I know

about is Sandvine, Allot and Procera Networks. I know at least Sandvine

does the bandwidth limiting in a very ugly way with the spoofed RST's

that we've heard about from Comcast in the US.
The only product I've had hands on experience with is PacketLogic from

Procera Networks (disclamer: I work for them). In one case it had no

problem identifying the traffic in real time on two links pushing a

total of 2,5Gbps (~6-700Gbps in both directions over four interfaces).

This was in sweden, so the traffic pattern is pretty easy, a looot of

BitTorrent. In cases with a lot of short lived connections, a system

like this has a hard time keeping up with 2,5Gbps.
I know there are a lot of buzzwords that you have to see through in this

market of DPI/DFI, but there are actually systems capable of identifying

traffic on layer7 in realtime, although commercial.
/Johan

Thanks for such a prompt reply.
I will not use Linux even if you pay me. It has been OpenBSD

for me for past three years and it will remain so as long as

OpenBSD remains what it stands for.
That aside, see, I have used this tool called ourmon successfully

on OpenBSD to detect P2P traffic and block the users in

conjunction with authpf and pf. The tool can do other detections

as well. It matches packets/traffic-patterns with those observed

by network admins as being related to a specific type of application

protocol. Payload is not inspected, although a grep may be

happening. It works by passively monitoring the packets flowing

by, no kernel stuff involved.
Just want to know if anyone has come up with a good solution to

this problem. If there is none yet, fine, we continue with what we

have or even partial solutions will help a bit.
Thanks for your time.
Srikant Tangirala.

we're working on interfaces to speed up the application layer

relaying, the current way requires to rdr the traffic into userspace,

do a nat lookup on the pf socket, and forward the traffic to the

target with a second inspection. this can be done fast, but there is

some overhead. this may improve in the future when we have the ability

to migrate the relayed connections to forwarding in the kernel after
p2p detection is a very difficult but interesting area. but you can

also mitigate the use with other tricks, like delays, special kinds of

you can redirect the outgoing traffic through a pf proxy which

understands and enforces the common parts of the protocol.  this does

not prevent anyone to tunnel something else in the well-defined

protocol, like SSH over DNS, but it at least allows to make it a

little bit stricter. 
examples are ftp-proxy(8), tftp-proxy(8), relayd(8) (DNS, HTTP, and

more), ... some people also like squid with pf patches from ports; but

i'm feeling sorry for them.
reyk