Probably a compromised Stanford system, that makes one suspect those coltish "Stanford students" instead of the real culprit who is more likely either A/ to frustrate your service, such as tor or wikileaks etc, B/ to be a script kiddie, C/ to be an APT.
--------------------------------------------
En date de : Mar 9.4.19, Keith Williams <keithwilliamsnp(a)gmail.com> a écrit :
Objet: Re: [bitfolk] I know I should not take it personally but ...
À: "BitFolk Users" <users(a)lists.bitfolk.com>
Date: Mardi 9 avril 2019, 9h00
Thanks,
I'll check it out. 6 hits a second over more than 24
hours is well over the top, what ever their excuse
On Tue, 9 Apr 2019
at 14:55, Ryan Bibby <r.bibby(a)gmail.com>
wrote:
Hi Keith
Stanford University you say?
At work
I had some suspicious traffic from some Stanford University
addresses. I contacted there abuse contact and it turned out
they host a commercial vulnerability scanning service. In my
case they had a legitimate contract to do this, but the
message had not reached me.
It's possible that in your case
it's the same tool rather than students, so it may be
worth contacting them to find out why they are scanning your
services.
Best
wishes
Ryan
On Tue, 9 Apr
2019, 04:45 Keith Williams, <keithwilliamsnp(a)gmail.com>
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-----
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
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-----
Hi All,
How can I get access to my Bitfolk backup, so that I can restore it to a
local machine, and prove that I have enough data included?
The backup can only be reached from the VPS or recovery environment if
the VPS will not boot.
I guess I am asking how to set up a link in SSH so that I can mount the
backup share on my home kit via the VPS?
Regards
Ian
--
Ian Hobson
Tel (+351) 910 418 473
Hi,
For those of you who missed it, like I did, jessie-updates has now been
removed from the Debian mirror network (and therefore Bitfolk's
apt-cacher).
The original announcement from 2019-03-20 is here:
https://lists.debian.org/debian-devel-announce/2019/03/msg00006.html
I'd been tracking the error in my daily updates since the 21st (the morning
after it was removed) but hadn't done anything about it as security updates
were still coming through (and still will as Jessie is on the Debian LTS
programme until 2020-06-30).
Of course, jessie-updates has not received any actual updates since last
year (2018/05/17, https://wiki.debian.org/StableUpdates ).
Regards,
@ndy
--
andyjpb(a)ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
I seem to have lost connection to both my VPS, trying via normal SSH and
XEN. However my email server is still working and I can communicate with
that. Also cannot connect with webmin. It seems that ports 80 and 443 are
OK but 26, 922 and 10000 are down somehow. Both VPS are on different
machines I have not touched firewall settings, but anyway they would not
affect XEN
[image: image.png]
Hello,
Unfortunately some security flaws have been discovered in the hypervisor
software we use (Xen) so we will need to patch and reboot everything
before the public release of the details on 5 March.
We will do this work in the early hours of the morning (UK time) between
Saturday 2 March and Monday 4 March. You should already have received an
individual email confirming the hour-long maintenance window specific to
your server(s). The actual work for each server is expected to take
10–30 minutes within that window.
As before we should be able to do a suspend/restore of your guest if you
have enabled that at:
<https://panel.bitfolk.com/account/config/>
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi,
For a long time I've been assuming that you prefer scheduled maintenance
to take place in the early hours of weekends so that there is less
disruption. But sometimes people say they don't prefer this, and I
realise I don't actually know what your preferences are.
So, please help me out, let me know:
https://twitter.com/bitfolk/status/1099260516579622912
(If you don't have a twitter account you can just let me know by direct
email off-list)
Thanks!
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi all,
I’m exploring the idea of using two VPSs on different hosts to implement some sort of failover mechanism. Is anyone here doing something similar, or have any recommendations?
Regards,
Chris
—
Chris Smith <space.dandy(a)icloud.com>
I have in the back of my mind that there's an email thread that may be
related to this, but I can't find it in my mail archives unfortunately -
it may even not be this list. Anyway...
I've just been looking to do a do-release-upgrade from Ubuntu 16.04 to
18.04 and come across a raft of error messages along the lines of:
Err http://apt-cacher.lon.bitfolk.com/ubuntu/gb.archive.ubuntu.com/ubuntu bionic/main Sources
403 Forbidden file type or location: /ubuntu/gb.archive.ubuntu.com/ubuntu/dists/bionic/main/source/by-hash/SHA256/0e05b8e93cbdfe5d41306e9d34c893fa23f3087a58c637b882cb0f133375a133 [IP: 2001:ba8:1f1:f079::2 80]
My Google-fu is failing me at the moment as nothing I'm finding is quite
matching up, so I thought I'd see if the collective knowledgebase of
fellow Bitfolk folks had come across this.
One way around, I guess, would be to bypass the Bitfolk cache, but that
doesn't seem to make sense, particularly in the long run if the change
ends up needing to be permanent. Is there a change I can make locally,
or is it down to the Bitfolk cache itself, possibly waiting for a file
to be re-cached? I'm guessing it is likely related to recent updates to
apt.
--
Paul Tansom | Aptanet Ltd. | https://www.aptanet.com/ | 023 9238 0001
Vice Chair, FSB Portsmouth & SE Hampshire Branch | http://www.fsb.org.uk/
=============================================================================
Registered in England | Company No: 4905028 | Registered Office: Ralls House,
Parklands Business Park, Forrest Road, Denmead, Waterlooville, Hants, PO7 6XP
