(untitled)

Does anyone here uses any kind of bulletproof/offshore hosting? I'm looking for some host that don't have a lot of rules, and that allows to run scripts, botnets, etc. I'm not only concerned about the availability and privacy. I'm kind confused about this offshore laws, they really do what they promise? I've also read that bulgarian laws are vague, and hosting there should be a good idea, is it? I'm going to post here some options I found and seens to be good. Please tell me whats you guys think about those companies, if they are good or not, and if you have a better one please fell free to share. >someone in blackhat forum told that he used to run a botnet on it, but their terms say the oposite https://legionhoster.com/terms-of-service/ >heard a lot about this bulgarian company, but their terms don't seen to be nice either https://www.webuzo.net/terms-of-service/ >they don't even have a page of terms, and this one seems to be the better one, their terms are in the pic, but they are located in UK what I don't believe it's safer as Bulgaria, Russia, or offshore hosting https://lolekhosted.net/index.php

>bulletproof/offshore hosting no such thing exists today, it's not 2005 anymore >allows to run scripts, botnets any computer+tor fronting >bulgarian laws are vague They comply to EU and Interpol >payment with bitcoin as something good >phone screenshot Are you aware of what you are doing, young man?

>>2995 Thank you, Lain. I was just too tired to edit this image. I thought using tor, but I want something more stable, since tor connections are slow.

>>2999 Listen, anyone who tells you soykaf on forums is probably a retard. Especially if it's a forum with a reputation-based system or whatever. 99% of the time they're full of wannabe asswipes living a make-believe hacker dream, and the remaining 1% are guys who were so monumentally stupid they got caught by the federales and are now monitoring hacker forums so they don't spend the next five years unable to see sunlight. Bulletproof hosting doesn't exist. Not for you. By the same token, whatever crime you're planning on doing, you probably shouldn't do it. If you're not smart enough to a) build up the infrastructure for it without googling and asking people on forums and b) understand why Tor's speed problems are a very minor negative compared to the immense positive provided, it's a very good sign that you're not capable of living out your hacker dream. No doubt you'll come back with a whole bunch of defensive responses, like "WELL NORMALLY I KNOW EVERYTHING ABOUT HACKING BUT JUST THIS ONE TIME I WANTED TO ASK SOME BASIC QUESTIONS ON THE INTERNET FOR THE SHEER VISCERAL THRILL OF IT" or "I'LL NEVER BE ARRESTED BECAUSE I'M IN AFGHANISTAN/RUSSIA/I'M A 12 YEAR OLD BOY/I'LL FOLD LIKE PANDE AT STANFORD", but believe me. While this might seem harsh, it's really for your own good.

>>3010 >By the same token, whatever crime you're planning on doing, you probably shouldn't do it. If you're not smart enough to ... understand why Tor's speed problems are a very minor negative compared to the immense positive provided, it's a very good sign that you're not capable of living out your hacker dream. I agree with this point specifically. Disregarding Tor because it's slow is like disregarding a bullet proof vest because it is pink. I'm not saying that Tor is bullet proof and you should use it. I'm just saying that if you are not even getting the fundamental logic right.

>>2994 Cheezus... Please stop the meme about Russian hosting being "safer" or "privater". Russia is one of the frontrunners in internet censorship, and I can assure you there isn't one datacenter there that isn't compromised in one way or another. Just... don't. Hosting there is almost as smart as hosting in China.

>>3013 Why wouldn't it be safer to be based out of Russia if Russia doesn't answer to the country you live in?

>>3013 I think the kernel of truth at the heart of the Russian hosting meme is that traditionally the Russian government turned a blind eye hackers who were careful not to target Russian citizens. Times are changing though.

>>3014 I think >>3016 gets it. It is a well-known strat to base in countries that won't collaborate with yours, but it's not as simple as that. First of all, you never know what sort of cooperation and with whom do they have. Secondly, chances are that whatever you host on such a server that would be disruptive for other governments, will be perceived as such by the Russians as well. I just wouldn't risk it.

OP here. >>3010 In fact I won't, comrade. I really agree with you, I'm not in any illegal activity, I'm just interested in how it could play out. But my major concern is that the tor2web tld is not always working. Is there any better way to deal with it? >>3013 I also though on this, but how I live in a third world country perhaps no one would give a fuarrrk as >>3014 >>3016 and >>3017 said, but how about offshore hosting? Is the same soykaf?

>>3027 >But my major concern is that the tor2web tld is not always working. Is there any better way to deal with it? Maybe install a friggin Tor browser them?

>>3028 Yes, for sure that's something that I can work on. But supposing that I use tor, I wouldn't host a hidden service in my own place for obvious reasons, what forces me again to use some vps/dedicated server, is it right? If so, what would be the safest way to host a hidden service?

>>3029 The point of a Tor location hidden service is that the location of the service is hidden. So you are less likely to have problems with the hosting provider in the first place so you don't necessarily need "bulletproof" anymore.

>>3030 I thought that the hosting companies wouldn't allow such thing. Can't they find out that I'm running a hidden service over theirs server? Perhaps analyzing the traffic, idk.

>>3031 some won't, some will. you'd still definitely want to pick a hosting provider that takes a more hands-off approach when it comes to monitoring your usage, but that's a lot easier than finding a hosting provider that won't cave when the FBI shows up at their door. as >>3030 said, your job would be to ensure that doesn't happen by preventing LE from finding out which door they need to kick down in the first place. that's where tor comes in.

you can make your server connect to tor through bridges and download packages from repos over https, then provider won't see any suspicious activity connected to tor unless they explicitly look at your vps instance directly. and yes, use a proxy or vpn after tor to not look as a suspicious customer to your provider too

Are Sealand still running a data haven?

>>3031 The Tor Project lists hosting services that are okay with Tor exit node usage. I'm not sure if such a list exists for Hidden Services, but I'm sure that if a company doesn't care to have an exit node running, they won't care about a hidden service. It may be better to find a hosting service that isn't listed, since the feds will obviously check hosts that explicitly allow Tor for hidden services first. >>2994 I just want to re-iterate what other lains have being saying: bulletproof hosting is not real. If you see someone offering "bulletproof hosting" all they're really offering is an out-dated server for more money than it's worth. Not only that, but people who run "bulletproof hosting" have a habit of rooting your box and digging around in it. Think about it: they know the people who are signing up with them are doing illegal soykaf, they clearly have no problem doing illegal soykaf, so why wouldn't they spy on you and steal whatever valuable info you have? If you're worried about being caught because you used a normal host, you should not be doing whatever it is you're planning on doing. It should not be difficult to purchase a normal host without them getting any information that could lead back to you. >>3029 Read this: https://pastebin.com/GrV3uYh5 It's Doxbin's writeup regarding not going to prison after having the Doxbin hidden service taken down. To my knowledge, he's the only person whose hidden service was taken down during Operation Onymous and didn't go to prison. It's high-level, so if you don't understand what needs to be done from it, you're not ready to do whatever it is you're planning on doing.

>>3032 >>3033 That was very helpful, thanks. >hosting in a country that don't have any kind of deal with mine country, like russia or wherever(or anyone will be the same soykaf?) >always use tor, and bridges >use https (can I get a ssl certificate for a hidden service? Sorry for this dummy question.) >it's not on this thread, but I know that some hosting companies share the same ip address between theirs VM, this would give some extra work to the authorities, of course, this is only valid if they don't keep any log, what I doubt. So can we summarize this thread in those points? >>3034 As far as I searched they don't.

>>3051 >>use https (can I get a ssl certificate for a hidden service? Sorry for this dummy question.) That's absolutely not necessary and is, in fact, detrimental. Hidden Services already usa RSA to encrypt communication from client to server in a similar fashion, so you already have all the benefits SSL gives you. It's detrimental because with SSL, you have to register your SSL certificate with a certificate authority (CA). So, whenever someone connects to your hidden service, they'll have to contact at least one CA to verify your hidden service is using the right certificate. The CAs will then be able to track when people are visiting your hidden service, and, in some cases (such as when using tor2web), even track who is visiting your service. Additionally, registering the certificate with a CA is more work for you and is just another attack vector for someone to figure out who you are. In layman's terms: DO NOT USE SSL ON HIDDEN SERVICES. IT IS USELESS AND WILL COMPROMISE BOTH YOUR VISITORS' ANONYMITY AND YOURS. >it's not on this thread, but I know that some hosting companies share the same ip address between theirs VM, this would give some extra work to the authorities, of course, this is only valid if they don't keep any log, what I doubt. If you're doing something that will attract attention from law enforcement, you should assume that every service you interact with keeps as much logs as they possibly can. If your opsec won't keep you safe under this assumption, then your opsec is soykaf and you're going to prison.

>>3035 For sure, you are definitely right. Thank you so much, Lain. This paste was just what I was looking for.

>>3053 Yes, I was wondering about that, even when they say that don't keep log, they shall keep something.

>>3053 >So, whenever someone connects to your hidden service, they'll have to contact at least one CA to verify your hidden service is using the right certificate >t. has no idea how certificates work pro tip: not like this When client connects through ssl/tls, it gets a certificate response from a website, signed by CA, it then verifies the signature with CA certificates in local storage DO use TLS or other RSA-based protocol on your hidden services if it's self-signed for extra security. DO NOT use CA-signed TLS if you want to keep your hidden server location anonymous. >>3055 They probably don't log every VM, especially if it runs your own baked OS with fde keys on another remote server, but they surely log all entrances and exits on the network, and sometimes those logs can tell much more that your VPS storage.

>>3056 >When client connects through ssl/tls, it gets a certificate response from a website, signed by CA, it then verifies the signature with CA certificates in local storage This is correct. Hidden services are already encrypted. The only reason to use SSL would be to use a CA as proof of your identity (like facebook's hidden service). Otherwise there is no advantage to using any kind of SSL on a hidden service. >They probably don't log every VM, especially if it runs your own baked OS with fde keys on another remote server, Full Disk Encryption only protects data at rest so is completely useless on a device that is running 24/7 like a VPS.

>>3057 >there is no advantage to using any kind of SSL on a hidden service. But there are advantages of using other tunnel encryption methods inside tor circuit, just in case if tor's encryption is broken, the information is will not leak until second layer is cracked. If we assume the time between law enforcement entities finding out the hidden service real IP address and obtaining physical server hardware is not momentary, we can shut down the vps immediately after bad signs, hoping that keys will be erased from ram soon enough thus preventing further forensic examination of internal file systems. I repeat, the keys are not stored locally in any form, they are loaded in ram from remote (hidden) server during boot process.

>>3059 >But there are advantages of using other tunnel encryption methods inside tor circuit, just in case if tor's encryption is broken, the information is will not leak until second layer is cracked. I'm not convinced but that's your threat model I guess. >If we assume the time between law enforcement entities finding out the hidden service real IP address and obtaining physical server hardware is not momentary You are using someone else's hardware so it is already compromised from day 1. Anyone with access can 1) sniff the encryption key at boot time 2) pull the encryption key out of RAM at any point while the server is running. You are counting on knowing when law enforcement is onto you and shutting down both servers before they get any kind of access (not just physical) to them. That's wildly unrealistic. Even if you manage to pull that off, you are not renting hardware you are renting a virtual machine. You have no control over RAM. Your encryption keys could be saved to the host's swap space long after you powered it down. They could also be taking snapshots of your machine while it is running and therefor in a decrypted state. FDE on a hosted server is never realistically going to help you.

>>3061 tl;dr rent a dedicated server or host in your basement

>>3062 Yes if your only concern is to use FDE and win an internet argument.

>>3061 In doxbin's text he sad about auto destruction scripts, which is the best way to deal with it? Not the destruction script itself what shall not be hard to do, but how can I trigger it in the right moment? I thought something like I do in veracrypt, there's two systems, if someone log in using the emergency password, it runs a script that erases everything. But how could I do this in a 24/7 service such as a vps?

>>3064 The example trigger warning in that pastebin was when your bridge nodes suddenly go down. >>3063 It is obvious if you don't own the hardware you can't tell if the keys are safe in ram or not. When you own your hardware, the only concern would be to destroy those keys securely. It's either a partition/flash drive, which is not secure and requires physical attendance, your head, not secure and hard to remember. a hidden service that goes down the moment swat team kicks your door.

>>3065 >The example trigger warning in that pastebin was when your bridge nodes suddenly go down. Entry guards, not bridges. Read the Sniper paper. >When you own your hardware, the only concern would be to destroy those keys securely. The keys are always in RAM while the machine is running, which for a server is 24/7. So FDE is pretty useless unless you also sit in front of the hardware 24/7 and pull the plug the moment law enforcement arrive. I'm sure even you have more of a life than that.

>>3066 Even then they can still freeze the RAM with liquid nitrogen and pull the encryption keys out after poweroff if they are quick enough.

>>3066 Bridges, preferably obfuscated, don't look suspicious for ISPs at a first look, and probably won't be derezzed even if you decide to host in a chinese village. >So FDE is pretty useless unless you also sit in front You skipped the part where automatics come over. No need to be with your servers 24/7. Erasing local keys securely is not a trivial part, you still have to have a memorizable password to unlock them, but if they are on another server in tor, you can securely erase this server anytime, the most thing maskheads will be left with is hidden service address that does not point to server's real location. Then another vulnerable on purpose hidden server automatically fires up to further mislead the spooks. long time after that if they even try to find out the real key when they rubberhose the original host location out of you, it will be surely long gone. Or you just put a raspberry pi in your mom's house, call her from jail and after hearing the passphrase from you, she will put the sd card into microwave. >>3067 Only if an attacker has access to a working machine or around 10 seconds after it was turned off. With VPS it's pretty damn straight, but with your own servers you can set up an emergency shutdown script when figures dressed in black armor show up on your cctv cameras or whatever.

I guess, ECC ram holds information for longer period, but you can also put locks on your hardware and heating elements inside every chassis that turn on after shutdown.

Does it really have to be 'your' server? What if you could use someone else's server somehow? Just a thought...

>>3071 Yes it has to be "your" server because he is only trying to prove FDE is not useless and ignoring everything else. >>3068 >Bridges, preferably obfuscated You didn't read the paper. I'm not going to push it. >You skipped the part where automatics come over. You skipped the part where "automatics" magically know when it is time to shutdown. >with your own servers you can set up an emergency shutdown script when figures dressed in black armor show up on your cctv cameras or whatever. Your server shutsdown everytime the mailman rings? And then it stays down until you can do your manual intervention to bring it back up again? Good job. Your customers/bots will be so happy to get service 3 hours per week. Sage, I feel like I'm talking to a 5 year old.

>>3075 Bring us this paper you are talking about, the pastebin linked in this thread clearly says "bridges". FYI, bridges are entry guards too, since every Tor entry node is a guard, bridges are just not released in public. >You skipped the part where "automatics" magically know when it is time to shutdown. Te same way burglar alarm works, it goes off the moment after windows or doors are broken, even walls if you live in burgerland. >Your server shutsdown everytime the mailman rings? I haven't seen mailmen going in groups of 10 dressed in full body armor, but pattern recognition computer vision algorithms are not something from sci-fi stories anymore. >ugh i'm literally angry right now, here is my sage button yeah now my name is different color cool that'll gonna show him calm down, negro

>>3077 >FYI, bridges are entry guards too, since every Tor entry node is a guard, bridges are just not released in public. Yes, all bridges are entry guards but not all entry guards are bridges. That's why >>3065 was slightly wrong for saying bridges (the subset) instead of entry guards (the superset). Well done for *almost* figuring it out by yourself and dragging it out over half the thread. >Te same way burglar alarm works, Fine. So you hooked up your home security system to your server. Good for you. >I haven't seen mailmen going in groups of 10 dressed in full body armor, but pattern recognition computer vision algorithms are not something from sci-fi stories anymore. >pattern recognition computer vision algorithms lol. We're so far off into lala land I'll just say yes this is all theoretically possible. Though you obviously have no experience with cv or ml because you will have encountered a number of practicality issues I'm not going to bother going into here. Back on topic, you shouldn't be hosting this soykaf at home and FDE will not be useful in the real world. Sage because this garbage discussion shouldn't be bumped to the top of the board where other people will waste their time looking at it.

>>3075 >You didn't read the paper. What paper are you referring to? The pastebin by Doxbin says >In this situation, if all of your relays are down, you essentially have an early warning canary that you're being targeted. after a paragraph that contains, "Bridge," six times. That entire pastebin does not contain the phrase, "Entry guard," at all.

OP here. >>3077 >>3079 Calm down. Let's stay in the subject, even if it changes of perspective somehow. This thread is great don't destroy it, please. I thought about using raspberry pi some time ago, but in someones wifi or a public hotspot without being noticed, and capable to stand alone... But ikd... I also thought in some self-destruction system, using termite, it was the most effective(shall i say dangerous), technique that I have found. So I decided not using, there were several concerns to take, like how the pi would stand alone, hiden and safe, in a place that you don't own. If someone have a solution, tell me. Let's use our brains, I know you are intelligent. Also, about the recognition thing, can't you get it done using Kinect?

>>3082 >What paper are you referring to? >>3066 >Read the Sniper paper. http://www.nrl.navy.mil/itd/chacs/biblio/sniper-attack-anonymously-deanonymizing-and-disabling-tor-network >The pastebin by Doxbin says >In this situation, if all of your relays are down, you essentially have an early warning canary that you're being targeted. >after a paragraph that contains, "Bridge," six times. The pastebin describes exclusively using bridges but that's a detail of the whole howto narrative. In this thread we were talking about the general concept of hidden service decloaking attacks then it's important to note that these attacks are not specific to only bridges. This was supposed to be a minor issue like pointing out a typo and then we can move on. The fact that this confused you so much suggests that you have a very weak grasp on this whole subject of Tor. >That entire pastebin does not contain the phrase, "Entry guard," at all. Entry guard and entry node are obviously the same thing. The official Tor documentation uses them interchangeably. To be honest what are you doing sharing your opinions on safely operating a Tor hidden service when you don't even understand Tor fundamentals? I think you need to read more and post less. Sage because, you know, we're not adding any value to the board here.

>>3083 > like how the pi would stand alone, hiden and safe, in a place that you don't own. How about a solar phone charger powering a pi in a waterproof case on the roof of a public library? Getting up there would be a pain, but that just makes it less likely to be found.

>>3089 >The fact that this confused you so much I just asked for clarification on what paper you meant. That doesn't seem like major confusion on the general concept. >what are you doing sharing your opinions on safely operating a Tor hidden service I wasn't sharing any opinions, just asking one question. I had one post in this thread, and it was asking you for the paper you were talking about.

>>3117 >I just asked for clarification on what paper you meant. That doesn't seem like major confusion on the general concept. My mistake. Clearly you are the l33test h@x0r on this side of the d33p w3bz.(Argue in good faith.)

>>3117 >I just asked for clarification on what paper you meant. There was only 1 paper mentioned in this thread and the pastebin. If that's all you wanted the you didn't look very hard before posting. >That doesn't seem like major confusion on the general concept. No, but you are conveniently forgetting the rest of >>3089. And I'm the one who is posting in bad faith? >The pastebin by Doxbin says >In this situation, if all of your relays are down, you essentially have an early warning canary that you're being targeted. >after a paragraph that contains, "Bridge," six times. >That entire pastebin does not contain the phrase, "Entry guard," at all. If you actually understood the difference between bridges and guards you wouldn't have posted any of this. Who are you trying to fool?

Trust the mods to ignore context and pour gas on the dumpster fire. Anyway. >>3116 >How about a solar phone charger powering a pi in a waterproof case on the roof of a public library? Getting up there would be a pain, but that just makes it less likely to be found. I'm not sure if solar energy can provide enough power for your Pi. I have 10.000mAh battery and my Pi can only last ~10 hours with it doing constant WiFi stuff. Something like that might work with something less power hungry than a Raspberry Pi and a low duty cycle radio protocol (i.e. no fuarrrking WiFi), but that's not really good enough to host a server.

>>3116 Problem is that were I live don't have the best weather, perhaps it would be needed more one battery. But this is a great start. As >>3135 said, maybe using a car battery would supply the needed energy.

>>3116 >> like how the pi would stand alone, hiden and safe, in a place that you don't own. >How about a solar phone charger powering a pi in a waterproof case on the roof of a public library? Getting up there would be a pain, but that just makes it less likely to be found. Could fly it to the roof with a drone. That would be fairly easy. May be difficult retrieving it for when it's time to change the battery, but perhaps there's no reason to retrieve it? A script could, in theory, alert you when the battery is about to die so that you could transfer (over Tor, of course) all the data you need to backup and move everything to a new pi, then set it up somewhere else, and srm -rf / the old pi. After all, if LE figured out someone was running an illegal service via a raspberry pi on a random roof, they're just going to wait to see who retrieves it. Probably best to just leave it to rot, assuming you can afford to replace it. Power is a huge issue however. >>3135 >>3169 A quick google search showed that a raspberry pi will draw a max of 1A. Car batteries are 40-120Ah, so a smaller car battery will net you at least 40 hours of power and the 120Ah batteries will net you 120 hours of power (thanks to the pi people for drawing a max of 1A, making this math super easy). In actuality, the pi probably won't draw its max of 1A, so it will last longer. This website lists the power consumption this one guy found for different pis with different peripherals when the pi was idle: http://www.pidramble.com/wiki/benchmarks/power-consumption It looks like if you were able to use a pi zero, 120mAh, and ignore the power consumption caused by your server, you'd still only be able to get 41 days of uptime. So, max uptime of 41 days and minimum of 5. You could stress test your server and measure the power consumption caused by that for a better minimum bound, and then just run your server and measure power consumption for a better upper bound. Hooking up a car battery to a little computer is going to look bomb-y as fuarrrk, so you'd always need to disguise your set up. If you're dropping it on a roof, that's probably not much of a concern since nobody will see it.

>>3170 >After all, if LE figured out someone was running an illegal service via a raspberry pi on a random roof, they're just going to wait to see who retrieves it. Not before pulling your hair and fingerprints from it. >It looks like if you were able to use a pi zero, 120mAh, and ignore the power consumption caused by your server, you'd still only be able to get 41 days of uptime. The Pi and the web server are not the main energy drains it's the radio. It won't be "idle" it will be doing constant WiFi, and probably be no where near the access point which means more power and retransmissions required, even 120 hours is optimistic.

>>3010 >Bulletproof hosting doesn't exist >what is tor hosting

>>4854 >Bulletproof hosting doesn't exist >what is tor hosting Tor is an anonymity network. It can host websites anonymously but onion sites are only robust because the clients also need to run Tor to connect so nobody knows where the real location of the server is. Bulletproof hosting refers to a provider who will host your stuff in the clear and ignores legal pressure to take it down even though everyone knows exactly where they are.

Im new so forgive any ignorance but i would like to share a thought: Why not drop a pi into a water sprinkler box. It has timed power up to charge batteries and is on the ground.

>>2994 the order of operations should be to first collect some low hanging fruit using tor, then use that low hanging fruit to collect more desirable systems (perhaps webservers) by tunneling tor through your initial infections. with enough webservers under your control then you can start to build up a fastflux network and then host stuff on that. if thats too much work and you are just looking for something quick, you are a couple dorks away from 1000s of neglected servers that you can host some light weight c&c on. there is also other back channels that could prove to be useful, like pastebin or twitter. really depends what you are planning, just take baby steps and keep building on what you got