One that caught one server in the past month was webmin's, where one
version was hacked with a backdoor would by default let an attacker
run code as root, and later versions could also do so, depending on
how they'd been set up.
http://www.webmin.com/exploit.html
It didn't help that it's easy to let webmin update itself rather than
using the usual Debian apt / apt-get utilities and, if you don't use
it very often, it's easy to miss an update release.
What it did was install something listening to port 59000. As that
port (and almost all others) has always been blocked by the firewall,
it doesn't seem to have done anything bad, but it's rebuild on a fresh
VPS and destroy it time.
Ian, knowing that Andy has always disliked webmin...
Hi,
Last week we received abuse reports of SSH dictionary attacks coming
from a customer IP. At the time of investigation no attacks were
taking place but looking at historical bandwidth use it did seem
that something anomalous had happened in a few short bursts.
It was also obvious that the VPS had started using 100% of both of
its CPU cores around the same time as the first traffic spike:
https://imagebin.ca/v/4sqgOQKzxB4r
The customer was then informed of the probable compromise.
While we were watching the outbound SSH connections a dictionary
attack started up again, so we had no option but to disable the
customer's network access.
The customer later confirmed presence of this malware:
https://kindredsec.com/2019/05/31/dota-campaign-analyzing-a-coin-mining-and…
They had got in through an SSH dictionary attack against the
customer and then installed this to continue attacks and mine
cryptocurrency.
Unfortunately since the compromised account had full sudo access,
the customer had no choice but to completely reinstall.
We always recommend that password auth be disabled for SSH.
Do note that you can also upload SSH public keys and disable
password auth for your Xen Shell access, and/or require two factor
auth. This is set via the Panel:
https://panel.bitfolk.com/account/security/
About this email:
https://tools.bitfolk.com/wiki/Security_incident_postings
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
I was too busy to upgrade one of my VPS to Buster the other week. Also the
email from Andy reminded me that I have not converted that one to 64 bit.
So I decided to kill 2 birds with one stone.
First, into Xen shell and type in arch x86_64
That went nice and easy and Xen now tells me that I am operating in 64 bit
mode and that the bootloader can only boot x86_64 guests
Great. Prepare for upgrade to Buster, the press the go button. Chugging
through the upgrade process I see that it is all 32 bit packages being
installed. I thought Xen by some internal magic changed what I could
download. Well Kernel wise really
When all finished and a reboot done (a totally problem free upgrade by the
way) I ran lscpu
~# lscpu
Architecture: i686
CPU op-mode(s): 32-bit
Byte Order: Little Endian
OK I should have done some step earlier on in the process which I didn't -
maybe install a 64 bit kernel and rebooted, or something.
Showing my ignorance here I know, but I seem to remember when doing it on
my other VPS it was as simple as do the arch command on xen then just
update/upgrade
What have I missed, please?
Hi all, sorry it's me with a problem. Last night I did a complete reinstall
of the OS. I am running Stretch 64 bit.
I had some troubles with Bind not updating slaves, It said it was not
authoritative. Googled for remedies, tried them all out (will list what I
did in a minute.
No luck so purged and reinstalled Bind, then manually entered a single
zone, restarted Bind. The logs showed this:-
zone keiths-place.co.uk/IN: sending notifies (serial 2019072335)
zone 31.172.in-addr.arpa/IN: sending notifies (serial 1)
zone 127.in-addr.arpa/IN: sending notifies (serial 2)
zone 27.172.in-addr.arpa/IN: sending notifies (serial 1)
zone 255.in-addr.arpa/IN: sending notifies (serial 1)
zone 0.in-addr.arpa/IN: sending notifies (serial 1)
client 85.119.84.35#35865 (keiths-place.co.uk): bad zone transfer request:
'keiths-place.co.uk/IN': non-authoritative zone (NOTAUTH)
client 85.119.80.222#59271 (keiths-place.co.uk): bad zone transfer
request: 'keiths-place.co.uk/IN': non-authoritative zone (NOTAUTH)
client 85.119.80.198#10938 (keiths-place.co.uk): query '
keiths-place.co.uk/SOA/IN' denied
client 85.119.80.198#49851 (keiths-place.co.uk): bad zone transfer
request: 'keiths-place.co.uk/IN': non-authoritative zone (NOTAUTH)
So you will need to see the conf files
/etc/bind/named.conf.local
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
zone "keiths-place.co.uk" {
type master;
file "/var/lib/bind/keiths-place.co.uk.hosts";
allow-query {
85.119.84.35;
85.119.80.222;
2001:ba8:1f1:f085::53;
2600:3c01:e000:259::53;
45.33.107.124;
172.104.29.216;
2600:3c03::31:2153;
2001:ba8:1f1:f309::2;
127.0.0.1;
};
check-names warn;
notify yes;
};
in frustration I added all the possible slaves and localhost to allow-query
Named.conf
acl slaves {
85.119.84.35; 2001:ba8:1f1:f309::2;
};
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in
/etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
and finally named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
8.8.8.8;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See
https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain yes; # conform to RFC1035
listen-on-v6 { any; };
check-names master warn;
check-names slave warn;
allow-query {
85.119.84.35; 2001:ba8:1f1:f309::2;
};
also-notify {
85.119.84.35; 2001:ba8:1f1:f309::2;
};
notify yes;
forward first;
};
And just for good measure the zone file
$ttl 38400
keiths-place.co.uk. IN SOA ns3.keiths-place.co.uk.
keithwilliamsnp.gmail.com. (
2019072335
10800
3600
604800
38400 )
keiths-place.co.uk. IN A 85.119.82.237
www.keiths-place.co.uk. IN A 85.119.82.237
ns3.keiths-place.co.uk. IN A 85.119.82.237
mail.keiths-place.co.uk. IN A 85.119.84.35
ns1.keiths-place.co.uk. IN A 85.119.84.35
ns2.keiths-place.co.uk. IN A 85.119.82.237
webmail.keiths-place.co.uk. IN A 85.119.82.237
keiths-place.co.uk. IN MX 10 keynesmail.com.
keiths-place.co.uk. IN TXT "v=spf1 mx redirect=keynesmail.com"
keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f29d::2
mail.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
ns1.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
ns2.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
webmail.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
ns3.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f29d::2
www.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f29d::2
keiths-place.co.uk. IN NS a.authns.bitfolk.com.
keiths-place.co.uk. IN NS b.authns.bitfolk.com.
keiths-place.co.uk. IN NS c.authns.bitfolk.com.
keiths-place.co.uk. IN NS ns3.keiths-place.co.uk.
Following "solutions" on Google, I checked all permissions, checked
apparmor (no file for bind there) added all possible slaves to allow-query,
checked firewalls. And read all I could find on Bind. Though I have been
running the 2 bind servers for years and they always just seemed to work.
Sorry, should have said, running Bind 9.11
Keith
Hi All,
I have just done a "sudo apt-get update" and "sudo apt-get upgrade" and
got the following messages on the screen.
update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
update-initramfs: Generating /boot/initrd.img-4.15.0-52-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_hecyM2/lib/modules/4.15.0-5
2-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_hecyM2/lib/modules/4.15.0-5
2-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.15.0-50-generic
update-initramfs: Generating /boot/initrd.img-4.15.0-48-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_1XbniU/lib/modules/4.15.0-4
8-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_1XbniU/lib/modules/4.15.0-4
8-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.15.0-47-generic
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_acPqsQ/lib/modules/4.15.0-4
6-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_acPqsQ/lib/modules/4.15.0-4
6-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_bPQxlw/lib/modules/4.15.0-4
5-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_bPQxlw/lib/modules/4.15.0-4
5-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.4.0-116-generic
WARNING: missing /lib/modules/4.4.0-116-generic
Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/4.4.0-116-generic:
No such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_B46ktb/lib/modules/4.4.0-11
6-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_B46ktb/lib/modules/4.4.0-11
6-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.4.0-112-generic
WARNING: missing /lib/modules/4.4.0-112-generic
Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/4.4.0-112-generic:
No such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_gDoz9s/lib/modules/4.4.0-11
2-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_gDoz9s/lib/modules/4.4.0-11
2-generic/modules.builtin: No such file or directory
Setting up apache2 (2.4.29-1ubuntu4.8) ...
Processing triggers for initramfs-tools (0.130ubuntu3.8) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
ian@hobsoni:~$
I am using the standard Ubunutu 18.04 LTS kernel and software.
What do these warnings and errors mean? Can I safely ignore them? And if
not, how can I fix?
Regards
Ian
--
Ian Hobson
Tel (+351) 910 418 473
[Redirected back to the list with permission.]
Hi David,
I should stress again that crossgrading between 32- and 64-bit is
not officially support by Debian/Ubuntu nor BitFolk. It does however
work, multiarch is supported by these distros, I've done it a bunch
of times and so have other customers.
The worst thing that happened to me was that one time I accidentally
let it remove /bin/rm, and I had to scp in a /bin/rm from another
host before dpkg would work again (it requires a working rm
command!). Removing coreutils is not a good plan, for future
reference. :-)
The basic procedure is described here:
https://wiki.debian.org/CrossGrading
The only BitFolk-specific issue is the architecture of the
bootloader that we use to boot your VM. You have to tell us whether
it should be 32-bit or 64-bit. You do that by using the "arch"
command in the Xen Shell.
Going by that page, you would use the Xen Shell "arch" command
after you install the 64-bit (amd64) kernel but before you reboot.
This is step 2 ("Install a kernel that supports both architectures
in userland") in that article.
Assuming your VM then boots 64-bit into the amd64 kernel, you could
stop there. You would be running a 64-bit operating system and
kernel but all your apps would still be 32-bit and anything new you
install would be 32-bit as well.
I think it's unlikely that anything too weird would happen if you
carried on like this.
You could take it a step further, which is step 4 ("Crossgrade
`dpkg` `tar` and `apt`"). That involves downloading the .deb files
for the 64-bit versions of those packages and installing them
forcibly with dpkg. After you've done that your default architecture
would be amd64 so everything new you install would be amd64, while
all your existing stuff that is i386 still works.
Leaving things in this state I've seen some confusion happen at
later package upgrades. Things being upgraded or installed in future
sometimes need to pull in amd64 versions of things already
installed, and apt wants to ask you if you are really sure about
that. So expect some ongoing work.
If you are brave you could go the whole way of listing everything
installed and replacing it with its amd64 counterpart. This is the
really tricky thing to do, as apt won't like you trying to remove
essential things (even though you are only doing it to immediately
replace them) and it will come up with some very odd suggestions
that also involve removing most of your system.
Most times I have tried this involved repeatedly issuing commands
like:
# apt remove blah:i386 blah:amd64+ coreutils:amd64+
and seeing what it suggests, before letting it or hitting 'n' and
trying again.
Note the '+' on the end of some of the package names. This is apt
syntax for "Please remove package blah but also install amd64
architecture of package blah and also keep coreutils installed too".
You do this when apt wants to remove something that you really don't
want it to remove, to tell it to try again with a different plan.
If this sounded scary, or you aren't familiar with doing this sort
of thing, you probably should not try this. Just reinstall. Or keep
going with a 64-bit kernel and 32-bit userland.
The other thing I would say is, make sure you are familiar with how
to use the Xen Shell to start, stop, destroy (power yank) your VPS
and access its console. It is totally mad^W^Wextremely unwise to
consider trying to change the architecture of your running VPS
without having offline access to its console, yet I have had to
rescue a few people who gave it a go and then were flummoxed when
their only problem was that grub was waiting for them to choose
which kernel to boot.
Of course, if you don't fancy doing any of that, the offer of a free
VPS for 2 weeks to migrate into is always there.
https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Those running 32-bit VMs who haven't thought about
upgrading/reinstalling them to 64-bit yet, please have a read of:
“There are no current plans to remove support for 32bit PV
guests from Xen, but it is very much in the category of "you
shouldn't be using this mode any more".”
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00827.html
When Juergen asked for feedback on removing 32-bit guest support a
year or two ago I told him that (at the time) more than 60% of
BitFolk's user base was 32-bit and they'd need time to transition.
Now that there is a stable grub release which supports PVH¹ booting
Juergen is pushing this again and it will eventually go through to
the Linux kernel.
When Xen does remove 32-bit PV mode we can still continue to support
32-bit guests in PVH mode or HVM mode, so I will still make sure it
works without customers having to do anything. But you should be
clear that just because it will work doesn't mean it is a good idea!
I have a round of updates to do and then I will start moving
customers over to PVH mode where possible (requires 4.11+ kernel in
guest).
Cheers,
Andy
¹ PVH mode guests run all the normal code paths of a kernel not
under virtualisation except for their IO drivers like networking
and block devices which are still paravirtualised for performance
reasons. This results in a kernel that has a smaller attack
surface as there is much less xen-specific code being used, it's
faster and simpler. It also still doesn't require use of qemu on
BitFolk's side. See:
https://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum
for more information.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
I wrote a thing about the different options for handling boot-time
entropy on distributions that may be affected such as Debian 10
(buster).
TL;DR: By default the CPU's RDRAND instruction is used so you won't
notice anything and don't need to care unless you believe that Intel
is a pawn of the US government, in which case maybe you want to
disable it.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello Folks,
I hope this question is OK to ask here. Before doing some research and digging elsewhere, I thought I might tap thoughts here.
I currently work for a small software company based in Poplar, London (Poplar Business Park) but will be leaving in a month for new pastures. We only have a few software engineers and support people now - about 5. With me leaving, there is no Linux experience left in the company and there are a few servers and services that may need watcing and support. So, considering options, I am thinking of seeing if an external third-party could do the occasional Linux server support, on call, email support, visit if required etc. I don't think the workload will require any full-time position.
Does anyone here have any recommendations on a Linux Support service - company or person? If so, feel free to contact me off-list if preferred.
This is a small office, with small requirements and no rocket science is used..
Servers : ~3 Debian 9 VM's and 1 Debian 9 file server (HP micro,RAID5).
Services : main server is Apache/Mysql/Mercurial repo/ Samba SMB. Others for intranet DNS (dnsmasq), Samba workgroup.
I can share more details later obviously. Most of the stuff just needs to stay available as-is, so we need to cope with a VM or host crash, RAID failure etc.
Any recommendations would be gratefully received.
Cheers,
--
Alastair Sherringham
http://www.sherringham.net
Hi,
Debian 10.0 (buster) was released on Sunday. You can now use the
self-installer to install it. From the Xen Shell type:
xen shell> install debian_buster
If this is not your first install you may wish to check that your
architecture is set to x86_64 (64-bit). If it's 32-bit then you can
change it with:
xen shell> arch x86_64
I recommend that you do switch to 64-bit if you haven't already.
The new Debian testing (bullseye) is also present but is still a
work in progress. We'd still be interested in hearing about any
problems with it.
More info:
https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installerhttps://tools.bitfolk.com/wiki/Xen_Shell
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce