it looks like i've found an exit node mitm-ing ssh, or at least giving
it a shot.
https://atlas.torproject.org/#details/29378422C99074D06331D5700E47451610B0D20
that exit policy looks more like a wishlist than anything else, at this point.
notice all 3 sites have different clear wire ssh keys (ob
hould have done this ages ago.
On Sat, Jul 29, 2017 at 9:11 PM, teor wrote:
> Hi,
>
> I've cc'd bad-relays with this report.
>
> Please send reports of bad relays to bad-rel...@lists.torproject.org.
>
>> On 30 Jul 2017, at 02:56, eric gisse wrote:
>>
>&
I use pure IPv6 on a bind caching nameserver:
2001:4860:4860::8844; 2001:1608:10:25::1c04:b12f; 2600::1;
Considering the throughput of my exit node and the amount of dns
cached, I not leaking as much as you might expect.
On Fri, Aug 4, 2017 at 2:38 PM, teor wrote:
>
>> On 5 Aug 2017, at 00:29,
...and what is dnscrypt supposed to do for a relay? where are the DNS
queries themselves supposed to come out?
i'm yet to hear why a big caching nameserver is insufficient. i'm
doing 30mb/s on an exit node. here's my rndc stats:
[View: internal]
86635983 IPv6 queries sent
Roger: I got an exitmap module that hunts for these.
https://github.com/jowrjowr/exitmap/blob/master/src/modules/sshmitm.py
On Wed, Aug 9, 2017 at 5:23 AM, Roger Dingledine wrote:
> On Wed, Aug 09, 2017 at 02:41:34AM -0400, Roger Dingledine wrote:
>> Right -- it seems clear that there is some
Just out of curiosity, do DoS attacks against dirports even happen?
My server gets nailed by what my host thinks is a DOS every now and
then but I'm yet to get details.
Does anyone have a good idea on how I would be able to classify
traffic as an attack rather than normal "shitloads of traffic" ?
Check out https://github.com/NullHypothesis/exitmap
On Sun, Nov 5, 2017 at 2:16 PM, Kijani wrote:
> Hi folks,
>
> Does anyone have a script for periodically updating strick exit nodes lists
> after running an inspection as per
> https://tc.gtisc.gatech.edu/bss/2014/r/spoiled-onions-slides.pdf or
I can kinda answer that.
I run an exit node that happily does 200-250mbit/s according to
netdata accounting and my monitoring regularly pegs it at nearly 200k
connections. Usually 100-150k.
On Sun, Jan 21, 2018 at 4:06 PM, nusenu wrote:
>
>
> Quintin:
>> Ah, thats it. My conntrack entries are fu
NTP?
On Mon, Feb 19, 2018 at 12:32 PM, Toralf Förster wrote:
> This happenes here now with that version usually once a day.
>
> Feb 19 18:59:00.000 [warn] Our clock is 1 minutes, 1 seconds behind the time
> published in the consensus network status document (2018-02-19 18:00:00 UTC).
> Tor nee
I have never seen such errors and I'm running on 64 bit gentoo hardened as
well. Are you running with special debug options or something?
On Wed, Oct 29, 2014 at 4:03 PM, Toralf Förster
wrote:
> On 10/28/2014 08:56 PM, Mike Patton wrote:
> > My exit isn't the size of yours but at times has sup
How do you know you are an exit relay?
On Thu, Oct 30, 2014 at 8:30 PM, jchase wrote:
> Hello,
> On hearing the news that tor 0.2.5.10 was available, I upgraded my
> raspberry-pi tor (obfuscated bridge) to 0.2.4.something. The upgrade
> restarted the tor daemon automatically. I would have rathe
If your vps provider is openvz, you are shit out of luck because you
can't set time.
On Fri, Nov 14, 2014 at 4:37 AM, s7r wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Austin,
>
> The clock is very important to Tor, you need accurate clock all the time.
>
> Do you run NTPDATE
r provider has the interest to
> have an accurate time on the host server... so it shouldn't be a
> problem at all - it can be fixed in few seconds.. it's just a
> misconfiguration.
>
> No sane person will refuse to set the correct time on a host server...
>
> On 11/1
Sebastian, how do you distinguish between the usual low level noise of
ssh brute force bots out there from more invasive attacks?
Because this list is most likely just a bunch of internet background noise.
Honestly, the safest thing to do is to NOT USE PASSWORD BASED LOGINS.
But what would be eve
No, this isn't necessary. Just the ports configured in your torrc.
On Sun, Dec 28, 2014 at 5:12 AM, wrote:
> Hello guys,
>
> well I'm new to the tor-project supporting it now by running my first tor
> exit node since 23th Dec'14 :)
> For security purpose I configured iptable and exitpolicy rules
That was my bug report, thanks for the quick turnaround on that one :3
My problem was that my infrastructure, including that tor exit node,
is puppetized. But a problem with that resulted in dhcp blitzing
/etc/resolv.conf and I kept putting in google dns out of sheer muscle
memory and I simply fo
Various public ipv6 dns servers, and yes that one is Google's.
Resolver traffic is split across all the forwarders and I'm caching
everything so I'm OK with it.
On Fri, Jan 9, 2015 at 8:07 AM, Andreas Krey wrote:
> On Thu, 08 Jan 2015 18:20:42 +
ching, etc are all common - and best -
practices.
If there's a practical consideration I am missing, that's different.
On Fri, Jan 9, 2015 at 6:29 PM, Nusenu
wrote:
> hi,
>
> eric gisse:
>> I even threw on a squid proxy on regular http and that's caching
>> so
at 8:12 PM, Drake Wilson wrote:
> eric gisse wrote:
>> Why? People say 'DO NOT MESS WITH TRAFFIC' but in the same breath they
>> say 'BUT USE A CACHING DNS RESOLVER'.
>
> Because the interface level at which exit traffic proper occurs is TCP,
> and the interfa
That's my point. The logic applies to either both or none.
Plus the logic starts to get warped when you wonder "So do you BadExit
every node that runs on an ISP that caches traffic?"
What about ISP's (and openDNS) that NXDOMAIN trap to insert advertising?
Regarding 'cached evidence', logs are sh
assume everyone's ok with that, right? :p
On Sat, Jan 10, 2015 at 4:11 AM, Nusenu
wrote:
>
>
>> On Fri, Jan 9, 2015 at 6:29 PM, Nusenu
>>> Are you saying you are routing exit traffic through a transparent
>>> squid http proxy?
>>>
>>> If that
What an interesting coincidence, tor-specific load is down to about
1/3 of its' normal which is in the 20mb/s range usually.
I was worried my experimentation got me dinged as a badexit but that's
not the case, and otther people are seeing odd things...
On Sun, Jan 11, 2015 at 7:40 AM, ZEROF wro
Interesting tool.
Though you need to make it clear that this tool only runs on Python 2,
not Python 3.
Wouldn't a periodic testing pass for dns within tor make more sense, though?
On Mon, Jan 12, 2015 at 3:31 PM, Dedalo wrote:
> Some months ago I started running another tor relay (middle relay
This is roughly consistent with what I've been seeing on my own node.
Weird.
On Mon, Jan 19, 2015 at 1:31 AM, Bram de Boer wrote:
> Update: generation of the http://nosur.com/consensus.txt list has
> completed now, and contains 3683 relays that exist half a year or more.
> Again the relays at th
Holy crap, 40%? And that's been historically acceptable?
On Tue, Jan 20, 2015 at 5:54 PM, Sebastian Hahn wrote:
>
> On 20 Jan 2015, at 22:58, Roger Dingledine wrote:
>> We've already known about this in the context of "the bandwidth
>> authority scripts are very poorly tuned for the changes that
This is what I do:
My tor exit node runs on its own, but I have a full caching bind
server on a different VM. This services some domains I run, with ACLs
to do regular DNS.
I use the following DNS servers:
2606:4700:4700:: -- Cloudflare
2001:1608:10:25::1c04:b12f -- https://dns.watch/
2600::
26 matches
Mail list logo
