Well, in almost any* case blacklisting reflection vectors by IP is an insanely bad practice. * — I can *think* of a use case when this could be an appropriate solution (I recall Netscout/Arbor once had such a use case), but in the overwhelming majority of incidents it is absolutely not, and you need to be one hundred percent sure you know what you're doing.
Agreed; drop the vector not the address, but was looking to just clarify the direction of things a bit. NB: I have just checked the IP addresses the OP has provided me with
(offlist) against our database of known reflection sources, and I confirm that none of those seem to ever host UDP software vulnerable to amplification
ty; good to know. They decide to completely ignore the emails, it seems like we're being
either spoofed *or people are attacking us with Sony's IP space*.
So you're getting inbound traffic that has Sony IP space source addresses in it? That does start to sound more like people trying to reflect off of you to Sony. What's the protocol and destination ports on the traffic you're receiving with Sony source addresses (and the source ports for good measure, if they're fairly consistent)? -- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal On Tue, Jan 7, 2020 at 10:54 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:
Peace,
On Tue, Jan 7, 2020 at 9:10 PM Hugo Slabbert <hugo@slabnet.com> wrote:
And you're sure that you are the reflection target not the reflection vector?
NB: I have just checked the IP addresses the OP has provided me with (offlist) against our database of known reflection sources, and I confirm that none of those seem to ever host UDP software vulnerable to amplification.
-- Töma