bro
>Robin,
> I am trying to test how the signature engine works with snort rules.What I do is loading http-request.bro and snort.bro, adding "redef signature_files += snort-default.sig;" in the latter and visiting the host by "http://……/etc/passwd".But there is still no rule matching.
> I find that in the function of Match in class RuleMatcher, "m->state->Match((const u_char*) data, data_len, bol, eol)" still returns false.Would you please tell what's wrong?
>
>Tad
>
>
>
>
>
>
Greetings
I am trying to use bro to read tcpdump files for the purposes of
characterizing network traffic (not just that which is directed to the
host). It has a more consistent output format than tcpdump, I'm going to
want to do some filtering at some point, and it might be easier than trying
to write my own routines from libpcap (maybe). The documentation is robust,
which is a 'good news'/'bad news' situation. Is there a simple explanation
for how to make bro report _everything_?
Thanks
Mike
Vern,
I am trying to test how the signature engine works with snort rules.What I do is loading http-request.bro and snort.bro, adding "redef signature_files += snort-default.sig;" in the latter and visiting the host by "http://……/etc/passwd".But there is still no rule matching.
I find that in the function of Match in class RuleMatcher, "m->state->Match((const u_char*) data, data_len, bol, eol)" still returns false.Would you please tell what's wrong?
Tad
廖章军
liaozj(a)netpower.com.cn
2004-05-27
------ NOTICE ------------ NOTICE ------------ NOTICE ------
1. The LBNL VirusWall REMOVED a virus from this message.
The message is now safe to open.
2. If you need help or have questions, contact the
Help Desk at 510-486-HELP.
3. For information, please visit:
http://www.lbl.gov/ITSD/Security/vulnerabilities/virus.html
------------------------------------------------------------
Found virus PE_BAGLE.N-O in file Message.pif
The uncleanable file Message.pif is moved to /etc/iscan/virus_quarantine/virKTFWzbWuR.
---------------------------------------------------------
------ NOTICE ------------ NOTICE ------------ NOTICE ------
1. The LBNL VirusWall REMOVED a virus from this message.
The message is now safe to open.
2. If you need help or have questions, contact the
Help Desk at 510-486-HELP.
3. For information, please visit:
http://www.lbl.gov/ITSD/Security/vulnerabilities/virus.html
------------------------------------------------------------
Message.pif is removed from here because it contains a virus.
---------------------------------------------------------
I want to use snort rules in Bro.But Bro does not use them defaultly now.Would you please tell me a example how to use a snort rule in Bro? Thanks a lot!
dul
Hi Robin,
I've been looking at the serialization code in Bro for a while now and
I've hit a dead end. It'd be really cool if you could help me out
because I think I simply don't get it :)
I think I've basically understood the concepts of SerialObj, Serializer
and SerializationFormat -- I think I would have structured things the
same way. I'm getting lost in the details though:
- When exactly and why does a class have to implement Unserialize() and
Serialize()? What's their relationship to DoSerialize() and
DoUnserialize()? The comments in SerialObj.h are a bit vague in that
regard.
- It seems the idea of sending ahead an identifier to the receiving end
that tells it what to do with the following data exists three times:
* in the SER_xxx constants and the factory approach in
IMPLEMENT_SERIAL
* in the character constants 'i', 'e', 's' etc in Serializer.cc
* in the MSG_xxx constants in RemoteSerializer.cc.
I think the latter are partially internal to the remote<->local
communication and can hence mostly be ignored for understanding the
serialization code, right? If you could quickly explain the difference
between the first two that'd be great.
The next thing I noticed are the hardcoded (un)seralization methods in
Serializer:
bool Serialize(const ID& id, const SerialInfo& info);
bool Serialize(const char* func, val_list* args);
bool Serialize(const StateAccess& s);
bool Serialize(const Connection& c);
bool Serialize(const Timer& t);
virtual void GotID(ID* id, Val* val) = 0;
virtual void GotEvent(const char* name, double time,
EventHandlerPtr event, val_list* a) = 0;
virtual void GotFunctionCall(const char* name, double time,
Func* func, val_list* args) = 0;
virtual void GotStateAccess(StateAccess* s) = 0;
virtual void GotTimer(Timer* t) = 0;
virtual void GotConnection(Connection* c) = 0;
bool UnserializeID();
bool UnserializeCall();
bool UnserializeStateAccess();
bool UnserializeTimer();
bool UnserializeConnection();
Are these special in a way to have them implemented this way? Couldn't
there be a "received" callback per SER_xxx constant that resides as
a static method in the serializable classes themselves? So we can avoid
hardcoding anything?
- Following the comments in SerialObj.h, I see what I need to do to make
a class's objects serializable. I presume that the correct way to ship
an object to a serializer is by calling SerialObj::Serialize() with the
appropriate serializer. What are my options for picking them up at the
receiving end?
Oh and RemoteSerializer::ProcessSerialization() calls Unserialize()
passing a SerialInfo, but Serializer::Unserialize() expects a bool -- is
that intended?
The reason why I'm looking at this is that I'm trying to find the right
knobs to tweak to allow arbitrary *local* client applications to feed
information into Bro (like a tuned sshd that can feed its events and
traffic to a local Bro) without reinventing the wheel ...
Thanks so much!
Best,
Christian.
--
________________________________________________________________________
http://www.cl.cam.ac.uk/~cpk25http://www.whoop.org
Hi everybody !!!
As I explained in a previous mail, I'd like to log information using
Bro, in particular http payloads for each connection seen on a network.
I was looking for another way than signatures to manage this. Thanks for
your answers, but finally, I think signatures is not a so bad way to
handle this, since it can be easily extended to other protocols by just
changing port numbers in the rules and also because I can format output
the way I want in a Bro script.
So, let's see the new problem... :-(
At the moment, I use these signatures :
signature http-request {
ip-proto == tcp
dst-port == 80
payload /.*/
event "http-request"
}
signature http-reply {
ip-proto == tcp
src-port == 80
payload /.*/
event "http-reply"
tcp-state responder
}
signature http-effective-request {
ip-proto == tcp
dst-port == 80
payload /.*/
event "http-effective-request"
requires-reverse-signature http-reply
}
In fact, I can get events for http-request, http-reply, and
http-effective-request (which means Bro has effectively matched a
(request, reply) couple).
Then, here is the way I manage the data in a Bro script :
event signature_match(state: signature_state, msg: string, data: string)
{
if (msg == "http-request")
{
current_session$req$payload = data;
}
if (msg == "http-reply")
{
current_session$rep$payload = data;
}
if (msg == "http-effective-request")
{
current_session$startTime = state$conn$start_time;
current_session$IP_clt = state$conn$id$orig_h;
current_session$IP_srv = state$conn$id$resp_h;
log_info(current_session);
}
}
where log_info is a function I defined to log info ;-) contained in the
current_session record.
Moreover, I load http-reply (so http and http-request are also loaded)
and signatures modules in this script.
Now the results :
On my computer, it works perfectly, but I'm the only one generating http
traffic... ;-)
But when I launch this on a real probe, I get a "Segmentation Fault"
after a random time.
I dumped a core, to locate the problem, and it seems to crash in
RuleMatcher::ExecRule.
So, my question : What's the problem ??? (I know there are better
questions, but... ;-) )
Can it be due to an excessive traffic ???
Other information :
- Traffic : about 5000 packets/s
- HTTP traffic only : about 500 packets/s (I use a tcpdump filter to
limit to this kind of traffic)
- top command gives me : %CPU = max about 15% and %MEM = max about 3%
Thanks by advance,
Yohann.
