ASDIC

Advanced Usage



Here you learn the more advanced features of the system needed for advanced usage and system configuration.

In a newly installed system, you are required to define ip groups, criteria and predefined searches. Those definitions can then be used even by the basic user without the deeper skills needed for defining them.

You can choose to define those entities either local to the logged in user, or global accessible to all users of the system.

With predefined searches you can also define scheduled reports running searches and sending the results to specified mail receivers on a regular basis. This can be used to automatically bring network anomalies to your attention.

IP groups

IP groups are named and saved ip groups, and works in the same way as when you type them in manually in the search form described in the user manual. The difference is that here you can specify multiple groups at once.

Example of ip groups

All

Pattern: Four question marks, blank protocol
Explanation: Matches all possible patterns

Sessions

Pattern: Four asterisk, blank protocol
Explanation: Matches all records with only non-blank fields, i.e. sessions.

Sessions are very short lived in the ASDIC database. Each time a session is classified into one or more collectors, ASDIC will remove it after a short time. This time is default 48 hours and is configurable by the system administrator. Keeping too many sessions too long time, will make the databases larger and the system slower. Collectors on the other hand are by default kept indefinite.

Local services

Pattern: for example 192.168/16 * ? ? <blank>
Explanation: Requires source ip in our own network and a non blank source port. Destination ip and port optional (that is the semantics of the question mark). This ip group is very well suited to be used together with criteria like "overview", "tcp services" and "legal traffic" to get an overview of all the services in the network. The question masks in the pattern are required, because you do not know in advance how the pattern will be shaped, because it is determined by the traffic characteristics. If we take NTP as an example, both source and destination port are always the same, and the pattern will then specify them both, but a web server on the other hand, uses tcp and a random high port, and the pattern will not include that random data.

Criteria

Defining criteria is advanced and requires knowledge and experience in the system operations.

click to enlarge

A criterium is a search mask specifying conditions to be fulfilled in a pattern to make it match a search. The conditions can be one of four different classes, as the picture shows; "sender", "traffic is", "system flags" and "user flags". A criterium is matched against the corresponding data in the record for the particular flow in the database. Blank means the selection is not relevant for the search, "yes" and "no" that it must / must not be valid, "part" and "none" that it may / may not even be valid for any sub part of the pattern.

Sender

This is what is true about the sender of the ip datagram. Please take a moment to convince yourself that it is not possible to say anything what so ever about the receiver of a datagram by looking at the ip packet - the receiver may not even exist! If you need information about the receiver, reverse the session and look at the ip address in the role of the sender instead. The sender flags are only available via the network traffic interceptor.

  • Ack's means the sender answered positive, for example a TCP ACK.
  • Nack's means the sender answered negative, for example a TCP RST.
  • Connects means the sender sent a TCP SYN.
  • Listens meas the sender sent a SYN+ACK.
  • Open service means that ASDIC port scanning found an open service.

Traffic is

This is what some intermediate system (firewall, routes) has to say about the traffic. The traffic flags are only available via the loginput parser.

  • Permitted means the traffic was permitted.
  • Denied means the traffic was denied.

System flags

The system flags are a bit more subtle than the other flags, and requires more versatile explanations. They are a part of the ASDIC internal heuristics for traffic analysis.

  • Collection is the most important flag. It tells you that the system has classified this pattern as a collection of sessions, or aggregate. This classification is what makes the ASDIC traffic analysis system unique. Almost all criteria you define here, will have this selected.
  • Tampered is a flag that is set for all records in the database modified by an operator. By creating a report selecting all those records, you will get a list over all modified traffic entries in the database.
  • Subclass means there are other patterns embracing the pattern in question.
  • Meta collector means that the pattern/collector embraces other patterns/collectors.
  • Trapped means the pattern embraces at least one session matching a pattern marked "trap" by the operator.
  • Trap related means that this was the session/packet causing the trap

User flags

With these flags, you can modify the behavior of the system. For example, you can use them to acknowledge events, enable booby traps and similar features. By defining a criterium for those flags, you can define a search for locating those records in the database.

User flags and traps are features from version 1 of ASDIC, and not very much used now days, but still included for backward compatibility.

  • This is Ok is a flag for acknowledging an event.
  • Trap is used to create a booby trap.
  • Trap exclusion is used in combination with the trap flag. Often you want to set a trap on an entire ip address, but exclude a few used services.
  • Priority trap is a kind of trap activated even on non-patterns. Beware of false positives here. Use only when you know what you are doing.
  • Never collects means that the record in question must not be classified as a collector. Do not use this feature - ASDIC does in almost all cases classify flows better than you can do manually. If you use this, you are risking getting inconsistent flow classifications.

Acceptance

This is a shortcut. If is a complex expression calculated from "traffic is" and "sender" flags in both forward and reverse directions. It looks at both the firewall log files and the end systems responses, if appropriate input module used. This is the same as the red/green dot "AR" in the reports. One and the same session can be both accepted and at the same time rejected, is the firewall permits traffic to an end system refusing (resetting) the session. By using this instead of specifying "sender" and "traffic is" flags you creates criteria independent of the source of the traffic information (e.g. both firewalls and network).

Note that sometimes you really want to specify search rules explicit looking at firewall or protocol responses. In those cases you must look at the flags in "traffic is" or "sender" explicit, not using the "acceptance" feature. I.e. if a packet passes the firewall but is rejected by the end host (i.e. tcp rst), acceptance will indicate both accept and reject for one and the same session.

Threshold

The minimum number of sessions (or packets) for this criterium to match.

Example of common used criteria

All

Flags: none
Explanation: Matches everything.

Overview

Flags: Collection YES + Subcollector NO.
Explanation: "Collection YES" specifies only patterns are to be selected. "Subcollector NO" excludes all pattern with a (meta) pattern embracing it. At first glance, it can look like this is the same as "Meta collector YES", but it is not. Some patterns are not hierarchical, and they will then be missed.

Details

Flags: Collection YES + Meta collector NO.
Explanation: "Collection YES" specifies only pattern are to be selected. "Meta collector NO" excludes all (meta) patterns embracing other patterns. The results will be all sub collectors and non hierarchical collectors. You must not specify "Subcollector YES" by the same reasons as above ("overview").

Also note that in some cases, a subcollector will not be created. E.g. a highly trafficked web server, ASDIC may choose not to include every single client as its own collector (i.e. webserver:80 -> client), but only create the collector "webserver:80". This collector will not be marked "meta" since it do not collects any other collectors, neither "subcollector" because it is not. With the definition of the "details" and "overview" criteria here, this record will match both criteria, which is semantically sane.

Traffic pattern

Flags: Collection YES
Explanation: This will match any pattern/aggregate; subcollectors, meta collectors and non hierarchical collectors.

TCP services

Flags: Collection YES + Listen YES
Explanation: Matches any pattern containing sessions where the sender has sent an SYN+ACK. This criterium is very suitable to be used in combination with the ip group "local services" above. Please note that the "Listen" flags are dependent on an input module able to track tcp flags, like the ASDIC interceptor network sniffer, or the ARGUS record input module.

Legal traffic

Flags: Collection YES + Acceptance: accepted
Explanation: Will match any aggregates containing session accepted by the end system and/or firewall/routers. Note that similar criteria can be constructed with the ack/nack/permitted/denied flags, but it will not take the duplex traffic into account as the acceptance field does.

Illegal traffic

Flags: Collection YES + Acceptance: only rejected
Explanation: Will only match patterns not containing any successful sessions at all. This criterium is very useful to apply on firewall logs in combination with an ip group selecting the traffic originating from the internal network, applied in a scheduled predefined graphic search running once a day. It will then identify all traffic from the internal network not consistent with the firewall policy. This will typically detect configuration errors, viruses, worms, trojans, peer-to-peer programs and other things not supposed to exist on the internal network.
Please note, that although "only rejected" is specified, the hosts caught by this search will probably generate other unwanted flows accepted by the firewall. A detailed traffic aggregate search on the host(s) in question can reveal more information, or even better, a refined search doing this for you automatically.

Predefined searches

A predefined search ties together an ip group, a criterium and, optionally, a schedule.

click to enlarge

  • Name is a name of the predefined search.
  • IP Group is what ip group used.
  • Exclusions is an ip group matching what to exclude from the result (optional).
  • Criterium is what criterium used.
  • Action is what action used (optional).

  • Refine search is a powerful way of defining recursive searches (optional). This is a way of passing the search result from one search as input to another search. If this is selected, the fields of the result list as marked by "refine type" below is selected (a logical AND operation), and then passed as the IP group to the recursive search. The rest of the IP group is merged with the IP group specified in the recursively called search.

E.g. first perform a search looking for illegal patterns (i.e. patterns with only denied traffic). Use the IP source address from the hits of this search, and perform a new search (i.e. the refined search) for all patterns with those source addresses, but this time looking for successful traffic pattern (i.e. patterns with at least one session not denied). This way you will find potential attackers, but filter out much of all worms and such not generating any hits on any open services.

Be aware that a refined search may take more than ten seconds to execute, and is best run as scheduled search and not interactively.

  • Shared marks that the predefined search is to be accessible by other users than you (the current logged in user).
  • Email address for the recipient of a scheduled report. If not specified, this report is not run automatic.
  • Report type can be textual, packet graph, session graph or refined. A refined report is actual two (or more) chained reports; first this report are run, and all hits it gets, creates in combination with the refinement mask a dynamic ip group. This group is then used in the second report specified in the "refine search" field. See principle of operations for example when this can be useful.
  • Report interval is how often the report shall be scheduled to run (only automatic reports)
  • Time span specifies how far back in time the search shall look. Also see "last reported" below.
  • Hours since specifies what time stamp to use. "first seen", "last seen" or "baselined". Using "baselined" will generate a deviation report, "last seen" will re-report same events each time they show up. "Baselined" is the time ASDIC classified the pattern as a collector.
  • Last Reported tells you when this scheduled report last was run. Please note, this is the time for the last run, not the time it last produced a result report. A report run with resulting in no hits, will not generate a report mail.
  • Absence is not used today.
  • Sort index can be used to arrange the order the predefined searches will appear in the drop down menu in the search tab.

Predefined search have two usages. First they will make life easier for the users, especially the basic users. By selecting a predefined search, they do not need to know everything about criteria, ip groups and so.

The second usage, is for defining scheduled reports. If both "time span" and mail receiver is defined, the defined search will be run automatic and the result will be mailed to the receiver. In this way, you can be alerted of events in your network without using the user interface. This way of creating deviation reports, is one of the most important features of ASDIC.

Ping Research

ASDIC

Android