[nos-bbs] icmp
jj
ve1jot at eastlink.ca
Tue Dec 20 20:41:44 EST 2022
jnos here has been getting slammed with icmp ddos/probes/pings from
52.94.35.0/24 (botnet?) an amazon(?)
subnet...I have icmp echo off, and it still replies to ping probes, and
is responding to the icmp
attack as well...icmp quench is off...shouldn't that be the default?
"
7. Recommendation Regarding RFC 1016
[RFC1016] describes an experimental approach to the handling of ICMP
Source Quench messages in hosts that was considered in 1987. Even
though RFC 1016 has never been on the IETF Standards Track, for
clarity and avoidance of doubt we note that the approach described in
[RFC1016] MUST NOT be implemented.
8. Security Considerations
ICMP Source Quench messages could be leveraged for performing blind
throughput-reduction attacks against TCP and similar protocols. This
attack vector, along with possible countermeasures, has been
discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently
ignoring ICMP Source Quench messages, as specified in this document,
eliminates the aforementioned attack vector.
For current TCP implementations, receipt of an ICMP Source Quench
message should not result in security issues because, as noted in
[RFC5927] and [CPNI-TCP], virtually all current versions of popular
TCP implementations already silently ignore ICMP Source Quench
messages. This is also the case for SCTP and DCCP implementations.
Hosts, security gateways, and firewalls MUST silently discard
received ICMP Source Quench packets and SHOULD log such drops as a
security fault with at least minimal details (IP Source Address, IP
Destination Address, ICMP message type, and date/time the packet was
seen)."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20221220/40623fd4/attachment.html>
More information about the nos-bbs
mailing list