Silk Road forums
Discussion => Security => Topic started by: astor on April 29, 2013, 05:23 pm
-
Does anyone want to brainstorm ways to mitigate the DOS attack? Of course, without knowing the nature of the attack, we can't offer specific help, but if we compile enough ideas, DPR should know which ones work, or test them until he finds a solution.
I can start with two suggestions.
1. Increase the number of intro points.
You'll have to download the Tor source code and edit /src/or/rendservice.c
Which can be viewed here:
https://gitweb.torproject.org/tor.git/blob/ab3d5c049032651a9c9164262f9a8f81de9709d4:/src/or/rendservice.c
Look at this section:
72 /** Try to maintain this many intro points per service by default. */
73 #define NUM_INTRO_POINTS_DEFAULT 3
74 /** Maintain no more than this many intro points per hidden service. */
75 #define NUM_INTRO_POINTS_MAX 10
76
77 /** If we can't build our intro circuits, don't retry for this long. */
78 #define INTRO_CIRC_RETRY_PERIOD (60*5)
79 /** Don't try to build more than this many circuits before giving up
80 * for a while.*/
81 #define MAX_INTRO_CIRCS_PER_PERIOD 10
82 /** How many times will a hidden service operator attempt to connect to
83 * a requested rendezvous point before giving up? */
84 #define MAX_REND_FAILURES 30
85 /** How many seconds should we spend trying to connect to a requested
86 * rendezvous point before giving up? */
87 #define MAX_REND_TIMEOUT 30
88
89 /** How many seconds should we wait for new HS descriptors to reach
90 * our clients before we close an expiring intro point? */
91 #define INTRO_POINT_EXPIRATION_GRACE_PERIOD (5*60)
Increase NUM_INTRO_POINTS_DEFAULT to something like 8, and NUM_INTRO_POINTS_MAX to 20. You may also experiment with changing the other values.
Then take a look at this section:
https://gitweb.torproject.org/tor.git/blob/ab3d5c049032651a9c9164262f9a8f81de9709d4:/src/or/rendservice.c#l1001
That's the formula for changing the number of intro points. You might try increasing the fudge factor from 1.5 to 2, or otherwise adjusting the formula to be more "sensitive" to intro point usage, and increase by a larger factor when they are getting hammered.
Build instructions are in the INSTALL file and here: https://www.torproject.org/docs/tor-doc-unix
2. Increase the number of entry guards.
This is potentially dangerous. It increases the likelihood of certain kinds of attacks and should only be used temporarily to mitigate an attack, if at all. You probably already know how to do this, but add NumEntryGuards to your torrc and set the value to something like 8 or 10.
Does anyone with experience defending web or database servers from attacks want to offer advice?
-
Find the people responsible and make them disappear off the face of the earth.
-
Find the people responsible and make them disappear off the face of the earth.
Yes in theory killing them would stop the dos attack.
Chaos
-
Find the people responsible and make them disappear off the face of the earth.
This....
-
Find the people responsible and make them disappear off the face of the earth.
Yes in theory killing them would stop the dos attack.
Chaos
It would also serve as a deterrent against future attacks. lol
DPR probably took all the documented measures, and maybe a few we don't know about. SR probably loses more money than the attackers want as ransom, and they know it. So it's either wait until they give up so it doesn't keep happening, or pay them and get hit again and again by various groups. Let's hope torproject mitigates DoS attacks on tor in general, and that the tor network continues to grow, making these attacks more difficult.
-
Find the people responsible and make them disappear off the face of the earth.
The people responsible may not realize that if their identities and location were exposed somehow, it's very likely that they would be killed, their house would get burned down, things like that. Imagine if you were a vendor making 30k a month in profits and you had to deal with this cutting into your profits two days a week and then you found out that the person responsible for it lives in the same state as you. Road trip.
Dumb. Stupid. Evil, even. I don't want anything to do with people who think like that. I know that some drug dealers are violent, but I keep hoping they're in a solid minority here on the Road.
goblin
-
Ok, while you all work on killing the attacker, anyone else have technical advice?
It's time for the community to step up and help the site they love.
-
Would be very good if we could get more information on what EXACTLY is going on. Security through obscurity does not work and the vagueness and lack of info here does not help.
If want to keep some methods to fight off out of public view, that is ok. The attackers know what they are doing, so telling us what they are doing is not a security risk.
WE WAN TO HELP!! some here have many resources and technical skills, allow us to brainstorm. :)
MAKE THEM WALK THE PLANK DPR!! :D
-
One simple and effective way to stop a DDoS attack is to bounce/rediurect the traffic towards the point of origin, or the site of the point of origin (if that person has a site). This has the added benefit of letting you know if that person or people are responsible (IF both the nature and the site you are redirection traffic to both change to resist redirected traffic you can safely bet its them).
You could also run your own offensive DDoS to limit their ability to make outgoing pings.
You could also exponentially time out repetitive requests on the url, along with setting a dynamically shifting ip address for the server and dis associate. and only allow the ip to access traffic from the url address.
Hope this makes sense
-
People on an anonymous website talking about burning peoples houses down.. LOL...
OP is on the right track :) fight fire with fire...
-
hey astor, +1 for posting up some possible solutions. This is what community is all about: collaboration!
-
Ok, while you all work on killing the attacker, anyone else have technical advice?
It's time for the community to step up and help the site they love.
It always puzzles me as to why DPR won't give us a little detail on the attack. Or call on some of the forums members like Astor and others known to be trustworthy and well versed in these things.
I'm sure he has good reasons tho.
Unconditional love for DPR.
Chaos
-
Just what the "ATTACKER" needs, is more info from a forum. DOS attacks are initiated in private and are dealt with in private.
Hence, DPR isn't about to volunteer what the problem is and what they are doing about it in private, on this public sieve.
The "ATTACKER" is reading this right now. ATTACKER's have huge ego profiles.
In the 2 years I've been here Silkroad aka DPR, that's right Silkroad was his original handle and the only handle I recognize,
with his team have overcome server growing pains, btc scamming pains, scammer pains. This DOS pain is no different and we're
still here. So everybody can feel free to postulate at will, and Silky will continue to find a solution.
See you when the store reopens.
Bikerbum
-
The old security through obscurity.
The attacker knows what kind of attack he's running, thus he already knows how it can be mitigated, if that's possible at all. Openly discussing it reveals nothing new to the attacker.*
What appears to be the case is that DPR doesn't know how to mitigate it, which is why he mentioned several options in his latest post. That's why we need to be throwing out suggestions.
*Not to mention that if we throw out enough ideas, he won't know which ones were implemented.
-
I know this Is probably going to rack up the - karma. I'm not as computer skilled as alot of you, so correct me If I'm wrong.
From what I've read so far a DOS attack Is fairly easy for 1 to pull off.
Hypothetically speaking, say this particular DOS attack was the work of Atlantis/BMR. Say a few tech savvy guys on Silk Road got together and plotted to strike back. If they were to launch an attack on Atlantis/BMR, they would crash as well right?
Due to the number of people here that are willing and able to help, why not DOS Atlantis/BMR and see If the attacks cease?
-
I think that we can reasonably guess this is either a DDoS on the introduction nodes or an attack by introducing HSDir nodes which serve up bad data.
Fixes for both of these attacks require source code changes to Tor, we need hackers to be interested and involved in the problem and to fix it. Maybe offering a bounty in Bitcoins is the right way to go here, because what anonymous security researcher *wouldn't* want to collect a bounty of several grands worth of untraceable cryptocurrency?
In the short term it looks like changing the address could combat rogue HSDir nodes, while more introduction points (like in the first post) would combat the first issue. Offering up the service over I2P may also be a reasonable work-around.
@imghost9: Don't suggest that. Anyone who remembers the IRC wars of the early 2000s knows that that's not a good idea. Services were disrupted for months, networks were destroyed and everybody lost. DDoS is the nuclear option.
-
I found a few articles on clearnet that are related to preventing selective DOS of a TOR service. The last article contains a post by the author of pyLoris that describes his recommendations for mitigating DOS from pyLoris and Tor in general. I hope one of these helps. I will be doing as much research as I can to help find a solution.
hxxp://arxiv.org/pdf/1107.3863.pdf
"Anonymous communication systems are subject to selective denial-of-service (DoS) attacks. Selective DoS attacks lower anonymity as they force paths to be rebuilt multiple times to ensure delivery which increases the opportunity for more attack. In this paper we present a detection algorithm that filters out compromised communication channels for one of the anonymity networks, Tor. Our detection algorithm uses two levels of probing to filter out potentially com-promised tunnels. We perform probabilistic analysis and extensive simulation to
show the robustness of our detection algorithm. We also analyze the overhead of our detection algorithm and show that we can achieve satisfactory security guar-antee for reasonable communication overhead (~5% of the total available Tor bandwidth). Real world experiments reveal that our detection algorithm provides good defense against selective DoS attack."
hxxp://fc09.ifca.ai/papers/43_Detecting_dos_in_tor.pdf
"More recently, Borisov et al. [3] showed that an adversary willing to engage in denial of service (DoS) could increase their probability of compromising anonymity. When a path is
reconstructed after a denial of service, new proxies are chosen, and thus the adversary has another chance to be on the endpoints of the path. Our contributions are as follows. We prove that an adversary engaging in the DoS attack in an idealized Tor-like system can be detected by probing at most 3n paths in the system, where n is the number of proxies in the system. Through simulation, we show that an adversary attempting to avoid detection by engaging in DoS probabilistically can still be detected, and that the attempt to avoid detection radically degrades the effectiveness of the attack. Finally, using measurements of connection drop rates across Tor nodes, we implement a version of the detection algorithm and conclude it is unlikely that such an attack was in progress during the time period the network was observed."
hxxp://security.stackexchange.com/questions/19698/mitigating-anonymous-dos-tor-combined-with-pyloris
"sarepta: To start off, I am the author of PyLoris, so I have done a good amount of research into this. In fact, the attack you have envisioned is one that I specifically coded to when developing PyLoris--the current version even comes bundled with an helper app tor_switcher.py which routes the attack through multiple Tor exit nodes.
The only good way of detecting a Tor-based flood is by checking source IP addresses against known Tor exit nodes. This is trivial with blacklisting or plugins like mod_security. In my research, mod_antilors does not prevent the PyLoris+Tor vector as it is IP address based. My personal choice for preventing this attack is to use any server other than Apache to handle direct connections from the internet. This could mean using a reverse proxy like Varnish to marshal requests or switching to something like nginx for your web server.
Aside from rethinking your infrastructure, I do feel that a combination of low timeouts, IP connection limits, minimum data transfer rates, maximum connection time limits, and maximum request sizes can provide adequate protection from this form of attack. I say this all with the disclaimer that there is no way to prevent this form of attack, and that these configurations should be thought through thoroughly to gauge their impact on a per-server basis."
I think it's much more likely this this is what is being used to DOS SR:
https://blog.torproject.org/blog/hidden-services-need-some-love
If this is the case, SR is going to have to make some contributions to the TOR codebase itself or hope that someone does it for them. It might be better to switch to I2P...
-
http://dkn255hz262ypmii.onion/index.php?topic=153350
-
@imghost9: Don't suggest that. Anyone who remembers the IRC wars of the early 2000s knows that that's not a good idea. Services were disrupted for months, networks were destroyed and everybody lost. DDoS is the nuclear option.
Your a rich person and everybody flocks to you because you have money, and I'm a hobo.
Your walking down the road to go to the ATM machine, I beat you up and rob you.
While your recovering, I'm partying In your mansion with some of your friends. I bone your wife.
You come back and Inform your friends and wife what happened. You take back what Is rightfully yours, and tell me to leave.
Your rich and happy again and I'm a hobo, with your wives phone number.
You decide to use a different ATM machine far away.
Your wife calls me and tells me your location.
Once again your left beaten and robbed. The only difference Is, Now I and everybody else knows that there's no consequences for stealing what YOU worked for.
-
Could silk road be hosted on some sort of VM hosted on a tor-based cloud? With multiple mirrors hosted the same way?
When a DOS is launched against one of them, simply switch to another?
-
The admin of OVDB used to say that SR had vulnerabilities, and he was really tech-savvy. I think he goes by " kmfkewm" on here. Perhaps he can give a helping hand to DPR.
-
The admin of OVDB used to say that SR had vulnerabilities, and he was really tech-savvy. I think he goes by " kmfkewm" on here. Perhaps he can give a helping hand to DPR.
That's the admin of OVDB?!
-
I don't know about any particular vulnerability in regards to Silk Road. I will say that I have seen some less than ideal configuration though, for example having detailed error messages enabled in a production site. At the end of the day the security of a site like SR is not of utmost importance for customers, they must handle their security themselves and not rely on an non compromised server. The primary things that present real problems are things like DoS attacks , and of course the risk to DPR and vendors that hackers could steal the escrow. Although this is only ideally, as we all know that most users here do not encrypt their addresses with GPG, etc, and thus they needlessly make it so that they do indeed rely on the security of the server hosting the site.
As far as the DoS of SR goes, I cannot say much without knowing specifics of the attack. I don't go to the SR marketplace ever, but I did notice a few things when the forums were said to be being DDoSed. The first thing I noticed is that Tor was indeed building a circuit to the instance of Tor running on the server hosting this forum. It was just immediately closing streams through it. This means that the introduction nodes were not being DDoSed, it also means that the server was not being overwhelmed with bandwidth. If the introduction nodes were inaccessible, I would not have been able to successfully build a circuit that communicated with the instance of Tor running on the server. This also means that the server itself was clearly running and had sufficient bandwidth available, otherwise it would not have a running instance of Tor capable of establishing a connection. It seems to me that the problem is with the actual web server, Apache I believe. The connection to the instance of Tor running on the SR forum server was working fine for the entire time, however after establishing the circuit the streams through it were immediately closed by the remote host. This is what we would expect to see if Tor was running and configured to redirect incoming traffic to a port that had nothing listening on it, or had something malfunctioning listening on it.
Another thing I noticed is that intermittently Apache began working again, and the circuit built to the instance of Tor on the forum server was useful for maintaining open streams. During the brief periods in which this happened the server returned 500 errors when attempting to access legitimate pages, but when attempting to access pages such as http://dkn255hz262ypmii.onion/made_up_not_real.php it was returning 404 errors as normal. I see that now attempting to load false .php pages is returning a 'No input file specified' error , and attempting to load any .html page loads the forum index, so apparently they changed something since the forums went down. It didn't take long before the intermittent 500 error messages were replaced with a maintenance message, and the forum came up shortly after that.
My impression of the down time for the forum was that their instance of Apache kept crashing and being brought back up. Definitely the server itself remained reachable the entire time, and connections to their hidden service were also flawless the entire time, it is just that Tor was apparently redirecting the traffic to a port that had nothing listening on it. That said, it doesn't rule out a DoS attack. Perhaps the attacker exploited a remote flaw in Apache, or somewhere in the configuration, and kept remotely crashing the web server. But it does pretty definitely rule out a bandwidth flooding DDoS, and also rules out a DDoS on the introduction nodes, and a DoS of the box itself.
The first step of determining what went wrong is finding why there was a 500 error being returned. I cannot do this without access to Apache error logs from the server. Searching shows that 500 errors are pretty ambiguous and can refer to a wide variety of different things. Maybe it was caused by a PHP misconfiguration or crash, and that is why fake .php pages were returning 404 errors but real ones were returning 500 errors. The real root of the problem is probably figuring out why Apache was crashing / PHP was throwing a fit or crashing.
-
Looking at the connection log it seems that the introduction cell is being sent from my machine but I will never receive the introduction ack. Rendevous seems to be fine. Ping of the introduction node comes back looking pretty healthy.
This seems to be at odds with what you saw when the forum was being attacked...
Confused..........
-
I was thinking about this. But we don't know what kind of DOS is being run.
Is it simply requesting the login pages over and over or is it using credentials to request the main page over and over(probably a database rich connection).
Another problem is I suspect it takes a decent amount of computer time to handle tor packets which means by the time you've unencrypted the packets and decided whether it should be filtered or not the damage is done.
The best way to prevent a DOS is to make it seem like it's pointless/not working.
Either way step one would be to convert to a shell static website (the maintanance page) this makes handling requests easier takes load off your network and creates the image of "we are in control", "we are winning". Which may put some/all attackers off (those that aren't just agents at least).
Next you want to actually start working. You need to set up some filter perhaps load balancing system to handle the increased through put. I would disable registration and drop and ignore all packets which aren't logged in and Rate limit those that are logged in to 1 packet a minute.
This still means you have to handle the overhead of this all happening on tor.
-
The entire time the forum was down I had no trouble establishing an open circuit to dkn255hz262ypmii.onion. I even closed the open circuits I established a few times and rinsed and repeated, and never had any trouble establishing an open circuit. The problem was that streams through the circuit were going from connecting to closing almost immediately, without ever opening. That is indicative of Tor on the hidden service redirecting traffic to a port that has nothing listening on it. Do an experiment, configure a hidden service yourself but don't run anything on the port that you have it redirect traffic to. Now connect to the hidden service. You will see the same exact behavior, the circuit is established without problems, but the streams through the circuit quickly go from connecting to closed. I am pretty much absolutely certain that the actual forum server did not experience any down time, and I am equally certain that the introduction nodes behaved correctly and were not DDoSed. Tor on the remote server (dkn255hz262ypmii.onion) was running and operating perfectly for the entire duration of the down time (that I witnessed anyway, which was quite a while but probably not from the very start). The problem was that it was redirecting traffic to a port that had nothing listening on it, or something malfunctioning listening on it. This means that the problem was with Apache (and very likely it had crashed). Towards the end of the down time Apache started working correctly, because the streams were going from connecting to open to closed, and a 500 error was returned on valid pages and 404 on invalid pages. This suggests to me that the problem at this point was with PHP, but it could have been an Apache problem as well. It looked like Apache kept crashing and coming back up, because it would go from rarely loading with a 500 internal server error, to forming a circuit to the remote instance of Tor, but with streams through it going from connecting to closed.
I am positive that the server hosting this forum did not go down nor was it overwhelmed with bandwidth. I am also 100% positive that the introduction nodes were not DDoSed. I am less sure, but still quite confident, in saying that the down time was caused by Apache crashing.
-
That is indeed what it looks like for the forum.
The main site however is different.
Hmm, managed a successful connect once just a moment ago and got maintainance page.
Now I get past introduction and receive
[Info] connection_ap_process_end_not_open(): Edge got end (server out of resources) before we're connected. Marking for close.
-
I have not looked at the main site at all, only the forums, as I mentioned in my original post :D. It looks like the error you posted is actually a Tor error message. I see reference in Tor support tickets to several variants of it:
https://trac.torproject.org/projects/tor/ticket/1519
Jun 08 20:41:28.171 [Info] connection_ap_process_end_not_open(): Edge got end (connection refused) before we're connected. Marking for close.
for example. I don't see any reference to it with (server out of resources) , but it is pretty apparent what that error message means. So it seems like there is a resource exhaustion attack against the server, from that error message. Please post the link to the main site for me, I literally never go there so I don't even know the .onion for it. Are you able to establish circuits to it? In your previous post you said that you can send introduction cells but never get a response, that would indicate the introduction nodes are being DoSed. If you get an open circuit but streams close, that means that the problem is not with the introduction nodes.
Digging up that error message in the Tor source code to see exactly what triggers it.
-
Somebody with access to the SR server should type in the command top and see if the CPU is at 100%, or if the memory is exhausted. In either case they should see which process is using all the CPU or Memory.
-
I can occasionally create circuits to the main site, more often than not today I will receive the error i posted above.
Yesterday however I could not get an ack in response to the INTRODUCTION1 cell.
Link to main site:
http://silkroadvb5piz3r.onion/
-
Yep it definitely looks like it is the introduction nodes being DoSed and not the server itself, because circuits cannot even be established. The server out of resources message probably is referencing to the introduction nodes of SR. I think the best bet is to take Astors advice and modify the source code in order to use a lot of introduction nodes.
-
A quick way for SR staff to confirm that this is the problem, is to create a new .onion address pointing to the same port as the original one. This will use a different set of introduction nodes, and as the address will not be made public, the attacker will not DDoS those introduction nodes. If they can access the site with this new .onion address, then it is definitely the introduction nodes being DDoSed. Keep in mind sometimes it takes a little bit to access a newly created / launched hidden service though.
-
^Someone pay this man (or woman). Even if he doesn't want it :D
-
Yep it definitely looks like it is the introduction nodes being DoSed and not the server itself, because circuits cannot even be established. The server out of resources message probably is referencing to the introduction nodes of SR. I think the best bet is to take Astors advice and modify the source code in order to use a lot of introduction nodes.
I threw that out there without knowing what the problem is, hoping to get a conversation started, but now I think it's the intro points too. I go from 4 or 5 open circuits to 20 and then it dies, no error message.
-
Same here. I also doubt it's the server itself. At first I thought along the lines of a SYN flood, where the server is still able to build circuits but too many are left half open for it to manage. Since I don't think that's possible (or effective) over tor--and as kmf said you don't get the "server out of resources" message--it likely is an attack on the only nodes the attackers can reasonably find: the entry nodes.
On the other hand, I can still build circuits to the SR server, at least as of this post. HTTP connections still close immediately though. It's almost like the old ICMP/TCP RST attacks from back in the day, although I don't see how that would work here. lol
-
@kmf Thats pretty much what I figured.
Nice job on the suggested test.
I just wish staff were a little more transparent about this. I am absolutely certain they know exactly what is going on, but yet there are many here spending hours trying to figure it out.
I wonder if you could choose some of the introduction nodes too. There are some with some pretty impressive bandwidth.
Interestingly tor does some sort of reset/clear connections every 20 mins or so. Immediately after this I can get to the maintenance page. However all additional attempts after this will fail until the next reset.
EDIT: If its even possible I have absolutely no idea what effect fixing introduction nodes will have on privacy/anonymity
-
There is also the question of if it is definitely an intentional DDoS or if SR is just too popular for Tor to handle. At least one other really popular hidden service, with hundreds of Tor users, simply could not scale any larger with a single hidden service. They were not being DDoSed by an attacker, but their introduction points were so overloaded by their legitimate users that hardly anybody could connect with the .onion anymore. Although in their case they had people who could connect still, if absolutely nobody can connect to the silk road market then it is probably an intentional DDoS. If it has 100 people able to connect, and 400 who cannot connect, then it has very likely just gotten more popular than Tor can handle. In either case increasing the number of introduction nodes will alleviate the issue, but unfortunately if there is an attacker they can probably take down a lot of introduction nodes. If they have a Botnet they can probably exhaust the processing power of the entire Tor network :(.
-
Same here. I also doubt it's the server itself. At first I thought along the lines of a SYN flood, where the server is still able to build circuits but too many are left half open for it to manage. Since I don't think that's possible (or effective) over tor--and as kmf said you don't get the "server out of resources" message--it likely is an attack on the only nodes the attackers can reasonably find: the entry nodes.
On the other hand, I can still build circuits to the SR server, at least as of this post. HTTP connections still close immediately though. It's almost like the old ICMP/TCP RST attacks from back in the day, although I don't see how that would work here. lol
Not likely a DoS of the entry guards. Unless strict entry guards are used, the hidden service will switch to a new entry guard temporarily while one of its previously selected ones is down. The attacker would need to DoS a lot of entry guards simultaneously to prevent access to a hidden service. They would probably be able to brute force deanonymize it with mass entry guard DoS + timing attack before they could block access to it in this way. It looks very much like itnroduction node DoS.
The behavior that you describe sounds like what I was seeing on the forums when they suffered down time, and is indicative of a crashed Apache. However, I am personally incapable of establishing a circuit to the marketplace.
-
@kmf Thats pretty much what I figured.
Nice job on the suggested test.
I just wish staff were a little more transparent about this. I am absolutely certain they know exactly what is going on, but yet there are many here spending hours trying to figure it out.
I wonder if you could choose some of the introduction nodes too. There are some with some pretty impressive bandwidth.
Interestingly tor does some sort of reset/clear connections every 20 mins or so. Immediately after this I can get to the maintenance page. However all additional attempts after this will fail until the next reset.
EDIT: If its even possible I have absolutely no idea what effect fixing introduction nodes will have on privacy/anonymity
I think mods don't have any beckend access, and DPR is too busy dealing to bother writing huge explanations. He came on, told us there was an attack and that they were working on it, and has updated a couple of times. He may need some sleep too, I don't even work here and I could use a few extra hours after last night.
-
Oops, I meant the introduction nodes as you said a few posts back. For some reason I keep getting that confused with the entry guards lol
Agreed on the crashed apache. The maintenance page would always pop if I was able to connect, and now I can get a circuit but the connection is immediately reset (at least it looks like a rest). Maybe it's a SR-specific attack of some kind...
EDIT: Just got the maintenance page with error message.
-
Another thing that doesn't quite add up is in theory once you have got the introduction node to introduce you to the hidden service tor should build a seperate circuit for communication between client/server and the introduction circuit is discarded. This is obviously happening as we can occasionally connect. Whats a little odd though is that subsequent connections within a specified time period should reuse the previously created circuit. This is not happening.
-
@kmf Thats pretty much what I figured.
Nice job on the suggested test.
I just wish staff were a little more transparent about this. I am absolutely certain they know exactly what is going on, but yet there are many here spending hours trying to figure it out.
I wonder if you could choose some of the introduction nodes too. There are some with some pretty impressive bandwidth.
Interestingly tor does some sort of reset/clear connections every 20 mins or so. Immediately after this I can get to the maintenance page. However all additional attempts after this will fail until the next reset.
EDIT: If its even possible I have absolutely no idea what effect fixing introduction nodes will have on privacy/anonymity
Not likely to be bandwidth DoS unfortunately, but rather CPU. Unfortunately, attackers can make Tor nodes do computationally expensive operations without having to do computationally expensive operations themselves.
-
Another thing that doesn't quite add up is in theory once you have got the introduction node to introduce you to the hidden service tor should build a seperate circuit for communication between client/server and the introduction circuit is discarded. This is obviously happening as we can occasionally connect. Whats a little odd though is that subsequent connections within a specified time period should reuse the previously created circuit. This is not happening.
Yeah after that the connections should be through the rendezvous node, and the successfully opened circuit should stay good for a decent period of time.
-
yeah we gotta do em in like the cartels did... there family see their head on the 5 o clock and the rest of their body on the 6 o clock news.
probably scare off future attacks too ahaa
-
I finally managed to establish a circuit to the market and it looks like Apache crashed, same as the forums did last night (circuit is open, streams through it fail). I wonder if the people establishing connections DO maintain their circuit through the rendezvous node, but Apache keeps crashing and coming back up, giving the impression that the circuit is failing when it is actually just Apache crashing. I have been maintaining my open circuit for several minutes now, but it took me like an hour of hitting refresh periodically before I was introduced. Of course the site looks like it is down, but it is likely because Apache has crashed because the circuit remains open.
-
yeah we gotta do em in like the cartels did... there family see their head on the 5 o clock and the rest of their body on the 6 o clock news.
probably scare off future attacks too ahaa
ahahahahahhhahahahahahahahahahahahahahahhahahahahahahahahahahahahahahahahahahahahhhahahahahahahahhahahahaha
no wait just kidding.
-
If the actual service goes down, like the web server, then a TCP connection won't be formed and the circuit will (or should) be killed.
-
If the actual service goes down, like the web server, then a TCP connection won't be formed and the circuit will (or should) be killed.
Nah, the circuit is to Tor and is entirely independent of the web server. If the web server goes down the circuit will still be just fine, but all the streams going through it will go from connected to closed.
-
Tor is not going to keep empty circuits open other than the baseline ones it always keeps open.
-
Tor is not going to keep empty circuits open other than the baseline ones it always keeps open.
Sure it will. Otherwise it would close a circuit as soon as a page is done being loaded. It keeps an established but inactive circuit open for about ten minutes before discarding it. You can prolong the life of the circuit by trying to open streams through it, even if the streams fail to connect it resets the remaining time to keep the circuit open. I was able to indefinitely keep the circuit to the market open despite never being able to establish an open stream through it, but after manually closing the circuit I wasn't able to establish another one, likely because the introduction nodes are being pwnt.
-
Sure it will. Otherwise it would close a circuit as soon as a page is done being loaded. It keeps an established but inactive circuit open for about ten minutes before discarding it.
Those are the baseline ones I was talking about, the 3 hop circuits that it always keeps open and rotates every times minutes.
You can prolong the life of the circuit by trying to open streams through it, even if the streams fail to connect it resets the remaining time to keep the circuit open. I was able to indefinitely keep the circuit to the market open despite never being able to establish an open stream through it, but after manually closing the circuit I wasn't able to establish another one, likely because the introduction nodes are being pwnt.
Right, you're sending data through it. How often did you do that?
-
Is anyone else finding it increasingly difficult to use the forum? It keeps delaying or timing out.
Anyway, I was under the impression that all hops must use fully formed TCP streams. That's why syn floods are not possible. Your Tor client makes a full connection to the entry, which makes a full connection to the next relay, and so on. I guess I didn't consider that in the last hop it may allow you to blast the service with whatever data. :)
-
Those are the baseline ones I was talking about, the 3 hop circuits that it always keeps open and rotates every times minutes.
I mean the circuit to the hidden service through the rendezvous node. After that is established, it will stay open for about ten minutes of inactivity before you need to establish a new circuit to it and use the introduction nodes again.
Right, you're sending data through it. How often did you do that?
Well I have finally managed to get yet another circuit to the market. I will send more data through it right now. It is still connected, tries to open streams but they go from connecting to closed. Now I will wait a few minutes. Three minutes later I try again, and the circuit from before is still open, and the streams go from connecting to closed again. I waited another couple of minutes and this time I loaded the maintenance page, although immediately after I tried again and it went from connecting to closed. Now it keeps going from connecting to closed, but on the same circuit as before. I manually closed the circuit and try again, and now it fails to establish a circuit after multiple refreshes.
For another test I made a hidden service that redirects traffic to a port with nothing listening on it. A circuit is established to the hidden service, but of course the streams go immediately from connecting to closed. I will wait five minutes and try again. Yep, it is still using the same circuit, and the streams go from connecting to closed again. I closed the circuit and tried to connect again. New circuit is used of course, and established without any trouble because the introduction nodes are not under attack. The same behavior as before, a circuit is established but all of the streams go from connecting to closed.
-
Thats strange as I cannot keep a circuit to the market open for more than about 20 seconds after the stream has closed. Which of course means that any new stream will open a new circuit and have to be routed through the usually non responsive introduction node.
-
Interesting. So it seems both the intro points and the web server are under attack.
-
It seems that way astor.
Forgive me if I am mistaken, my understanding was that if the rendevous circuit that is established after intro is broken or closed that any new circuit to that server would then have to go through the introduction stage again.
Thats certainly what my client is doing and is what I understood from reading the protocol spec.
Be interested to know :)
-
It seems that way astor.
Forgive me if I am mistaken, my understanding was that if the rendevous circuit that is established after intro is broken or closed that any new circuit to that server would then have to go through the introduction stage again.
Thats certainly what my client is doing and is what I understood from reading the protocol spec.
Be interested to know :)
Yes you are correct but there is a difference between a circuit and the streams that are routed through the circuit. In vidalia you can see the circuit as the series of three node names, and the streams are underneath the circuits and look like this : dkn255hz262ypmii.onion:80 open (or connecting, or closed). If the circuit that is established is broken or closed, then you need to go through the introduction stage again. But if the streams are broken or closed or never open, the circuit stays open until it is inactive for a period of time. By opening new streams through the circuit, you make the circuit active again, even if the streams going through it never connect.
-
And the web server crashing will cause the open streams to close, and new streams to fail to connect in the first place. But the actual circuit is not to Apache, it is to Tor, and it will stay open even if there is nothing listening to the traffic after Tor redirects it to a port after receiving it. For the actual circuit to abruptly close, it would mean that the remote instance of Tor crashed, Apache crashing will cause the streams to abruptly close but not the circuit.
-
Which is the bit thats puzzling me, I repeatedly watch both stream and then circuit close every time I get a connection. I cannot keep a circuit to SR open when there is no traffic.
Just as a matter of interest, what platform are you running on. I am running Winx64. I might have to fire one of the linux boxes up and see if the behavior is the same.
EDIT: Now I see whats happening.
The circuit will show closed and then disappear fron the circuit list but actually remains open. Turning debug logging on suddenly makes things clear as day :)
-
The admin of OVDB used to say that SR had vulnerabilities, and he was really tech-savvy. I think he goes by " kmfkewm" on here. Perhaps he can give a helping hand to DPR.
That's the admin of OVDB?!
Yeah, dude. DPR should give him access, he has a pristine rep in this scene.
-
OK that shines a slightly different light on things then.
The server out of resources error must be coming from the SR server and not the Introduction node as we thought earlier. The circuit to SR is definitely open and with the debug logging on I am sure that no request is being sent to the Introduction node. Could Apache crashing make tor report that error do you think?
-
Is moving from apache for the main SR site to something with less overhead like node a possible medium-term solution?
-
OK that shines a slightly different light on things then.
The server out of resources error must be coming from the SR server and not the Introduction node as we thought earlier. The circuit to SR is definitely open and with the debug logging on I am sure that no request is being sent to the Introduction node. Could Apache crashing make tor report that error do you think?
If the circuit to SR is open that means that you see streams underneath a set of three nodes in vidalia.
node1,node2,node3
.
.
...dkn255hz262ypmii.onion:80 connecting
that is what an open circuit to the SR forums looks like in Vidalia, but the stream is not open it is connecting. If the stream fails to connect it will look like this
node1,node2,node3
.
.
...dkn255hz262ypmii.onion:80 closed
and then like this
node1,node2,node3
in this case, node1,node2,node3 is still an open circuit to the hidden service for a while, because if you hit refresh it will look like this again, with the same set of nodes:
node1,node2,node3
.
.
...dkn255hz262ypmii.onion:80 connecting
if you don't hit refresh for a good deal of time, it will attempt to do the introduction step again, and if it does this then a new circuit will be established that uses a different set of nodes.
-
kmfkewm, dbelle and astor: what you're all saying is Greek to me. But it sounds like you all know what you're talking about.
If DPR doesn't ask for your help on bended knees, he's a jerk. Sorry, but that's how I feel right now. I've had it with this crap.
goblin
-
Does I2P suffer these same introduction node vulnerabilities (or something equivalent)?
-
This suggestion about using I2P is not in my opinion a starter, as it is much more difficult to get regular non-computer savvy people to make a go of it. It's one thing to download and install tor but just try to get them to install I2P, making sure all is going as it should. It's much harder.
My opinion anyway.
-
Find the people responsible and make them disappear off the face of the earth.
The people responsible may not realize that if their identities and location were exposed somehow, it's very likely that they would be killed, their house would get burned down, things like that. Imagine if you were a vendor making 30k a month in profits and you had to deal with this cutting into your profits two days a week and then you found out that the person responsible for it lives in the same state as you. Road trip.
I got the rope if you have the fuel and the lighter.
-
Goddamn I've been trying to post this for 15 minutes.
Anyway, I can confirm that the same circuit (to the forum) stays open even when I don't interact with it for many minutes.
I haven't been able to connect to the SR server yet to test that out.
-
what is OVDB
-
This suggestion about using I2P is not in my opinion a starter, as it is much more difficult to get regular non-computer savvy people to make a go of it. It's one thing to download and install tor but just try to get them to install I2P, making sure all is going as it should. It's much harder.
My opinion anyway.
I2P is entirely out of the question anyway. Vendors leak their rough geolocation and I2P by default reveals the IP addresses of all users (just makes it hard to tell what the IP addresses are doing through I2P). It is not compatible with our threat model.
-
Just what the "ATTACKER" needs, is more info from a forum. DOS attacks are initiated in private and are dealt with in private.
Hence, DPR isn't about to volunteer what the problem is and what they are doing about it in private, on this public sieve.
The "ATTACKER" is reading this right now. ATTACKER's have huge ego profiles.
In the 2 years I've been here Silkroad aka DPR, that's right Silkroad was his original handle and the only handle I recognize,
with his team have overcome server growing pains, btc scamming pains, scammer pains. This DOS pain is no different and we're
still here. So everybody can feel free to postulate at will, and Silky will continue to find a solution.
See you when the store reopens.
Bikerbum
Congratulations and Salutations Silky. As usual your team needs no assistance.
The store is open and my orders are in.
Bikerbum
-
Express orders in transit. Ahhh, Life is good on the road.
Fuck you DoS pinheads. You can't shut this revolutionary experiment down for long.
Thanks Silky.
Bikerbum
-
some hours ago i experienced access problems again. do not know if this was again an attack. now its working again. i also notice that when SR is abailable its faster than some weeks ago...
if the server was available the whole time and only the hidden service at tor level had problems, it might be a good idea to spread alternative links for the vendors to process their orders in time...
-
firsf off and this is just my humble opinon dpr should not tKe advice from anyone .ANYONE outside he or shes inner circle and espwcially not on here when it comes to fixing this problem and preventing it in the future. dpr has his or her thinking cap on im sure. dpr im sure is in full ninja mode and any information given out on uere is a ploy to the real facts about what is going on behind the scenes. i hope so anyways. all thay dpr needs from us is our prayers and best wishes and our humble thank yous for being here for us all and giving many of us a happier life. gods speed dpr and in tthe words of james t kirk..."may fortune favor the foolish"