Evaluate Sessions

[glaslos]

With session tracking #7 we can:

• Evaluate how successful our responses are in triggering multiple stages
• Attempt fingerprinting the session owner (bots/tools/persons)

[glaslos]

You probably want to have a dict with all the request paths for a session and then count how often a certain path was accessed. Maybe also a timestamp for when which path was accessed. I kind of want to see which paths the attacker tried to access when and in which order.

[glaslos]

This is a rather open task so don't get hung up on it.

[glaslos]

Moved this issue to gsoc_sprint_3

[glaslos]

I think a good start for this task is to look at RFI attacks. They usually start with an injection of a id script. They run some simple script that should return some information about the system. If successful, they inject the bot. In the sessions, we should be able to see the stages. Maybe we should start this with a tool to investigate the stored sessions.

[afeena]

1.Maybe we should store the attack type in the session? For now we store paths, and we need to analyze them, i.e. we should do the same thing that we do in detection.
2.When we should initialize investigation tool? When the session is added/updated, or after session is pushed to redis? If we use redis, maybe we need update old session in the redis?

For now I don't fully understand how to investigate stored session. Count how often was accessed the certain path and it's type? Use paths timestamps to measure periods of attacks? (I think humans more slowly than network tools and crawlers). If we use hidden links, we can't with 100% say it's human or bot (because of the fact, that attacker can use page source to access hidden links), but we can maybe store that someone have accessed hidden link and use it for investigation

[glaslos]

Both are good ideas, we definitely want the attack type stored in the session. You can start with adding requests/second to the session when you close it.

[afeena]

What we expect as a result? Maybe we make json for every session with stats, e.g.

    "uuid":"session uuid",
    "user_agent":"ua",
    "sensor_uuid":"suuid",
    "start time":"start timestamp",
    "end_time":"end timestamp",
    "requests/second":"10",
    "approx_time_between_requests":0.1,
    "accepted_paths":20,
    "errors":"no",
    "paths":[  
        {  
            "path":"path1",
            "attack_type":"lfi",
            "payload":"/etc/passwd",
            "time":"timestamp"
        }
    ],
    "possible_owner":"human"

[afeena]

I think about storing evaluation result. Maybe we don't need raw sessions in redis, maybe we should store only sessions, that were evaluated?

[glaslos]

You are right, we can keep the open sessions in the TANER Python process memory. Create a separate issue for it.

Closing this issue after merging 7087bb8