Hi all,
I would be very grateful if any Debian expert out there could offer me some
advice.
Somehow, probably editing my sources.list(s) in response to the recent
jessie updates removal, I have managed to break the apt update/upgrade
process:
:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
systemd : Depends: udev (>= 208-8) but it is not installed
Recommends: libpam-systemd but it is not installed
E: Unmet dependencies. Try using -f.
After searching I've tried various suggested fixes such as
apt-get -f install
apt-get clean
apt-get autoclean
apt-get autoremove
apt-get dist-upgrade
dpkg --configure -a
and so on but all to no avail.
There is some info on my system below.
Thanks in advance,
Richard.
------------------------------
:~# uname -a
Linux rglynsvr 3.16.0-7-686-pae #1 SMP Debian 3.16.59-1 (2018-10-03) i686
GNU/Linux
-------------------------------
:~# systemd --version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
-SECCOMP -APPARMOR
-------------------------------
~# apt list --upgradable
Listing... Done
libsystemd0/jessie-backports 230-7~bpo8+2 i386 [upgradable from:
215-17+deb8u12]
libudev1/jessie-backports 230-7~bpo8+2 i386 [upgradable from:
215-17+deb8u12]
systemd/jessie-backports 230-7~bpo8+2 i386 [upgradable from: 215-17+deb8u12]
--------------------------------
My /etc/apt/sources.list
deb http://apt-cacher.lon.bitfolk.com/debian/ftp.uk.debian.org/debian/
jessie main contrib
deb-src http://apt-cacher.lon.bitfolk.com/debian/ftp.uk.debian.org/debian/
jessie main contrib
#deb http://apt-cacher.lon.bitfolk.com/debian/archive.debian.org/debian/
jessie-backports main contr$
#deb http://apt-cacher.lon.bitfolk.com/debian/security.debian.org/debian
jessie/updates main contrib
-------------------------------------
In sources.list.d/ there is
certbot.list
deb http://apt-cacher.lon.bitfolk.com/debian/archive.debian.org/debian/
jessie-backports main
Hi,
Today there were some periods of intermittent packet loss on both
IPv4 and IPv6 between 21:04Z and 21:23Z. For IPv6 it was more severe
(not all customers, but if you were affected it was 100% loss)
between 21:04Z and 21:13Z. Then there was a further period of
intermittent IPv4 packet loss between 21:19Z and 21:22Z.
This happened during some scheduled network reconfiguration on the
part of our colo provider. It was intended to be
non-service-impacting, but unfortunately multiple different problems
were encountered.
I took no part in what was going on (it was solely on their
equipment) but I made sure I was online so that if there were any
problems I could spot them and help diagnose them promptly. That
helped things get resolved faster.
The problems encountered were unanticipated and the colo provider
apologises for the disruption, but I should also apologise because I
admit I did not ask for a detailed plan of what exactly they were
doing as beyond looking out for problems I had no involvement.
Had I asked for a detailed plan, in hindsight I think I'd have
decided it was pretty complicated and would have announced an
"at-risk" window. The problems would still have happened, because as
I say they were unanticipated, but at least you'd have been able to
connect what you were seeing with the maintenance window.
If you care for the details of exactly what went wrong let me know
and I'll send them to you but they seem like a bit too much detail
for this email.
The initial work was completed at 21:22:48Z, and a second bit of
work was carried out without incident at around 22:00Z. No more work
is planned so no more problems are expected.
Apologies again for the disruption.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Now what would it take to get them to notice you and fix the problem and compensate you?
A lawsuit.
How does this differ from a robber who is trespassing on your property and looking to see whether any of your doors is ajar?
If one of your machines is located in the US, you have locus standi in that jurisdiction to pursue the trustees of Stanford.
Is that jurisdiction California?
Can bitfolk map the address range to which your machines respond to a US server farm located in Palo Alto or Menlo Park?
It need only be for a month or a week, although damages would follow length of exposure to the hazard.
--------------------------------------------
En date de : Mer 10.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: Mercredi 10 avril 2019, 1h50
It still
continues, but at a reduced rate. Still no response to my
email to the abuse mailbox. They have advertised a seminar
on cybersecurity which is going on round about now. That is
ironic.
On Wed, 10 Apr
2019 at 00:44, Keith Williams <keithwilliamsnp(a)gmail.com>
wrote:
I was
just going to say it had stopped, LOL, a 15 minute break,
then a burst, then a few minutes break. Seems to be slowing
down but another is giving port 80 a hammering. Because I
give these blackholes different names I can see the new
contender is one of the content spammers. Oh well it's
past midnight here so I will let them get on with their
games
On Tue, 9 Apr 2019
at 23:03, admins <admins(a)sheffieldhackspace.org.uk>
wrote:
Sounds sensible to me.
I also blanket ban anyone having a go at SSH simply
as whilst it
may start there, it never ends there.
Sounds like a retarded infestation to me. Most bots
are not that
clever in and of themselves, once you have had a
rummage through
their code. There have been some clever tricks put
into coding
them though.
kirbs
On
09/04/2019 15:50, Keith Williams
wrote:
Every packet that arrives from them is
sent to a
chain by the firewall which logs them and then drops
them. The
log records the port they were blocked on.
That's how I found
the 7777. I had no idea what it was. I picked them
up first
because they hit on 22. that got them put in the
set. Others in
the set made a couple of attempts then disappeared.
There is one
oyher persistent pest, a well known comment spammer
that keeps
coming back and having a go for a while then
disappearing, then
just the usual rubbish
On
Tue, 9 Apr 2019 at 22:27,
Dom Latter <bitfolk-users(a)latter.org>
wrote:
On 09/04/2019 10:59, Keith Williams wrote:
>
> On Tue, 9 Apr 2019 at 17:38, Dom Latter
<bitfolk-users(a)latter.org
> <mailto:bitfolk-users@latter.org>>
wrote:
>
> On 09/04/2019 04:44, Keith Williams
wrote:
> > for at least 24 hours now. They
go for ports
22.23.53, 80, 443
> and 7777.
> > That last one is particularly
nasty.
>
> They're (probably) looking for a
backdoor opened up
by Windows malware.
>
> Why would that concern you?
> It does concern me for a number of
reasons.
I was particularly referencing 7777 (hence the
quoted
context). You've
not got anything on that port, and even if you
did, it
wouldn't be
compatible.
I don't think I'd even notice an attempt
to connect to 7777.
Because a connection is not made...
_______________________________________________
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
_______________________________________________
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-----
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
