Re: [Echelog-devel] Filter Attributes (message faking)

[Kamil T. <kt...@em...>]

On =C8t, 2003-01-16 at 11:48, Martin Ma=E8ok wrote:
> On Thu, Jan 16, 2003 at 10:30:32AM +0100, Marek Zoth wrote:
>=20
> > >    MSG.agent_id
> > >    MSG.agent_instance_id
> > >    MSG.agent_host_id
>=20
> > Maybe it will be possible then to workaround a small problem with
> > message faking.
>=20
> I assume that knowing those 3 attributes from one (compromised)
> monitored host gives you real chance to guess correct 3 attributes of
> messages from another (non-compromised) monitored host. That gives you
> real chance to send fake message from compromised agent that will be
> accepted by server as the real ones from other non-compromised host
> because the Filter doesn't know the IP/SSL channel through which the
> message really came from.
>=20

True. When the Filter is enhanced, then one may set up more than one
receivers and attach a Filter to each.

But obviously this identification filter rule should be also added to
Receiver (thus it would be able to drop messages with fake or invalid
headers). If there is a proxy (somewhere on the path) it also should
drop such forged packets. If it didn't you can consider the whole
segment compromised.


> Either the message should contain some (not easily forged) hosts's
> signature or at least the tests should be done earlier on the Receiver
> which knows the IP/SSL channel the message came from.
>=20
> Maybe, we can gain something just by adding some not easily guessed
> content of some message attribute, say MSG.password, which is 1-1
> related to host. If there are agents on hosts A and B and the server
> is C then when I compromise A I can make false messages that looks
> like those from B because I can know/guess B's *_id attributes. The
> server C now contains fake messages. If there is another not easily
> guessed attribute then I can't easily forge messages from B because
> message from B which doesn't have correct B's password attribute
> should be invalid (which can be checked online/offline by any Filter
> on C).
>=20
> --=20
>          Martin Ma=E8ok                 http://underground.cz/
>    mar...@un...        http://Xtrmntr.org/ORBman/

If the solution proposed above takes place there is no need for
MSG.password field as it doesn't increase inherent security.

Signing each message would be a very demanding task. It has been already
said that it is undesirable for agent systems.

Kamil