Protocols such as IP, TCP, UDP, ICMP, and RPC, according to Juniper networks could potentially be useful for IDS objectives of determining the direction and test conditions. In a way, protocol anomaly-based IDS is considered more practical than other methods as it uses available basic TCP header data and other attributes. Is this approach really practical in reality?

1 Answer 1


The problem IDSes face today is encryption. Once you receive a stream of encrypted information, you can only try to make sense of its behaviour.

They rely on defaults (a default port or protocol for a service), on well-known endpoints and on some pre-encryption activities (handshakes for instance).

So I would say that it is more one of the few possibilities left today, rather than being "more practical".

  • What about GigaSMART with the SSL Decryption feature license? What of Blue Coat, Palo Alto Networks, or other SSL/TLS decryption? What about detecting the difference between SSL/TLS and SSH flows that are interactive versus ones that are bulk-file transfer operations? Let's say you have an sftp server that should only be accessed for bulk-file transfer operations but then you see evidence of an interactive shell just by the network flows (i.e., without decryption)? Isn't this an anomaly that should be reported and/or analyzed but that involves encrypted traffic?
    – atdre
    Jul 1, 2016 at 22:03
  • @atdre: if you can and are willing to decrypt then obviously you have data to look at. Otherwise you fall back to the behavioral analysis I mentioned (which may or may not be useful - in the case you describe, provided that you can define 'normal', it could be a possibility).
    – WoJ
    Jul 4, 2016 at 6:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .