<div dir="ltr"><div dir="ltr">I just found this in my spam folder.<div><br></div><div>The probes come in on many ports, so they are just looking for something open I suppose.</div><div><br></div><div>I'll look into that INVALID tag, it's something I'm not familiar with (yet).</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 28, 2020 at 3:29 PM Trevor Cordes <<a href="mailto:trevor@tecnopolis.ca">trevor@tecnopolis.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-02-27 Scott Toderash wrote:<br>
> [10192947.300008] UDP: bad checksum. From <a href="http://1.2.3.4:10398" rel="noreferrer" target="_blank">1.2.3.4:10398</a> to<br>
> <a href="http://3.4.5.6:5060" rel="noreferrer" target="_blank">3.4.5.6:5060</a> ulen 237<br>
> <br>
> I started getting some of this yesterday on one host.<br>
> <br>
> I think that there is a way to use regex and fail2ban to block flood <br>
> attacks like this. Does anyone have the recipe?<br>
> <br>
> It comes in on various ports. This example is port 5060 but the host <br>
> does not have anything listening there.<br>
<br>
I think just simple iptables -j DROP for those would be more efficient<br>
than fail2ban.  The only thing fail2ban would buy you is if the hitters<br>
are also hitting valid ports with valid packets and you want to<br>
preemptively block them.  I wouldn't think it was worth it.<br>
<br>
iptables -A earlychain -p all -m conntrack --ctstate INVALID -j DROP<br>
iptables -A earlychain -p all -m state --state INVALID -j DROP<br>
<br>
Not sure if those catch invalid checksum... but they should?  If the<br>
traffic is confined to certain ports, just -p udp --dport xxxx -j DROP<br>
them.<br>
<br>
In any event, besides the kernel log (which is probably settable), even<br>
letting the kernel drop them post-iptables isn't really taking up many<br>
resources.<br>
<br>
You should capture some of the packets to see what the content is!<br>
Might be interesting.<br>
<br>
And 5060 is sip... you sure you aren't running some voip that is<br>
getting handled in a wonky way?  Is the source IP somewhere in CN or<br>
from legit IPs you might have business with?<br>
</blockquote></div></div>