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?


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 '16 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 '16 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.