Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
> Security Comments > > * I think almost all writable data nodes here are sensitive, because a network > attacker's first move is to block any logging on the host, and many of the data > nodes here can be used for this purpose. > > [clw1] I will reword the security section to include all writeable nodes as sensitive. > > * Re: readable data nodes, I'm not > sure which are sensitive, and the document should give an example or two rather > than just say "some". Otherwise the security advice is not actionable. One > example: "remote" sections leak information about other hosts in the network. > > [clw1] This text was lifted from another model. I will review the readable nodes and update. > > * Write operations... can have a negative effect on network operations. - I would > add "and on network security", because logs are often used to detect security > breaches. > > [clw1] I will add this phrase. > The fact that the syslog data nodes are write-sensitive can be made explicit in the model by making the whole configuration tree nacm:default-deny-write, and making read-sensitive subtrees nacm:default-deny-all. Thanks, Gary Wu Agreed. Usually my modules have the NACM annotations and then, in the Security Considerations section, I'm sure to point them out. K. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
> Security Comments > > * I think almost all writable data nodes here are sensitive, because a network > attacker's first move is to block any logging on the host, and many of the data > nodes here can be used for this purpose. > > [clw1] I will reword the security section to include all writeable nodes as sensitive. > > * Re: readable data nodes, I'm not > sure which are sensitive, and the document should give an example or two rather > than just say "some". Otherwise the security advice is not actionable. One > example: "remote" sections leak information about other hosts in the network. > > [clw1] This text was lifted from another model. I will review the readable nodes and update. > > * Write operations... can have a negative effect on network operations. - I would > add "and on network security", because logs are often used to detect security > breaches. > > [clw1] I will add this phrase. > The fact that the syslog data nodes are write-sensitive can be made explicit in the model by making the whole configuration tree nacm:default-deny-write, and making read-sensitive subtrees nacm:default-deny-all. Thanks, Gary Wu ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
Hi Clyde, Thank you for responding to my comments. I am OK with all of your responses. Best, Yaron On 19/02/18 13:02, Clyde Wildes (cwildes) wrote: Yaron, Thanks for your review. My answers are inline as [clw1]. On 2/18/18, 6:31 AM, "Yaron Sheffer" wrote: Reviewer: Yaron Sheffer Review result: Has Issues General Comments * The semantics of pattern matching is not clear: "and/or the message text" - are there cases where you only match the text but not the facility/severity? * [clw1] Yes. There are three cases: 1. Match on facility/severity; 2. Match on the regex pattern; 3. Match on both facility/severity and the regex pattern. It's very confusing to specify rollover in minutes, but retention in hours. People are bound to get this one wrong. [clw1] I will change the retention to minutes unless others object. * Interface selection: the feature makes sense, but I think the description is incorrect. "This leaf sets the source interface to be used to send messages to the remote syslog server. If not set, messages sent to a remote syslog server will contain the IP address of the interface the syslog message uses to exit the network element". AFAIK the source IP will always correspond to the interface, but this feature allows you to select a particular one. [clw1] You are correct. I will modify the description to make this clearer. How about: "This leaf sets the source interface to be used to send messages to the remote syslog server. If not set, messages can be sent on any interface." * Usage examples: the second example lists a specific IPv6 address, but the Yang snippet shows a domain name. [clw1] Thanks for catching this error. I will fix this in the next revision. * A generic question (I am new to the Yang ecosystem): I understand most implementers will use this module from https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang - is this the expectation? If so, why not add a link from the RFC into the repo, to make it easier for people to find? [clw1] It is standard practice to include the model in the RFC AFAIK. I have not seen github links published in any other RFCs. Security Comments * I think almost all writable data nodes here are sensitive, because a network attacker's first move is to block any logging on the host, and many of the data nodes here can be used for this purpose. [clw1] I will reword the security section to include all writeable nodes as sensitive. * Re: readable data nodes, I'm not sure which are sensitive, and the document should give an example or two rather than just say "some". Otherwise the security advice is not actionable. One example: "remote" sections leak information about other hosts in the network. [clw1] This text was lifted from another model. I will review the readable nodes and update. * Write operations... can have a negative effect on network operations. - I would add "and on network security", because logs are often used to detect security breaches. [clw1] I will add this phrase. * Also add an advice, similar to the one on "pattern match", that the private key used for signing log messages MUST NOT be used for any other purpose, and that the implementation of this data node must ensure this property (I'm not sure how). The rationale: if the TLS private key is used, for example, this could result in a signing oracle for TLS and eventually a MITM attack. [clw1] I will add this advice. Thanks, Clyde ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
Yaron, Thanks for your review. My answers are inline as [clw1]. On 2/18/18, 6:31 AM, "Yaron Sheffer" wrote: Reviewer: Yaron Sheffer Review result: Has Issues General Comments * The semantics of pattern matching is not clear: "and/or the message text" - are there cases where you only match the text but not the facility/severity? * [clw1] Yes. There are three cases: 1. Match on facility/severity; 2. Match on the regex pattern; 3. Match on both facility/severity and the regex pattern. It's very confusing to specify rollover in minutes, but retention in hours. People are bound to get this one wrong. [clw1] I will change the retention to minutes unless others object. * Interface selection: the feature makes sense, but I think the description is incorrect. "This leaf sets the source interface to be used to send messages to the remote syslog server. If not set, messages sent to a remote syslog server will contain the IP address of the interface the syslog message uses to exit the network element". AFAIK the source IP will always correspond to the interface, but this feature allows you to select a particular one. [clw1] You are correct. I will modify the description to make this clearer. How about: "This leaf sets the source interface to be used to send messages to the remote syslog server. If not set, messages can be sent on any interface." * Usage examples: the second example lists a specific IPv6 address, but the Yang snippet shows a domain name. [clw1] Thanks for catching this error. I will fix this in the next revision. * A generic question (I am new to the Yang ecosystem): I understand most implementers will use this module from https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang - is this the expectation? If so, why not add a link from the RFC into the repo, to make it easier for people to find? [clw1] It is standard practice to include the model in the RFC AFAIK. I have not seen github links published in any other RFCs. Security Comments * I think almost all writable data nodes here are sensitive, because a network attacker's first move is to block any logging on the host, and many of the data nodes here can be used for this purpose. [clw1] I will reword the security section to include all writeable nodes as sensitive. * Re: readable data nodes, I'm not sure which are sensitive, and the document should give an example or two rather than just say "some". Otherwise the security advice is not actionable. One example: "remote" sections leak information about other hosts in the network. [clw1] This text was lifted from another model. I will review the readable nodes and update. * Write operations... can have a negative effect on network operations. - I would add "and on network security", because logs are often used to detect security breaches. [clw1] I will add this phrase. * Also add an advice, similar to the one on "pattern match", that the private key used for signing log messages MUST NOT be used for any other purpose, and that the implementation of this data node must ensure this property (I'm not sure how). The rationale: if the TLS private key is used, for example, this could result in a signing oracle for TLS and eventually a MITM attack. [clw1] I will add this advice. Thanks, Clyde ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
Reviewer: Yaron Sheffer Review result: Has Issues General Comments * The semantics of pattern matching is not clear: "and/or the message text" - are there cases where you only match the text but not the facility/severity? * It's very confusing to specify rollover in minutes, but retention in hours. People are bound to get this one wrong. * Interface selection: the feature makes sense, but I think the description is incorrect. "This leaf sets the source interface to be used to send messages to the remote syslog server. If not set, messages sent to a remote syslog server will contain the IP address of the interface the syslog message uses to exit the network element". AFAIK the source IP will always correspond to the interface, but this feature allows you to select a particular one. * Usage examples: the second example lists a specific IPv6 address, but the Yang snippet shows a domain name. * A generic question (I am new to the Yang ecosystem): I understand most implementers will use this module from https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang - is this the expectation? If so, why not add a link from the RFC into the repo, to make it easier for people to find? Security Comments * I think almost all writable data nodes here are sensitive, because a network attacker's first move is to block any logging on the host, and many of the data nodes here can be used for this purpose. * Re: readable data nodes, I'm not sure which are sensitive, and the document should give an example or two rather than just say "some". Otherwise the security advice is not actionable. One example: "remote" sections leak information about other hosts in the network. * Write operations... can have a negative effect on network operations. - I would add "and on network security", because logs are often used to detect security breaches. * Also add an advice, similar to the one on "pattern match", that the private key used for signing log messages MUST NOT be used for any other purpose, and that the implementation of this data node must ensure this property (I'm not sure how). The rationale: if the TLS private key is used, for example, this could result in a signing oracle for TLS and eventually a MITM attack. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod