[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