>A simple case where this won't work,
>2 attackers, both request binding the same port 12345, now if one of
>them connects to 12345 you don't know which "Responder" object to use,
>you'll have to store the attackers ip address too.
>If the bound port times out, you'll have to take care to clean up the
>(unused) Responder Objects.
The Socket class inherits from Responder class, if I have the socket object
i have the responder ID and the attacker IP.
>This adds a lot of complexity to the nepenthes code itself, and won't
>be required for most cases.
>Therefore I'd say correlate in the module, as done in log-surfnet in a
>much simpler way.
I agree in that using events is better approach :-)
However I need new events for correlate hexdump operations, for example:
connection_accepted --> unknown shellcode --> saved hexdump.
[mailto:nepenthes-devel-bounces@...] On Behalf Of
Nepenthes Development Team
Sent: Monday, December 18, 2006 10:48 AM
Subject: Re: [Nepenthes-devel] Nepenthes SessionID-Responder
On 12/18/06, Nelson Williams <ngamazo@...> wrote:
> I am developing a nepenthes front-end with detailed log analysis and
> correlating from several sensors. In this sense the nepenthes logs are
> difficult to parse if I want correlate the entire sessions attacks with
> source, destination, hexdump or capture malware and used simulation
> dialogue. It is because in the log different sessions can be nested, for
> example, when nepenthes receive one attack while is processing other (the
> register log time don't help here :-)).
Did you look how log-surfnet correlates the events?
> The nepenthes architecture associate one "Responder" object with each
> session or received attack. May be, one way to resolve the nesting session
> problem is to associate one unique ID (rand()) to the "Responder Object"
> log the ID when the nepenthes is processing one specific attack. With the
> session ID is easy extracts independently each attack.
> But to implement this solution is needed modify all the logging call :-).
> However this feature is very important for correlating event and speed the
> processing of logs. I can participate in the implementation of this
> if the nepenthes-devel team thinks that it is worthwhile.
A simple case where this won't work,
2 attackers, both request binding the same port 12345, now if one of
them connects to 12345 you don't know which "Responder" object to use,
you'll have to store the attackers ip address too.
If the bound port times out, you'll have to take care to clean up the
(unused) Responder Objects.
This adds a lot of complexity to the nepenthes code itself, and won't
be required for most cases.
Therefore I'd say correlate in the module, as done in log-surfnet in a
much simpler way.
If you accept a connection, you have a temporary uniq id, the pointer
to the socket, this pointer is avalible everywhere.
If the shellcode requires you to take a action like binding a port,
you have the ptr to the socket bound to that port, and could correlate
it in the module.
If the shellcode starts a download, correlate it in the module as it
belongs to the session.
if the shellcode connects another host, correlate it in the module.
Things one would have to do be able to use this,
- create new Events to correlate the different possible actions
example connection_accepted -> shellcode_open_port ->
connection_accepted -> start_download_via_ftp -> download_success.
if a socket opens a new socket, correlate them, if a download is
started by a socket, correlate them.
- use these events when the action takes places
- make sure to be able to remove correlated actions when they are
gone, for example right now a unsuccessfull download is not
correlateable, as it does not notify somebody else about his failure,
this is very important to get the memory back
Even though this may sound complex, I think it will be much less work
and far less error prone than starting to pass Responder objects
between the classes in nepenthes itself.
Additionally it will allow to correlate information gatherd by a
module, for example the pcap files from module-honeytrap.
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Nepenthes-devel mailing list