BitFolk Users

users@mailman.bitfolk.com

1123 discussions

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, 10 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, 11 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, 11 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, 11 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, 11 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, 11 months

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

by Max B

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

5 years, 11 months

I know I should not take it personally but ...

by Keith Williams

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

5 years, 11 months

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

by Max B

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

5 years, 12 months

Testing backups are re-storable?

by Ian Hobson

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

6 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users