Hello Balazs,
My thanks for your review. I'll incorporate your comments on sections
5 and 5.4 but I have some observations on your comments on section 5.2.
I've placed some comments in-line.
Thanks,
Chris
At 10:14 AM 7/12/00 +0200, Balazs Scheidler wrote:
>>
>> I've cleaned up the original draft a bit and have posted it here:
>> http://www.employees.org/~lonvick/draft2.txt
>>
>> I know that everyone is anxious to discuss the next two areas but
>> we really can't do that until we can get consensus on the Security
>> Considerations section of this draft. Please take a moment to
>> review this and send your comments back to the group.
>
>Hi everyone,
>
>Here are some comments on the security considerations chapter of the draft
>above:
>
>chapter 5.
>----------
>
>"One possible consequence of this is that a misconfigured machine may
>send Syslog messages to a collector representing itself as another
>machine. The administrative staff may become confused that the status
>of the supposed sender of the messages may not be accurately reflected
>in the received messages. The administrators may not be able to discern
>that there are two machines representing themselves as the same machine
>unless they view the packets on the wire and differentiate the packets
>based upon their source IP address."
>
>Since UDP packets can be easily spoofed, source IP address is not a good
>measure to differentiate sending hosts. A MAC address would be a better bet,
>but it can be spoofed as well. Even TCP connections can be spoofed using ARP
>poisioning, but it's a bit more difficult and more prone to errors.
If the syslog packets are coming through a router, then the MAC
addresses are changed as well. I do understand your concern with
the scenario however and I'll make some changes to the paragraph.
>chapter 5.2.
>------------
>
>"Also, without any sequence indication, messages may be recorded and
>replayed. An attacker may record a set of messages that indicate normal
>activity of a machine. At a later time, that attacker may remove that
>machine from the network and resend the Syslog messages to the
>collector. The administrators would find nothing unusual in the
>received messages and their receipt would again indicate normal activity
>of the machine."
>
>Since anyone can send anything, no sequence information would prevent them
>doing that, though if the first seqno is generated randomly the attacker may
>not know its value at least as long as she can't sniff it off the network. I
>think this paragraph should be removed. Sequence information would be
>helpful in reordering messages, but nothing else. (of course if extended
>with cryptographical tools, sequence numbers can prevent replay attacks, but
>not in this case)
The purpose of the entire section 5 is to bring to light the security
concerns of the current Syslog protocol. This particular section shows
another potential problem since there is no sequence information built
into the protocol. I hope that people who use the current Syslog protocol
have a clue about this, but I think that this needs to be documented to
make this ID complete. It may also be used by the authors of future IDs
as they may choose to propose mechanisms that will address this concern.
(..and I hope that they do. :-) As you note, unprotected sequence numbers
as well as unprotected timestamps will not prevent replaying as those may
be easily modified.
>chapter 5.4.
>------------
>
>"Besides being discarded, Syslog messages may be damaged in transit, or
>an attacker may maliciously modify them. In either case, the original
>contents of the message will not be delivered to the collector. If an
>attacker is positioned between the sender and collector of Syslog
>messages, then he may be able to modify those messages to hide
>unauthorized activities."
>
>UDP packets are protected by a 16 bit checksum value, which at least
>indicates some damage.
I'll note that the UDP checksum will offer some protection against
in-transit damage if it is used.
>--
>Bazsi
>PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
> url: http://www.balabit.hu/pgpkey.txt
