Re: [tor-talk] Yet another Tor failure - DanWin1210.me Hosting hacked
or use Qubes OS , its useful with some knowledge about it to make it great OS for hosting (i didnt test that for web hosting , but theoretically possible).And more secure than docker or plain debian or bsd ...etc. Mirimir: > On 11/15/2018 10:23 PM, Daniel Winzen wrote: >> Hello, >> >> yes my server got hacked. How - I do not know yet and I will need to do >> an extensive analysis. I did indeed not maintain backups, partly for the >> reason that users should have the right to be forgotten immediately when >> deleting their accounts. Around 1TB of data is gone. > > Hey, sorry about that :( And I do got your point about backups. > Although, in retrospect, a backup setup with relatively fast rotation, > and thorough deletion of old backups, would be prudent. > >> The scripts are open source and anyone who would like to build something >> similar is welcome to do so. However you should note there might be a >> risk of getting hacked too in case the vulnerability is hidden in those >> scripts. I will re-instantiate my hosting only after the vulnerability >> is found and fixed. https://github.com/DanWin/hosting/ > > As I said, shared hosting is a security nightmare. As I understand it, > you're depending on not much more than permissions to protect users from > each other. And in that situation, it's not _that_ hard for a skilled > hacker to get root, and do what they like. > > If I were going to attempt such an .onion hosting setup, I'd use a > couple levels of isolation between users. But first, I'd use LUKS with > dropbear for server FDE. It ain't perfect, but an attacker would need to > take some care while impounding the server. > > Basically, I'd setup several KVM domains, to help limit damage from a > compromise. Within each domain, I'd put each website in a Docker > container. Given a custom Docker-optimized kernel for the host, and XFS > storage, it's possible to set hard limits on CPU, RAM and storage for > each Docker container. > > Docker containers rely on kernel namespaces and cgroups. That's not as > secure as using full VMs, but _far_ lighter. And _far_ more secure than > chroot, which many shared-hosting setups still rely on. Alternatively, > one could use FreeBSD jails, and maybe that can also work with Docker. > > Anyway, if you're interested, I'd be happy to help. I'm just a hobbyist, > and totally self-taught. I mostly just use shell scripts. And I lack the > patience and organization to actually operate a shared-hosting site. > >> Any updates will be posted on my front page: https://danwin1210.me/ >> >> Regards, >> Daniel >> >> On 16/11/2018 06:13, Mirimir wrote: >>> On 11/15/2018 09:52 PM, tor...@secmail.pro wrote: DanWin1210.me hosting service was hacked. https://danwin1210.me/ All Tor Onions are dead. >>> >>> I guess that he didn't maintain backups :( >>> >>> Maybe some of those .onion owners did, though. >>> FH1: Unknown FH2: Took down by FBI FH3: Unknown Danwin1210: Ripped by Anonymous Now where is "Freedom Hosting IV"? >>> >>> Shared hosting is a security nightmare. Just sayin'. >>> And why so hate on Tor Onion service? >>> >>> This was just for lulz, no? >>> >> >> >> -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Yet another Tor failure - DanWin1210.me Hosting hacked
On 11/15/2018 10:23 PM, Daniel Winzen wrote: > Hello, > > yes my server got hacked. How - I do not know yet and I will need to do > an extensive analysis. I did indeed not maintain backups, partly for the > reason that users should have the right to be forgotten immediately when > deleting their accounts. Around 1TB of data is gone. Hey, sorry about that :( And I do got your point about backups. Although, in retrospect, a backup setup with relatively fast rotation, and thorough deletion of old backups, would be prudent. > The scripts are open source and anyone who would like to build something > similar is welcome to do so. However you should note there might be a > risk of getting hacked too in case the vulnerability is hidden in those > scripts. I will re-instantiate my hosting only after the vulnerability > is found and fixed. https://github.com/DanWin/hosting/ As I said, shared hosting is a security nightmare. As I understand it, you're depending on not much more than permissions to protect users from each other. And in that situation, it's not _that_ hard for a skilled hacker to get root, and do what they like. If I were going to attempt such an .onion hosting setup, I'd use a couple levels of isolation between users. But first, I'd use LUKS with dropbear for server FDE. It ain't perfect, but an attacker would need to take some care while impounding the server. Basically, I'd setup several KVM domains, to help limit damage from a compromise. Within each domain, I'd put each website in a Docker container. Given a custom Docker-optimized kernel for the host, and XFS storage, it's possible to set hard limits on CPU, RAM and storage for each Docker container. Docker containers rely on kernel namespaces and cgroups. That's not as secure as using full VMs, but _far_ lighter. And _far_ more secure than chroot, which many shared-hosting setups still rely on. Alternatively, one could use FreeBSD jails, and maybe that can also work with Docker. Anyway, if you're interested, I'd be happy to help. I'm just a hobbyist, and totally self-taught. I mostly just use shell scripts. And I lack the patience and organization to actually operate a shared-hosting site. > Any updates will be posted on my front page: https://danwin1210.me/ > > Regards, > Daniel > > On 16/11/2018 06:13, Mirimir wrote: >> On 11/15/2018 09:52 PM, tor...@secmail.pro wrote: >>> DanWin1210.me hosting service was hacked. >>> https://danwin1210.me/ >>> >>> All Tor Onions are dead. >> >> I guess that he didn't maintain backups :( >> >> Maybe some of those .onion owners did, though. >> >>> FH1: Unknown >>> FH2: Took down by FBI >>> FH3: Unknown >>> Danwin1210: Ripped by Anonymous >>> >>> Now where is "Freedom Hosting IV"? >> >> Shared hosting is a security nightmare. Just sayin'. >> >>> And why so hate on Tor Onion service? >> >> This was just for lulz, no? >> > > > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor 0.3.5.5-alpha is released
Hi, all! There's a new alpha Tor release! Because it's an alpha, you should only run it if you're ready to find more bugs than usual, and report them on trac.torproject.org. The source code is available from the downlaod page on www.torproject.org; if you build Tor from source, why not give it a try? And if you don't build Tor from source, packages should be ready over the coming days, with a Tor Browser alpha release likely by the end of next week. Here's what's new: Changes in version 0.3.5.5-alpha - 2018-11-16 Tor 0.3.5.5-alpha includes numerous bugfixes on earlier releases, including several that we hope to backport to older release series in the future. o Major bugfixes (OpenSSL, portability): - Fix our usage of named groups when running as a TLS 1.3 client in OpenSSL 1.1.1. Previously, we only initialized EC groups when running as a relay, which caused clients to fail to negotiate TLS 1.3 with relays. Fixes bug 28245; bugfix on 0.2.9.15 (when TLS 1.3 support was added). o Minor features (geoip): - Update geoip and geoip6 to the November 6 2018 Maxmind GeoLite2 Country database. Closes ticket 28395. o Minor bugfixes (compilation): - Initialize a variable unconditionally in aes_new_cipher(), since some compilers cannot tell that we always initialize it before use. Fixes bug 28413; bugfix on 0.2.9.3-alpha. o Minor bugfixes (connection, relay): - Avoid a logging a BUG() stacktrace when closing connection held open because the write side is rate limited but not the read side. Now, the connection read side is simply shut down until Tor is able to flush the connection and close it. Fixes bug 27750; bugfix on 0.3.4.1-alpha. o Minor bugfixes (continuous integration, Windows): - Manually configure the zstd compiler options, when building using mingw on Appveyor Windows CI. The MSYS2 mingw zstd package does not come with a pkg-config file. Fixes bug 28454; bugfix on 0.3.4.1-alpha. - Stop using an external OpenSSL install, and stop installing MSYS2 packages, when building using mingw on Appveyor Windows CI. Fixes bug 28399; bugfix on 0.3.4.1-alpha. o Minor bugfixes (documentation): - Make Doxygen work again after the code movement in the 0.3.5 source tree. Fixes bug 28435; bugfix on 0.3.5.1-alpha. o Minor bugfixes (Linux seccomp2 sandbox): - Permit the "shutdown()" system call, which is apparently used by OpenSSL under some circumstances. Fixes bug 28183; bugfix on 0.2.5.1-alpha. o Minor bugfixes (logging): - Stop talking about the Named flag in log messages. Clients have ignored the Named flag since 0.3.2. Fixes bug 28441; bugfix on 0.3.2.1-alpha. o Minor bugfixes (memory leaks): - Fix a harmless memory leak in libtorrunner.a. Fixes bug 28419; bugfix on 0.3.3.1-alpha. Patch from Martin Kepplinger. o Minor bugfixes (onion services): - On an intro point for a version 3 onion service, stop closing introduction circuits on an NACK. This lets the client decide whether to reuse the circuit or discard it. Previously, we closed intro circuits when sending NACKs. Fixes bug 27841; bugfix on 0.3.2.1-alpha. Patch by Neel Chaunan. - When replacing a descriptor in the client cache, make sure to close all client introduction circuits for the old descriptor, so we don't end up with unusable leftover circuits. Fixes bug 27471; bugfix on 0.3.2.1-alpha. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
