Hi,
Earlier in the week we were notified that a customer VPS was hosting
a web site pretending to belong to a major high street bank.
Upon investigation it seems that the TinyPortal mod for Simple
Machines Forum (SMF) was exploited in order to upload several HTML
documents into the /tp-images/File/ area.
Cheers,
Andy
About this email:
https://tools.bitfolk.com/wiki/Security_incident_postings
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
In late November a customer's VPS was detected performing a high
rate of outbound SSH connections (~135/sec) to a wide range of IP
addresses. Their network access was suspended and they were
contacted and asked to investigate.
Unfortunately the customer never responded, so their BitFolk account
was closed and we will never know how they were compromised.
Cheers,
Andy
About this email:
https://tools.bitfolk.com/wiki/Security_incident_postings
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Would be even better if I replied to the list...
---------- Forwarded message ----------
From: "Moggers87" <moggers87(a)googlemail.com>
Date: Dec 7, 2012 4:11 AM
Subject: Re: [bitfolk] Proposal: Security incidents postings
To: "Andy Smith" <andy(a)bitfolk.com>
I'd very much appreciate knowing what causes compromises in the real world.
Would be a good reminder to those of us who believe we have secure servers.
On Dec 7, 2012 2:19 AM, "Andy Smith" <andy(a)bitfolk.com> wrote:
> Hello,
>
> From time to time BitFolk customer VPSes occasionally become subject
> to various kinds of compromise. Frustratingly, the kinds of
> compromise encountered are generally the result of run of the mill,
> completely preventable and unremarkable root causes.
>
> I would like to find a way to raise awareness of these very simple
> security concerns amongst the customer base, in order to hopefully
> cut down on how often they happen.
>
> I was thinking that if customers saw how often these things happen
> to people very much like themselves then it might help remove some
> of the "yeah I've heard of that but it will never happen to me"
> mindset that we all regrettably can fall into.
>
> So I was contemplating posting an email thread to this ("users")
> list every time we become aware of a customer compromise, and I was
> wondering what you thought of that idea.
>
> It might look something like this:
>
> Today at around 04:30 we became aware of a customer VPS
> initiating an abnormal amount of outbound SSH connections (~200
> per second). The VPS's network access was suspended and customer
> contacted.
>
> It was later determined that a user account on the VPS had been
> accessed starting 3 days ago, via an SSH dictionary attack. The
> attacker installed another copy of the SSH dictionary attack
> software and set it going. We do not believe that root access
> was obtained.
>
> The amount of detail would vary because we may only become aware of
> a compromise when the customer's VPS itself starts perpetrating
> abusive activity, and then we rely on the customer to investigate
> why that is.
>
> If the customer is unable/unwilling to do this then we may never
> know why their VPS began misbehaving. We don't examine customer data
> unless given permission to do so, and even then this is often too
> time-consuming to undertake on an unpaid basis. I would consider the
> above an example of the maximum amount of detail we would go into.
>
> No identifying information regarding the affected customer would be
> shared. We already share non-identifying information similar to the
> above to peers within the industry to aid deterrence and detection
> of future abuses.
>
> Would this sort of posting be welcomed or would it be unwelcome
> noise? If the consensus is that it would be unwelcome noise then I
> may create a new list specifically for it, but I would rather not do
> so as then that is just another list that we have to raise awareness
> of.
>
> Please also note that those with an extremely low tolerance for
> email noise may wish to quit this list and instead join the
> "announce" list, as it contains only announcements from BitFolk with
> no customer discussion whatsoever:
>
> https://lists.bitfolk.com/mailman/listinfo/announce
> http://lists.bitfolk.com/lurker/list/announce.html
>
> (just 19 threads this year)
>
> Thoughts?
>
> Cheers,
> Andy
>
> --
> http://bitfolk.com/ -- No-nonsense VPS hosting
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREDAAYFAlDBUj4ACgkQIJm2TL8VSQsqvACgwIgInU6KIOtadzOhGfxJbzq2
> IMwAoKpBPCQW2HYD1Dgs6RPF38QNycai
> =xqsl
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> users mailing list
> users(a)lists.bitfolk.com
> https://lists.bitfolk.com/mailman/listinfo/users
>
>
Is anyone aware of any routing issues from Oz to Bitfolk? I'm doing some
remote support on a machine down there and can't ping any bitfolk ips?
-Matt Daubney
On 2012-12-03 12:07, David Paul wrote:
> I don't think I did, think it's as it was when I got the VPS
>
> search the-new-jedi-order.co.uk [1].
> nameserver 85.119.80.232
> nameserver 85.119.80.233
OK, so that looks similar to mine. I have done some dig tests:
---start---
~# dig @127.0.0.1 pear.php.net
; <<>> DiG 9.7.3 <<>> @127.0.0.1 pear.php.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57104
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 6
;; QUESTION SECTION:
;pear.php.net. IN A
;; ANSWER SECTION:
pear.php.net. 300 IN CNAME euk1.php.net.
euk1.php.net. 300 IN A 5.77.39.20
;; AUTHORITY SECTION:
php.net. 169942 IN NS dns3.easydns.org.
php.net. 169942 IN NS dns4.easydns.info.
php.net. 169942 IN NS dns2.easydns.net.
php.net. 169942 IN NS dns1.easydns.com.
;; ADDITIONAL SECTION:
dns1.easydns.com. 300 IN A 64.68.192.210
dns1.easydns.com. 300 IN AAAA 2001:1838:f001::10
dns3.easydns.org. 600 IN A 64.68.195.10
dns3.easydns.org. 60 IN AAAA 2620:49:a::10
dns4.easydns.info. 40342 IN A 194.0.2.19
dns4.easydns.info. 40342 IN AAAA 2001:678:5::13
;; Query time: 350 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 3 12:20:36 2012
;; MSG SIZE rcvd: 315
~# dig @185.119.80.232 pear.php.net
; <<>> DiG 9.7.3 <<>> @185.119.80.232 pear.php.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
~# dig @185.119.80.233 pear.php.net
; <<>> DiG 9.7.3 <<>> @185.119.80.233 pear.php.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
~# dig @8.8.8.8 pear.php.net
; <<>> DiG 9.7.3 <<>> @8.8.8.8 pear.php.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59519
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;pear.php.net. IN A
;; ANSWER SECTION:
pear.php.net. 265 IN CNAME euk1.php.net.
euk1.php.net. 265 IN A 5.77.39.20
;; Query time: 11 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Dec 3 12:21:43 2012
;; MSG SIZE rcvd: 65
---end---
Interesting stuff. It seems that the two Bitfolk-supplied IP addresses
are down at the moment for whatever reason (probably worth asking Andy
what is going on via an email to support(a)bitfolk.com). For now I suggest
that you add the following line above the two other nameserver entries
in your file:
nameserver 8.8.8.8
That is a public resolver by Google, which seems to do a good enough
job at resolving odds and ends. Still, consider it a stop-gap for now
until you have sorted out what you need to know in order to install your
own local resolver (both bind and dnsmasq are excellent packages for
situations like this).
Regards,
Jan Henkins
Hi,
The following applies to a Xen installation on my own hardware, not Bitfolk VMs.
I have therefore marked it O/T. I hope nobody minds. I've tried the Xen-Users
list and not had any luck.
The install is an Ubuntu 12.04-x64 host with two Ubuntu 12.04-x64 guests and one
Windows server 2008 R2 guest with the signed PV drivers. I'm using the XL
toolkit.
I'm suffering an issue where the machine gets stuck at the "Will now reboot"
line when the host is rebooted while the guests are still running. If I shut all
the guests down using "xl shutdown" the guests do terminate properly (after
about 30 seconds). If I then do a reboot on the host, it completes cleanly.
If I don't shutdown the guests, I have observed some possibly strange behaviour
during the host shutdown before it hangs. In the shutdown progress I see:
> Stopping xenconsoled
> WARNING not stopping xenstored as it cannot be restarted
> Shutting down Xen domains: Linuxguest1 (shut) Linuxguest1 (shut) Linuxguest2
> (shut) Linuxguest2 (shut) Windowsguest (shut) SHUTDOWN_ALL * [done]
The things I think are strange are that the two Linux guests are listed twice in
the shutdown line despite each only being running once and that it blows
straight through the line saying "[done]" without waiting for the guests to
terminate. It then appears to unmount the discs before all the guests have
wrapped up so they never do terminate. If I leave it, I get repeated kernel
warnings that the reboot process has been delayed for more than 120 seconds. I
waited over 300 seconds (the time specified in XENDOMAINS_STOP_MAXWAIT) but it
doesn't time out and recover.
My xendomains file contains:
XENDOMAINS_SYSRQ=""
XENDOMAINS_USLEEP=100000
XENDOMAINS_CREATE_USLEEP=5000000
XENDOMAINS_MIGRATE=""
XENDOMAINS_SAVE=
XENDOMAINS_SHUTDOWN="--halt --wait"
XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
XENDOMAINS_RESTORE=false
XENDOMAINS_AUTO=/etc/xen/auto
XENDOMAINS_AUTO_ONLY=false
XENDOMAINS_STOP_MAXWAIT=300
I disabled the save and restore options because I am using PCI passthrough and
trying to restore a saved VM caused the machine to crash at boot.
I'm wondering if these problems are something to do with me using xl as most of
the examples and references to the settings mention xm.
Do you have any suggestions why this hanging or why the "--wait" in xendomains
doesn't seem to be having any effect please?
Thanks,
Paul.
Hi,
Effective immediately the base transfer quota has been upgraded from
200GB to 300GB per month.
So,
- If you just use the included data transfer quota:
Congrats, it's now 300GB instead. You don't need to do anything.
- If you pay for any additional data transfer up to 300GB/mo:
Congrats, you won't have to pay any extra for that now, it's 300GB
for everyone.
The additional units of data transfer have been removed from your
configuration so you won't be charged for them in future.
Also if you pay quarterly or yearly, a pro rata amount of service
credit has been added to your account so there's no hard feelings
about you having paid up front for the extra units of data
transfer.
- If you pay for additional data transfer past 300GB/mo:
Congrats, 100GB of that now comes for free. 10 units of additional
data transfer have been removed from your configuration.
If you pay quarterly or yearly, you've received pro rata service
credits to your account for those 10 units.
If you're in either of the last two categories then this means that
your future bills will be smaller, so if you pay by standing order
you should take care to adjust it otherwise you'll be overpaying us.
You can check out your new costs at:
https://panel.bitfolk.com/account/config/
If you pay by PayPal subscription then we already altered it down
for you and PayPal will have confirmed that in email. If you pay by
Direct Debit pre-authorisation then we'll always only take the
correct amount anyway.
Happy holidays!
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
