Re: Socket filtering
Re: Socket filtering
- Subject: Re: Socket filtering
- From: "Justin C. Walker" <email@hidden>
- Date: Thu, 27 Apr 2006 11:52:06 -0700
On Apr 27, 2006, at 10:14 , 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.
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.
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
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.
If I knew there was no more data to come, I wouldn't want to hold the
packet.
A few observations:
- if the underlying protocol is stream-based (like TCP), you will
see a packet terminating the connection, coming from the local
endpoint.
You won't know whether this packet is "graceful" or
"prejudicial" :-}
If "graceful", you should push the data out; otherwise, not.
Oh, and not
all stream protocols distinguish (leaving it to higher layers to
complete
a handshake to terminate).
- if the underlying protocol is datagram-based, you are hosed. It is
possible that the local endpoint-owner will call a "disconnect"
procedure
for the socket, but that need not translate into a real packet.
Even if
there is a "hook" to give you control in this case, most UDP-
spewers don't
do it, so the only way you know that there aren't any more
packets coming
is that there aren't any more packets coming :-}
In short, for real streams, you can fake it by looking for
terminating (e.g., FIN) packets. Otherwise, you have no idea what
comes next, or when.
It also occurs to me that by holding onto a packet, waiting for "the
next one", you are screwing around with the transport's idea of
timing, and potentially harming the connection, and perhaps the data
it carries.
Just keeping a copy of the current packet and pushing the packet out
doesn't seem like what you want (unless you just want to see what
passes by), so it's not clear to me how to get the 100% solution...
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large, Director
Institute for the Enhancement of the Director's Income
--------
The path of least resistance:
it's not just for electricity any more.
--------
_______________________________________________
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