BitFolk Users

users@mailman.bitfolk.com

1117 discussions

by Andy Smith

Hello, If you run Exim and have local users you will want to make sure that it is upgraded as a matter of urgency as there is a trivial arbitrary command execution as root bug in most recent versions: https://seclists.org/oss-sec/2019/q2/152 Even if you are the only local user you should upgrade as it's possible, though more difficult, to exploit remotely. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

5 years, 6 months

Something to laugh at

by Keith Williams

The something today is me My SSH is set up to use a different port and login by key only no passwords. I then added to my firewall a rule that any attempt to connect on ports 22 or 23 would add the IP to a blacklist with a timeout of one day. Any further attempt by that IP to connect on any port would reset the timeout back to 24 hours. It's all logged and I have spent many happy hours running through the log seeing what other ports these miscreants attempt. All well and good until today. I have just returned after a year in the far east, and today still feeling jetlagged, I fired up my desktop computer, not used in just over a year and clicked on the SSH client icon to connect so that I could do my regular log checking but it would not connect, I did not look at the port, but remembered I had changed the keypair a few months ago. So transferred the key across from my laptop, still no joy. Ran windows diagnostics, no response from remote host, pings, nothing. Email, nothing, website nothing. Panic started to set in, could not even get in through XEN, though that should have worked. I used my laptop tethered still to my phone and was in straight away. Different IP. Yes I had locked myself out for 24 hours. In the meantime I had sent a panic email to support. Sorry Andy. It was a matter of minutes once the penny had dropped to get on the laptop and delete my home IP from the blacklist Such a silly elementary mistake So idiot of the day is... Keith

5 years, 6 months

Interesting (?) Linux RAID-10 performance caveat

by Andy Smith

Hello, A new BitFolk server that I will put into service soon has 1x SSD and 1x NVMe instead of 2x SSD. I tried this because the NVMe, despite being vastly more performant than the SATA SSD, is actually a fair bit cheaper. On the downside it only has a 3 year warranty (vs 5) and 26% of the write endurance (5466TBW vs 21024TBW)¹. So anyway, a pair of very imbalanced devices. I decided to take some time to play around with RAID configurations to see how Linux MD handled that. The results surprised me, and I still have many open questions. As a background, for a long time it's generally been advised that Linux RAID-10 gives the highest random IO performance. This is because it can stripe read IO across multiple devices, whereas with RAID-1, a single process will do IO to a single device. Linux's non-standard implementation of the RAID-10 algorithm can also generalise to any amount of devices: conventional RAID-10 requires an even number of devices with a minimum of 4, but Linux RAID-10 can work with 2 or even an odd number. More info about that: https://en.wikipedia.org/wiki/Non-standard_RAID_levels#Linux_MD_RAID_10 As a result I have rarely felt the need to use RAID-1 for 10+ years. But, I ran these benchmarks and what I found is that RAID-1 is THREE TIMES FASTER than RAID-10 on a random read workload with these imbalanced devices. Here is a full write up: http://strugglers.net/~andy/blog/2019/05/29/linux-raid-10-may-not-always-be… I can see and replicate the results, and I can tell that it's because RAID-1 is able to direct the vast majority of reads to the NVMe, but I don't know why that is or if it is by design. I also have some other open questions, for example one of my tests against HDD is clearly wrong as it achieves 256 IOPS, which is impossible for a 5,400RPM rotational drive. So if you have any comments, explanations, ideas how my testing methodology might be wrong, I would be interested in hearing. Cheers, Andy ¹ I do however monitor the write capacity of BitFolk's SSDs and they all show 100+ years of expected life, so I am not really bothered if that drops to 25 years. -- https://bitfolk.com/ -- No-nonsense VPS hosting

5 years, 6 months

apt-clone problem

by Ian Hobson

Hi All, I am trying to clone my bitfolk Ubuntu 18.04 VPS, using apt-clone. The issue is that the restore overrides /etc/apt/sources.list - so it fails, because it could not connect to apt-cacher.lon.bitfolk.com:80. Any ideas how to restore the packages? Regards Ian -- Ian Hobson Tel (+351) 910 418 473

5 years, 7 months

[OT] Newbie IPSec problem

by Chris Smith

Hi all, I’m trying to use a Docker/Alpine/Strongswan container on my VPS to connect to another site via IPSec (not my site, not my VPN choice). I’m a newbie to IPSec and would appreciate some help with what I think is probably a pretty basic issue. The IPSec config I have been given (below) is for a site-to-site connection. There is a machine on 10.99.102.92 at the remote site sending packets to 172.30.11.2 on my end and I need the container to be both the VPN endpoint and the destination machine (172.30.11.2). The IPSec connection is established just fine, but I can’t figure out how to properly associate the IP address with the tunnel. I thought this was a simple matter of configuring the IP address on the tunnel device (tunl0) but this fails in a pretty bizarre manner: if I configure the tunnel using ‘ip addr add 172.30.11.2/30 dev tunl0’ then I receive no packets at all. However, if I configure it for any other address in the range, I get the packets for 172.30.11.2. Can someone tell me how I’m supposed to do this? ipsec.conf: conn %default ikelifetime=60m keylife=60m rekeymargin=3m keyingtries=1 authby=secret dpdaction=restart dpddelay=30s dpdtimeout=120 conn net-net authby=psk lifetime=60m type=tunnel right=xx.xx.xx.xx rightsubnet=10.99.102.80/28 rightid=office rightfirewall=yes ike=aes256-sha1-modp1024! esp=aes256-sha1-modp1024! leftid=remote leftsubnet=172.30.11.0/30 auto=start Regards, Chris — Chris Smith <space.dandy(a)icloud.com>

5 years, 7 months

Security incident: Customer's Zimbra install compromised, VPS used for cryptocurrency mining

by Andy Smith

Hi, Today a customer informed us that their install of Zimbra fell victim to CVE-2019-9670, a remote code execution vulnerability disclosed in March of this year: https://blog.tint0.com/2019/03/a-saga-of-code-executions-on-zimbra.html https://lorenzo.mile.si/zimbra-cve-2019-9670-being-actively-exploited-how-t… Since some time in April the attacker had used their VPS as a cryptocurrency miner, using two cores of the BitFolk host's Xeon E5-1680v4 at 100% each. If you run Zimbra and haven't patched this vulnerability you should check that you haven't been compromised, as automated scanning and compromise has been taking place for over a month now. If you discover compromise you will probably need to reinstall. About this email: https://tools.bitfolk.com/wiki/Security_incident_postings Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

5 years, 7 months

I've broken my Debian Jessie package update / upgrade system

by Richard Glynos

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

5 years, 7 months

Intermittent packet loss today between 21:04Z and 21:23Z

by Andy Smith

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

5 years, 7 months

New server naming contest

by Andy Smith

Hi, A new name is needed, In a couple of days we will pick from the list of suggestions at: https://tools.bitfolk.com/wiki/BitFolk_server_naming#2019-04.2C_UK_VPS_host If you would like to add suggestions to the list please edit the wiki page. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

5 years, 8 months

Re: [bitfolk] I know I should not take it personally but ...

by Max B

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-----

5 years, 8 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users