[PLUG-TALK] About those UCE senders ...

[Tomas K]

Another possible explanation would be round robin proxy/load-balancer
-- one internal IP is scanning your ports -- a proxy is sending
different packets over different egress ports externally - resulting in
the patterns you observe. On Tue, 2018-10-16 at 10:26 -0700, wes wrote:
> On Tue, Oct 16, 2018 at 8:49 AM Rich Shepard <rshepard at appl-ecosys.co
> m> wrote:
> >    These look like a single source has defined multiple host IPs on
> > the same
> > 
> > registered network just to send UCE, and each host doesn't
> > represent
> > 
> > end-user customers of an ISP.s
> > 
> > 
> > 
> >    Is this a reasonable interpretation? Again, I'm only curious
> > about such
> > 
> > consistent patterns almost every day from the same host country.
> > 
> 
>  That is certainly one possibility. There are several which could
> explain this behavior.
> 
> Maybe they were allocated the whole /24. If it were any smaller, I
> would expect the source IPs to be right next to each other (131-139
> are believable, but not the rest). The reality is that spam
> operations are constantly looking for hosts to carry their spam. ISPs
> often take steps to keep them out, but spammers have a lot of
> experience with getting around protections.
> 
> It's just as likely that a spammer signed up for multiple accounts at
> the same provider, or that multiple spam operations started using the
> same provider, or that one of those operations discovered a
> vulnerability that a given ISP did not protect against, which was
> used to compromise multiple clients of theirs... that's just off the
> top of my head, I could probably think of a lot more.
> 
> Entertaining reading: https://www.spamhaus.org/rokso
> 
> -wes
> 
> _______________________________________________
> PLUG-talk mailing list
> PLUG-talk at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug-talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pdxlinux.org/pipermail/plug-talk/attachments/20181016/ee0ba0aa/attachment.html>