Re: Socket filtering
Re: Socket filtering
- Subject: Re: Socket filtering
- From: Michael Smith <email@hidden>
- Date: Thu, 27 Apr 2006 11:52:18 -0700
On Apr 27, 2006, at 10:14 AM, Eric Long wrote:
If he's just monitoring data content, though, he should make a local
copy for however big his buffer size is, and just let it through,
unless he's trying to catch bad data before it gets in, and wants to
check data spanning a buffer boundary, rather than just monitoring.
But if the buffer that was swallowed doesn't itself contain the data
you're trying to stop, then sending a partial buffer, and keeping a
local copy in the kext for the spanning check, rather than swallowing
it, is still an OK thing to do (assuming the data isn't malicious
unless complete - and if it's malicious when incomplete, then the
check should have matched already on the packet that was swallowed.
That's a bit broad of an assumption. The previous packet might
have just a
couple of bytes that match. It's hard to say how much data is
quantitatively malicious if its sensitive data. I can thwart a
transaction
when I know I've matched a pattern I'm looking for, but if I don't
hold
packets, a partial data transfer might actually be detrimental.
This suggests that your "maliciousness" analysis could use some work.
However, it also suggests that you are at least in part parsing a
structured exchange between two parties.
I'm scanning streams that other processes are conducting using an
NKE socket
filter. If I swallow a packet it is only intended to be temporary,
until I
can either get more data and determine to reinsert it based on the
new data
or arbitrarily set a timeout to reinsert it if no more data was
received.
I assume that there's more to it than this; if you decide to "thwart"
the transaction you're not going to reinsert the packet.
But if the socket closes and I don't get the data back into the stream
before that, the transaction ends up incomplete and its my fault. I
I think this is the part that's confusing us. Who is closing the
socket? Are you talking about a remote close, or a local close?
swallowed the packet only because I found a partial match at the
end of its
data holding out the possibility that more data was coming that might
demonstrate a true match.
What sort of "match"?
If I knew there was no more data to come, I wouldn't want to hold the
packet.
It sounds a lot to me like your basic analysis algorithm needs work.
Let me hazard a guess; you are trying to find specific data in email
or HTTP transactions, perhaps as part of the "icSPYWARE & ANTI
PHISHING" suite, using a naive string matching algorithm and
attempting to avoid knowing anything about the framing of the data in
these transactions. If you were to avail yourself of said framing
information, or better still, do this at a level where the framing
was implicit, none of this would be an issue.
Information systems tend to be structured, and working within the
structure is by definition easier than ignoring it. Frequently the
answer to "why is X hard?" is "because you should not be doing X".
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden