The admins at Stanford ought to be made aware of this, because it is a sizeable security
hole, and especially because they ought to have a bleeding edge installation.
The bot managers look for vulnerabilities in software - this is no novelty.
What is novel here is that they have targetted a big-ass trunk-level system.
Maybe Keith is just the testing ground victim for an APT who need a backwater like bitfolk
in their scale-up debug routine.
Did Stanford use any Chinese routers?
If so, are the Chinese responsible?
Or have the Chinese router backdoors been discovered by another group who want the
suspicion thrown onto the Chinese?
--------------------------------------------
En date de : Mar 9.4.19, admins <admins(a)sheffieldhackspace.org.uk> a écrit :
Objet: Re: [bitfolk] I know I should not take it personally but ...
À: users(a)lists.bitfolk.com
Date: Mardi 9 avril 2019, 13h36
I wish all the pesterees I have been monitoring came
from one
block.
We had a run of being targeted by a botnet herder.
The IP's were
far too many, and far too globally diverse to
summarize into a
handy block.
I did ensure it cost them a couple of bots though by
forwarding
on a size-able sample to the relevant abuse emails,
looking them
up via whois. For what good this does. (Very little).
Wish there
was a streamlined script/tool to do this. If everyone
reported
those that try it on, and ISP's did something
about it, there
would be a fraction at it.
If I had more time and inclination (which I had
neither) I would
probably looked at the fact that they would have all
been a
consistent bot to see if I could reverse a bot and
then take down
the net, from what I had learned form the one.
As my ssh was not a general use I could whitelist the
ranges that
would reasonably have access to it, and port knock a
disable to
the whitelist to allow initial connections to be made
from the
wider net if we needed. Thereafter con-track allowed
the session
to continue.
80 and 443 I get, but what was on 7777, would that
have been your
ssh port by any chance ??
BTW it is difficult not to take it personally when it
is
something we have built and nurtured. Your feelings
are fully
understood. Noe where did I stash that minigun....
LOL
Cheers
Kirbs
On 09/04/2019 04:44,
Keith Williams
wrote:
No questions,
just a bit of spleen venting.
Having been on a little break to deepest province
where internet
is very poor, I came back to find my vps under a lot
of attacks.
Firstly once or twice a day a website was going down
for upto 5
minutes a day. Sorted that. Fail2ban was not running
for some
reason (again sorted by reinstalling from Debian
backports)
Found that known spamming IPs were hitting it hard
but also were
hitting at virtual hosts that no longer exist -
Apache then
redirects to the default virtual host. All sorts of
thing then
happening including SSL timeouts etc.. Fail2ban,
adding a daily
updated set of addresses from a content spammer
blacklist to the
firewall and removing A and AAAA records where
possible from
Bind for those old domains. ( I had to leave some
like
weirdname.exmple.com
as they are used by other systems such as honeytraps
etc) all
seemed to bring that very much under control. Some
were looking
for URLs that have not existed for a long long
time.
Hours of perusing debug logs and tracking IPs via
Google
persuaded me to reinstall something I have not used
in a while.
My SSH is quite safe, I use a different port,
don't allow
password sign on etc. So there is nothing listening
on port 22.
So set up that any attempt there, the IP gets added
to a
naughtyboy set then is logged and dropped. Any
future visits by
that IP to any port, logged and dropped. Bit like
F2B but this
is more of a permaban.
Within seconds there were half a dozen IPs in the
set. All in
the same /21 CIDR block. The logs show them coming
back up to
twice a second each for at least 24 hours now. They
go for ports
22.23.53, 80, 443 and 7777. That last one is
particularly nasty.
They have each done a couple of pings (blocked of
course) The
group of 3 IPs all are registered to Stanford
University, So
probably some students
Keith
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
-----La pièce jointe associée suit-----