Re: [tor-relays] FreeBSD pkg repo configuration

[nusenu]

>> is the package 'ca_root_nss' installed?
>>
>> does installing it solve the problem?


> I wanted to updated the TorRelayGuide/FreeBSD wiki page, 

ca_root_nss package added:
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?action=diff&version=7

> I suppose it is not editable by anyone, is that correct?

some pages are edit-restricted, this is one of them


-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Possible problem with NYX

[teor]

> On 5 Sep 2018, at 02:36, Damian Johnson  wrote:
> 
> Nyx's 'should this be scrubbed' check is pretty simple [1].
> Inbound addresses are scrubbed if...
> 
> 1. You're configured to accept user traffic (ie. you set BridgeRelay
> in your torrc or have receive the Guard flag). [2]

There are so many edge cases for this check.

Flags are a *recommendation* to clients. They don't force clients
to behave a certain way.

For example:
* clients connecting via bridges can use a middle node as their
  second hop. These middle nodes will leak bridge addresses via nyx.
* clients and relays can have different consensuses:
  * if a relay loses the Guard flag, and finds out earlier than its clients,
nyx will stop protecting those clients
  * if a client finds out before the relay, nyx won't protect those clients
* some Tor client versions don't check the guard flag at all. Others
  keep their guards, even if they lose the flag
* middle and exit relays can be used as bridges, even if they don't set
  BridgeRelay
* older Tor versions have a non-zero probability of choosing any relay
  as an entry, even if it doesn't have the guard flag
* various config options make tor clients ignore the Guard flag

Please only show an IP if the relay is already public in the consensus.

> 2. The connection doesn't belong to a another tor relay. [3]

> [1] https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n230
> [2] https://gitweb.torproject.org/stem.git/tree/stem/control.py
> [3] In particular, we check if the address/port is in the consensus.

You could also check if the connection is authenticated to a public relay.
But the IP check works in most cases, and if it fails, it's ok to keep more
info private.

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] FreeBSD pkg repo configuration

[Santiago R.R.]

El 04/09/18 a las 17:51, nusenu escribió:
…
> > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> > Authority X3
> > 34405378632:error:14090086:SSL 
> > routines:ssl3_get_server_certificate:certificate verify 
> > failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> > Authority X3
> > 34405378632:error:14090086:SSL 
> > routines:ssl3_get_server_certificate:certificate verify 
> > failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> > Authority X3
> > 34405378632:error:14090086:SSL 
> > routines:ssl3_get_server_certificate:certificate verify 
> > failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> > pkg: https://pkg.FreeBSD.org/FreeBSD:11:amd64/latest/meta.txz: 
> > Authentication error
> > repository FreeBSDlatest has no meta file, using default settings
> > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> > Authority X3
> > 34405378632:error:14090086:SSL 
> > routines:ssl3_get_server_certificate:certificate verify 
> > failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> > Authority X3
> > 34405378632:error:14090086:SSL 
> > routines:ssl3_get_server_certificate:certificate verify 
> > failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> > Authority X3
> > 34405378632:error:14090086:SSL 
> > routines:ssl3_get_server_certificate:certificate verify 
> > failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> > pkg: https://pkg.FreeBSD.org/FreeBSD:11:amd64/latest/packagesite.txz: 
> > Authentication error
> > Unable to update repository FreeBSDlatest
> > Error updating repositories!
> > 
> 
> 
> is the package 'ca_root_nss' installed?
> 
> does installing it solve the problem?

Yes, thanks!

I wanted to updated the TorRelayGuide/FreeBSD wiki page, but it didn't
find how. I suppose it is not editable by anyone, is that correct?


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit friendly ISPs in Australia

[Sydney]

> On 5 Sep 2018, at 12:30 pm, Isaac Grover, Aileron I.T. 
>  wrote:
> 
> Good evening,
>  
> Following up with a tongue-in-cheek suggestion to set up exit nodes in 
> Australia, for those who are interested, there are already seven exit nodes 
> in Australia per https://hackertarget.com/tor-exit-node-visualization/ . 
> 

I run 3 exits in Australia, my main relay fingerprint is 
262E84A99F53AE1F6860267F7C5DA5B96E57A46D. They’re all nicknamed govtis. Two are 
in Sydney and one is in Adelaide. 

I haven’t had any issues running these relays. 

I’m also unconcerned about the potential Access Bill passing into law. There’s 
going to be a general election before it’s even debated in both houses, and we 
may have an entirely new government by that time. ___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Exit friendly ISPs in Australia

[Isaac Grover, Aileron I.T.]

Good evening,

Following up with a tongue-in-cheek suggestion to set up exit nodes in 
Australia, for those who are interested, there are already seven exit nodes in 
Australia per https://hackertarget.com/tor-exit-node-visualization/ .

I have also contacted RIMU Hosting, which has servers in Australia, and they 
said "As an account holder under our terms of use, you would be directly 
responsible for all content in and out of your server. In general that is not 
possible to do with a tor exist node, so we are not a good fit for that use 
case."

Make your day great,
Isaac Grover, Senior I.T. Consultant
Aileron I.T. - "Practical & Proactive I.T. Solutions"

O: 715-377-0440, F:715-690-1029, W: 
www.aileronit.com

LinkedIn: https://www.linkedin.com/in/IsaacGrover/
YouTube: https://www.youtube.com/channel/UCqrwZNFKdR-guKtuQzFPObQ

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[Mirimir]

On 09/04/2018 03:19 AM, Paul Templeton wrote:
> 
> On a satire note -
> 
> https://www.youtube.com/watch?v=eW-OMR-iWOE
> 
> But seriously - 
> https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bill-2018
> And -
> https://www.homeaffairs.gov.au/about/national-security/five-country-ministerial-2018
> 
> The thing that worries me is that this bill will probably go through and it 
> can hoover up relay operators. That is they can force you to add/develop 
> tools to eavesdrop on you.
> 
> Is there any real defense against this bill? IE having a parameter in the 
> torrc that would act like a canary? 

Sure. Run relays in Australia (and other oppressive places) using strong
pseudonyms. Lease by the month, if possible. If targeted, nuke the relay
and the pseudonym, and create a new relay. Repeat as needed.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Nathaniel Suchy]

> Using an obscure port only prevents attempts being logged, nothing else.
And if you’re going to use an alternate port, pick one under 1024. Make it
so an attacker needs to be root before they replace your sshd process.
If you take that approach, make sure you are using a hardware firewall
blocking inbound connections to ports above 1024.

Also SSH Keys, password auth disabled is enough - you don't even need to
change your SSH port :D

On Tue, Sep 4, 2018 at 8:44 AM Sean Brown  wrote:

> On Sep 4, 2018, at 8:40 AM, Natus  wrote:
> >
> >> Use some tool like fail2ban and/or ssh key authentication.
> >
> > Also change the default port of your ssh endpoint (eg: )
> >
> >
>
>
> Using an obscure port only prevents attempts being logged, nothing else.
> And if you’re going to use an alternate port, pick one under 1024. Make it
> so an attacker needs to be root before they replace your sshd process.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[Roger Dingledine]

On Tue, Sep 04, 2018 at 10:19:45AM +, Paul Templeton wrote:
> The thing that worries me is that this bill will probably go through and it 
> can hoover up relay operators. That is they can force you to add/develop 
> tools to eavesdrop on you.
> 
> Is there any real defense against this bill? IE having a parameter in the 
> torrc that would act like a canary? 

I don't believe they can actually force you to do these things, in this
hypothetical future. You will always have the alternative of deciding
to stop running your relay.

If you are faced with this choice, you should stop running the relay --
and then find some lawyers to get advice on how best to get the word out.

Tor's strength is in its distributed nature: a single relay operator
isn't in the same centralized position as, say, Lavabit was.

These proposed laws are still scary, though, first because they promote
broad insecurity (making civilization weaker at a time where attackers
already have the advantage in so many ways), and second because if they
get enough momentum in enough different places, our strategy will need
to shift from "route around that terrible country with its stupid law"
to some more pervasive design changes to handle the new attacks.

For those wanting more thoughts on this area, check out the discussion
at https://blog.torproject.org/calea-2-and-tor
(spoiler alert, it's basically the same broken record from 2013)

--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Lets increase Routing Security for Tor related BGP Prefixes

[Paul Templeton]

OVH response so far.

"

Thank you for contacting OVH regarding your concern about BGP hijacking.

We first would like to apologize for the delayed response! We are experiencing 
an unusual amount of requests at this moment. This is why the response time is 
longer than usual.

That being said, I have forwarded this question to our specialists and will 
update this ticket once I've received a response.

We thank you for your patience.


For any other questions or concerns, please feel free to contact us through a 
support ticket or through our toll-free line at 1-855-684-5463. We’re here 24/7 
to help you!

We thank you again for choosing OVH,
"

Paul
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Suspension of service (ISP Scaleway / tor exit)

[Nathaniel Suchy]

For DoS traffic, it'd be nice to have some agreed upon rate limit rules of
obvious syn flood and similar traffic which both stop the attacks, or slow
them down so they don't affect anything and cause complaints, while still
allowing legitimate traffic to flow as normal. Scaleway knows about Tor,
but they are also operating out of France and have stricter legal
requirements to follow - it's understandable they want a rapid response to
any complaints.

My advice for dealing with future complaints...
1) Respond explaining the traffic is coming from the Tor network and you
can't stop entirely but you can stop the traffic from coming from your exit.
2) Block outgoing traffic to the affected IP with your exit policy, if it's
an attack directed towards a website I'd go through DNS Records and block
all related IP Addresses. Perhaps the affected /24 or /16, better safe than
losing out on 100Mbps so of bandwidth or from the Tor network :)
3) BE FAST: Scaleway isn't playing games anymore when it comes to managing
abuse. They're allowing Tor Exits, but only if you are very fast about
managing abuse. If you get to the point where they say next complaint and
they suspend your service - stop running an exit node and operate in relay
only mode. Exit bandwidth is important, BUT, unique guards controlled by a
variety of people are still necessary. It's something to consider if you've
damaged your relationship with Scaleway beyond repair.
4) Maybe only allow DNS, HTTP, and HTTPS ports. That's less port choice for
sending out a syn flood and makes you less likely to get a complaint.

Cordially,
Nathaniel

On Tue, Sep 4, 2018 at 5:00 PM Paul  wrote:

> I made the same experience as you several times in the last few weeks with
> Scaleway.
>
> Usually you have 48 hours to respond - that's at least what they tell you
> somewhere on their pages.
>
> My impression is that you can place anything you want in your answer -
> important is your answer within time.
>
> If it happens to often within a short period they seem to get nervous and
> want to get rid of you (to protect their reputation as they say)
>
> Next time they shut my relay forever they promised :-)
>
> I would doubt that they know anything about tor, or do not care?
>
> Paul
>
> p.s. bad that they offer uncomparable speed/price relation
>
>
> Am 04.09.2018 um 22:27 schrieb Olaf Grimm:
> > Dear readers,
> >
> > some days ago I change my relay to an exit relay with a very strict
> > policy. Today came the suspension message into my regular mail account.
> > After login into the Scaleway account I saw that the time between the
> > abuse log message and the deactivation of my exit relay were 6 hours
> > only. At these time I was at work! I was not able to react of the
> > message, neither I knew it.
> >
> > The "abuse message" was a raw firewall log, without spaces hard to read.
> > I'm not a professional, so I could read only "SYNFLOOD src IP  dest
> > IP ". That's all.
> > After I learnt what this is, I responded to the provider that good
> > providers realize own DDOS protection in the network and protect
> > customers too. Why log the provider bad outgoing traffic and ignore bad
> > incoming traffic? They don't know the source of the bad traffic, but
> > have the customer to beat someone!
> > The answer field for the reply were some lines only. Without comment
> > from the ISP the ticket was closed and the VPS locked yet.
> > I try to delete the old instance and build a new one. If the same occur
> > I leave Scaleway (and give info about that again).
> >
> > Now I recommend to set the ISP Scaleway (in France) of the list of bad
> > providers.
> >
> > Scaleway message:
> >
> > Hello,
> >
> > We have tried to contact you about an abuse report concerning one of
> your server. Unfortunately at this time you did not reply to this report.
> As stated in our terms of service, we have suspended your account.
> >
> > Sincerly,
> > Scaleway
> >
> > End message
> >
> >
> > To avoid a big shitstorm: I know what I do and it is not my first and
> only exit. Scaleway was the first trouble and in such a way, that I must
> leave a comment.
> >
> > To the tor website editors:
> > It is possible to include a basic abuse protection chapter in the tor
> documentation (config guide)? I've found some iptable rules, but I use the
> user-friedly "ufw", the overlay to iptables.
> > It would be fine if some good guys could help with an easy configuration
> guide in the config chapter for tor relays.
> >
> > Have a good time. I feel me better.
> >
> > Olaf
> >
> >
> >
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays ma

Re: [tor-relays] Suspension of service (ISP Scaleway / tor exit)

[Paul]

I made the same experience as you several times in the last few weeks with 
Scaleway.

Usually you have 48 hours to respond - that's at least what they tell you 
somewhere on their pages.

My impression is that you can place anything you want in your answer - 
important is your answer within time.

If it happens to often within a short period they seem to get nervous and want 
to get rid of you (to protect their reputation as they say)

Next time they shut my relay forever they promised :-)

I would doubt that they know anything about tor, or do not care?

Paul

p.s. bad that they offer uncomparable speed/price relation


Am 04.09.2018 um 22:27 schrieb Olaf Grimm:
> Dear readers,
> 
> some days ago I change my relay to an exit relay with a very strict
> policy. Today came the suspension message into my regular mail account.
> After login into the Scaleway account I saw that the time between the
> abuse log message and the deactivation of my exit relay were 6 hours
> only. At these time I was at work! I was not able to react of the
> message, neither I knew it.
> 
> The "abuse message" was a raw firewall log, without spaces hard to read.
> I'm not a professional, so I could read only "SYNFLOOD src IP  dest
> IP ". That's all.
> After I learnt what this is, I responded to the provider that good
> providers realize own DDOS protection in the network and protect
> customers too. Why log the provider bad outgoing traffic and ignore bad
> incoming traffic? They don't know the source of the bad traffic, but
> have the customer to beat someone!
> The answer field for the reply were some lines only. Without comment
> from the ISP the ticket was closed and the VPS locked yet.
> I try to delete the old instance and build a new one. If the same occur
> I leave Scaleway (and give info about that again).
> 
> Now I recommend to set the ISP Scaleway (in France) of the list of bad
> providers.
> 
> Scaleway message:
> 
> Hello,
> 
> We have tried to contact you about an abuse report concerning one of your 
> server. Unfortunately at this time you did not reply to this report. As 
> stated in our terms of service, we have suspended your account.
> 
> Sincerly,
> Scaleway
> 
> End message
> 
> 
> To avoid a big shitstorm: I know what I do and it is not my first and only 
> exit. Scaleway was the first trouble and in such a way, that I must leave a 
> comment.
> 
> To the tor website editors:
> It is possible to include a basic abuse protection chapter in the tor 
> documentation (config guide)? I've found some iptable rules, but I use the 
> user-friedly "ufw", the overlay to iptables.
> It would be fine if some good guys could help with an easy configuration 
> guide in the config chapter for tor relays.
> 
> Have a good time. I feel me better.
> 
> Olaf
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Suspension of service (ISP Scaleway / tor exit)

[Nathaniel Suchy]

I run a "browser-only" exit relay at Scaleway, by "browser-only" I mean
only ports 53 (DNS), 80 (HTTP), 443 (HTTPS) and so far it's gone well.
Their support recommends if you run "an open proxy" to check your abuse
inbox daily (See: https://cloud.scaleway.com/#/abuses) as they will suspend
after 48 hours without a response. Still someone could try to send a syn
flood on those ports. Is there any guidance on dropping outgoing syn floods
with netfilter/iptables?

Cordially,
Nathaniel

On Tue, Sep 4, 2018 at 4:30 PM Volker Mink  wrote:

> Had the same experience with Scaleway a year ago.
>
> > Am 04.09.2018 um 22:27 schrieb Olaf Grimm :
> >
> > Dear readers,
> >
> > some days ago I change my relay to an exit relay with a very strict
> > policy. Today came the suspension message into my regular mail account.
> > After login into the Scaleway account I saw that the time between the
> > abuse log message and the deactivation of my exit relay were 6 hours
> > only. At these time I was at work! I was not able to react of the
> > message, neither I knew it.
> >
> > The "abuse message" was a raw firewall log, without spaces hard to read.
> > I'm not a professional, so I could read only "SYNFLOOD src IP  dest
> > IP ". That's all.
> > After I learnt what this is, I responded to the provider that good
> > providers realize own DDOS protection in the network and protect
> > customers too. Why log the provider bad outgoing traffic and ignore bad
> > incoming traffic? They don't know the source of the bad traffic, but
> > have the customer to beat someone!
> > The answer field for the reply were some lines only. Without comment
> > from the ISP the ticket was closed and the VPS locked yet.
> > I try to delete the old instance and build a new one. If the same occur
> > I leave Scaleway (and give info about that again).
> >
> > Now I recommend to set the ISP Scaleway (in France) of the list of bad
> > providers.
> >
> > Scaleway message:
> >
> > Hello,
> >
> > We have tried to contact you about an abuse report concerning one of
> your server. Unfortunately at this time you did not reply to this report.
> As stated in our terms of service, we have suspended your account.
> >
> > Sincerly,
> > Scaleway
> >
> > End message
> >
> >
> > To avoid a big shitstorm: I know what I do and it is not my first and
> only exit. Scaleway was the first trouble and in such a way, that I must
> leave a comment.
> >
> > To the tor website editors:
> > It is possible to include a basic abuse protection chapter in the tor
> documentation (config guide)? I've found some iptable rules, but I use the
> user-friedly "ufw", the overlay to iptables.
> > It would be fine if some good guys could help with an easy configuration
> guide in the config chapter for tor relays.
> >
> > Have a good time. I feel me better.
> >
> > Olaf
> >
> >
> >
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Suspension of service (ISP Scaleway / tor exit)

[Volker Mink]

Had the same experience with Scaleway a year ago.

> Am 04.09.2018 um 22:27 schrieb Olaf Grimm :
> 
> Dear readers,
> 
> some days ago I change my relay to an exit relay with a very strict
> policy. Today came the suspension message into my regular mail account.
> After login into the Scaleway account I saw that the time between the
> abuse log message and the deactivation of my exit relay were 6 hours
> only. At these time I was at work! I was not able to react of the
> message, neither I knew it.
> 
> The "abuse message" was a raw firewall log, without spaces hard to read.
> I'm not a professional, so I could read only "SYNFLOOD src IP  dest
> IP ". That's all.
> After I learnt what this is, I responded to the provider that good
> providers realize own DDOS protection in the network and protect
> customers too. Why log the provider bad outgoing traffic and ignore bad
> incoming traffic? They don't know the source of the bad traffic, but
> have the customer to beat someone!
> The answer field for the reply were some lines only. Without comment
> from the ISP the ticket was closed and the VPS locked yet.
> I try to delete the old instance and build a new one. If the same occur
> I leave Scaleway (and give info about that again).
> 
> Now I recommend to set the ISP Scaleway (in France) of the list of bad
> providers.
> 
> Scaleway message:
> 
> Hello,
> 
> We have tried to contact you about an abuse report concerning one of your 
> server. Unfortunately at this time you did not reply to this report. As 
> stated in our terms of service, we have suspended your account.
> 
> Sincerly,
> Scaleway
> 
> End message
> 
> 
> To avoid a big shitstorm: I know what I do and it is not my first and only 
> exit. Scaleway was the first trouble and in such a way, that I must leave a 
> comment.
> 
> To the tor website editors:
> It is possible to include a basic abuse protection chapter in the tor 
> documentation (config guide)? I've found some iptable rules, but I use the 
> user-friedly "ufw", the overlay to iptables.
> It would be fine if some good guys could help with an easy configuration 
> guide in the config chapter for tor relays.
> 
> Have a good time. I feel me better.
> 
> Olaf
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Suspension of service (ISP Scaleway / tor exit)

[Olaf Grimm]

Dear readers,

some days ago I change my relay to an exit relay with a very strict
policy. Today came the suspension message into my regular mail account.
After login into the Scaleway account I saw that the time between the
abuse log message and the deactivation of my exit relay were 6 hours
only. At these time I was at work! I was not able to react of the
message, neither I knew it.

The "abuse message" was a raw firewall log, without spaces hard to read.
I'm not a professional, so I could read only "SYNFLOOD src IP  dest
IP ". That's all.
After I learnt what this is, I responded to the provider that good
providers realize own DDOS protection in the network and protect
customers too. Why log the provider bad outgoing traffic and ignore bad
incoming traffic? They don't know the source of the bad traffic, but
have the customer to beat someone!
The answer field for the reply were some lines only. Without comment
from the ISP the ticket was closed and the VPS locked yet.
I try to delete the old instance and build a new one. If the same occur
I leave Scaleway (and give info about that again).

Now I recommend to set the ISP Scaleway (in France) of the list of bad
providers.

Scaleway message:

Hello,

We have tried to contact you about an abuse report concerning one of your 
server. Unfortunately at this time you did not reply to this report. As stated 
in our terms of service, we have suspended your account.

Sincerly,
Scaleway

End message


To avoid a big shitstorm: I know what I do and it is not my first and only 
exit. Scaleway was the first trouble and in such a way, that I must leave a 
comment.

To the tor website editors:
It is possible to include a basic abuse protection chapter in the tor 
documentation (config guide)? I've found some iptable rules, but I use the 
user-friedly "ufw", the overlay to iptables.
It would be fine if some good guys could help with an easy configuration guide 
in the config chapter for tor relays.

Have a good time. I feel me better.

Olaf



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Possible problem with NYX

[arisbe]

Thanks for this added info--it helps.


On 9/4/2018 9:36 AM, Damian Johnson wrote:

Hi arisbe. This isn't as concerning as you seem to think. As Nathaniel
mentions it's simple to get this information, Nyx is simply attempting
to scrub it cuz... well, it's ethically and legally the right thing to
do. Nyx's 'should this be scrubbed' check is pretty simple [1].
Inbound addresses are scrubbed if...

1. You're configured to accept user traffic (ie. you set BridgeRelay
in your torrc or have receive the Guard flag). [2]
2. The connection doesn't belong to a another tor relay. [3]

Does the relay show relay information such as a fingerprint? If so
then it shouldn't be scrubbed. If it doesn't and you've set
BridgeRelay in your torrc then please let us know on...

https://trac.torproject.org/projects/tor/wiki/doc/nyx/bugs

Thanks! -Damian (author of nyx and stem)

[1] https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n230
[2] https://gitweb.torproject.org/stem.git/tree/stem/control.py
[3] In particular, we check if the address/port is in the consensus.


On Mon, Sep 3, 2018 at 1:13 PM, arisbe  wrote:

Hello ops,

Today I noticed something on NYX that I find disturbing.  Page 2 (list of
inbound/outbound connections) showed me the IP address of an inbound
connection on one of my bridges!  Not the authority. This is crazy as these
are indicated as :port for the users protection!  I have never
seen this before and haven't seen it since.  Of course, on low usage
bridges, the connection IP address can possibly be disseminated from netstat
but that's not the point.  It's my sense that this should never happen.  I
get chills imagining this happening on a guard relay operated by an
antagonist ! !

I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor
0.3.3.9.

Arisbe

--
One person's moral compass is another person's face in the dirt.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
One person's moral compass is another person's face in the dirt.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[arisbe]

Hello Marcus,

On an ongoing basis, most of my relays get up to 4000 attempts each 
day.  It's standard practice I guess!  Many, many are from just a few IP 
addresses.  The rest are just a few per IP address. Occasionally, I will 
go beyond the fail2ban "ban" and block an IP address in iptables  via 
ufw.  I then unblock that IP address in a week or two.  I set fail2ban 
for long blocks maybe up to 12 hours (43000-seconds).


So, harden your operating system as best you can.  SSH works but disable 
the password entry, X11, etc. if possible.  This is always safe if your 
provider has a dashboard for you to use as a secondary access to the 
server.  I change my SSH port number but that only slows the 
professionals my minutes or seconds.  Remember to change the fail2ban 
SSH port number if you do that.  Your host provider should have DDoS 
protection for his/her entire plant.


And don't sweat it!  Learn from the experiences.


On 9/4/2018 5:35 AM, Marcus Wahle wrote:

Dear all,

Since 14:00 my logs (middle node) are spamed with around 100 faild ssh login 
attemps from different ips.
Is there anybody else affected?

Best regards
Marcus
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
One person's moral compass is another person's face in the dirt.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Multi node management programs/platforms?

[arisbe]

  
  
For me, 8.


On 9/3/2018 8:42 PM, I wrote:


  
  
   How many relays do you do that to?
  
  


  
  
  
  
  ___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



-- 
One person's moral compass is another person's face in the dirt.
  

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Roman Mamedov]

On Tue, 4 Sep 2018 18:44:55 +0100
 wrote:

> Waste of time move SSH port?  My fail2ban has hardly anything to do since 
> moving port some time back

Yes, it is. And you might as well remove fail2ban altogether if you simply have
key-based auth and disable passwords.

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[gerard]

Waste of time move SSH port?  My fail2ban has hardly anything to do since 
moving port some time back. Very rarely does it see any attempts on my new odd 
number SSH port, but on port 22 the attacks were continuous.   I agree in terms 
of security for a determined hacker moving port does nothing.

Gerry
-Original Message-
From: tor-relays  On Behalf Of Michael 
Brodhead
Sent: 04 September 2018 18:36
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] SSH login attempts

FWIW I found sshguard easier to deal with on FreeBSD than fail2ban.

Turn off password logins and take good care of your ssh keys. Moving sshd to a 
different port is a waste of time but harmless if you’re the only administrator.

—mkb  


> On Sep 4, 2018, at 5:35 AM, Marcus Wahle  wrote:
> 
> Dear all,
> 
> Since 14:00 my logs (middle node) are spamed with around 100 faild ssh login 
> attemps from different ips.
> Is there anybody else affected?
> 
> Best regards 
> Marcus
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] FreeBSD pkg repo configuration

[nusenu]

>> http replaced with https
>> https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_email=&sfph_mail=&action=diff&version=6&old_version=5
> 
> Trying that, but I am currently getting this:
> 
>  % sudo pkg update
> Updating FreeBSDlatest repository catalogue...
> pkg: Repository FreeBSDlatest load error: access repo 
> file(/var/db/pkg/repo-FreeBSDlatest.sqlite) failed: No such file or directory

this line is expected when running 'pkg update' for the first time after 
creating the new config file 
(that sqlite file will be created automatically)

> Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> Authority X3
> 34405378632:error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify 
> failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> Authority X3
> 34405378632:error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify 
> failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> Authority X3
> 34405378632:error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify 
> failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> pkg: https://pkg.FreeBSD.org/FreeBSD:11:amd64/latest/meta.txz: Authentication 
> error
> repository FreeBSDlatest has no meta file, using default settings
> Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> Authority X3
> 34405378632:error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify 
> failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> Authority X3
> 34405378632:error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify 
> failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
> Authority X3
> 34405378632:error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify 
> failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
> pkg: https://pkg.FreeBSD.org/FreeBSD:11:amd64/latest/packagesite.txz: 
> Authentication error
> Unable to update repository FreeBSDlatest
> Error updating repositories!
> 


is the package 'ca_root_nss' installed?

does installing it solve the problem?

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Michael Brodhead]

FWIW I found sshguard easier to deal with on FreeBSD than fail2ban.

Turn off password logins and take good care of your ssh keys. Moving sshd to a 
different port is a waste of time but harmless if you’re the only administrator.

—mkb  


> On Sep 4, 2018, at 5:35 AM, Marcus Wahle  wrote:
> 
> Dear all,
> 
> Since 14:00 my logs (middle node) are spamed with around 100 faild ssh login 
> attemps from different ips.
> Is there anybody else affected?
> 
> Best regards 
> Marcus
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Congrats to Nullvoid

[Santiago R.R.]

El 04/09/18 a las 17:12, nusenu escribió:
> 
> 
> Paul:
> > 
> > For me running several FreeBSD relays this is a great hint!
> > 
> > Maybe it will find its way to
> > https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD
> > 
> 
> http replaced with https
> https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_email=&sfph_mail=&action=diff&version=6&old_version=5

Trying that, but I am currently getting this:

 % sudo pkg update
Updating FreeBSDlatest repository catalogue...
pkg: Repository FreeBSDlatest load error: access repo 
file(/var/db/pkg/repo-FreeBSDlatest.sqlite) failed: No such file or directory
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
34405378632:error:14090086:SSL routines:ssl3_get_server_certificate:certificate 
verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
34405378632:error:14090086:SSL routines:ssl3_get_server_certificate:certificate 
verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
34405378632:error:14090086:SSL routines:ssl3_get_server_certificate:certificate 
verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
pkg: https://pkg.FreeBSD.org/FreeBSD:11:amd64/latest/meta.txz: Authentication 
error
repository FreeBSDlatest has no meta file, using default settings
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
34405378632:error:14090086:SSL routines:ssl3_get_server_certificate:certificate 
verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
34405378632:error:14090086:SSL routines:ssl3_get_server_certificate:certificate 
verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
34405378632:error:14090086:SSL routines:ssl3_get_server_certificate:certificate 
verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
pkg: https://pkg.FreeBSD.org/FreeBSD:11:amd64/latest/packagesite.txz: 
Authentication error
Unable to update repository FreeBSDlatest
Error updating repositories!

Is there something missing I am missing?

 -- Santiago


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Multi node management programs/platforms?

[Michael Brodhead]

My relay VMs are provisioned with Terraform. Once the VMs are up, Terraform 
copies over a shell script which installs and configures everything. Relay 
keys, configs, etc live on a separate volume so that relays keep the same 
identities even when I rebuild the VMs from scratch. I can destroy all the VMs 
and the automation will bring them back up with the same fingerprints. 

To make working on the config easier, the shell script is idempotent so I can 
re-run it on an existing VM without reprovisioning. 

—mkb

> On Sep 3, 2018, at 7:11 PM, Isaac Grover, Aileron I.T.  > wrote:
> 
> Good evening, 
> 
> For those of you who manage multiple exits and/or relays, what 
> program/platform do you use to manage them? 
> 
> Make your day great,
> Isaac Grover, Senior I.T. Consultant
> Aileron I.T. - "Practical & Proactive I.T. Solutions"
> 
> Office: 715-377-0440, Fax:715-690-1029, Web: www.aileronit.com 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Congrats to Nullvoid

[nusenu]

Paul:
> 
> For me running several FreeBSD relays this is a great hint!
> 
> Maybe it will find its way to
> https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD
> 

http replaced with https
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_email=&sfph_mail=&action=diff&version=6&old_version=5

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Possible problem with NYX

[Damian Johnson]

Hi arisbe. This isn't as concerning as you seem to think. As Nathaniel
mentions it's simple to get this information, Nyx is simply attempting
to scrub it cuz... well, it's ethically and legally the right thing to
do. Nyx's 'should this be scrubbed' check is pretty simple [1].
Inbound addresses are scrubbed if...

1. You're configured to accept user traffic (ie. you set BridgeRelay
in your torrc or have receive the Guard flag). [2]
2. The connection doesn't belong to a another tor relay. [3]

Does the relay show relay information such as a fingerprint? If so
then it shouldn't be scrubbed. If it doesn't and you've set
BridgeRelay in your torrc then please let us know on...

https://trac.torproject.org/projects/tor/wiki/doc/nyx/bugs

Thanks! -Damian (author of nyx and stem)

[1] https://gitweb.torproject.org/nyx.git/tree/nyx/panel/connection.py#n230
[2] https://gitweb.torproject.org/stem.git/tree/stem/control.py
[3] In particular, we check if the address/port is in the consensus.


On Mon, Sep 3, 2018 at 1:13 PM, arisbe  wrote:
> Hello ops,
>
> Today I noticed something on NYX that I find disturbing.  Page 2 (list of
> inbound/outbound connections) showed me the IP address of an inbound
> connection on one of my bridges!  Not the authority. This is crazy as these
> are indicated as :port for the users protection!  I have never
> seen this before and haven't seen it since.  Of course, on low usage
> bridges, the connection IP address can possibly be disseminated from netstat
> but that's not the point.  It's my sense that this should never happen.  I
> get chills imagining this happening on a guard relay operated by an
> antagonist ! !
>
> I'm using the default NYX configuration on Ubuntu server 18.04.1 LTS, Tor
> 0.3.3.9.
>
> Arisbe
>
> --
> One person's moral compass is another person's face in the dirt.
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Congrats to Nullvoid

[Paul]

For me running several FreeBSD relays this is a great hint!

Maybe it will find its way to
https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD


> Not a problem with FreeBSD.
> 
> Switch over to https and latest...
> 
> /etc/pkg/FreeBSD.conf:
> 
>   url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest";,
> 
> and run 'pkg upgrade' .
> 

Could you please explain a bit more on this - what exactly to do ?

> If it's a shared box, you probably also want
> devcpu-data,  and optionally cpupdate.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Multi node management programs/platforms?

[Manager]

  
  
Hello,
  
  i'm using ansible to do that.
  
  ps:
  
  https://bitbucket.org/urykhy/ansible-roles/src/master/tor/
  (yes, there is lot of hardcode, it's really example, not solution)
  
  
  04.09.2018 05:11, Isaac Grover, Aileron I.T. пишет:


  
  Good evening, 
  
  
  For those of you who manage multiple exits and/or relays,
what program/platform do you use to manage them? 
  
  
  
Make your day great,
  Isaac Grover, Senior I.T. Consultant
  Aileron I.T. - "Practical & Proactive I.T. Solutions"
  
  Office: 715-377-0440, Fax:715-690-1029, Web: www.aileronit.com
  
  
  
  
  ___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




  

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Multi node management programs/platforms?

[Manager]

  
  
Hello,
  
  i'm using ansible to do that.
  
  ps:
  
  https://bitbucket.org/urykhy/ansible-roles/src/master/tor/
  (yes, there is lot of hardcode, it's really example, not solution)
  
  
  04.09.2018 05:11, Isaac Grover, Aileron I.T. пишет:


  
  Good evening, 
  
  
  For those of you who manage multiple exits and/or relays,
what program/platform do you use to manage them? 
  
  
  
Make your day great,
  Isaac Grover, Senior I.T. Consultant
  Aileron I.T. - "Practical & Proactive I.T. Solutions"
  
  Office: 715-377-0440, Fax:715-690-1029, Web: www.aileronit.com
  
  
  
  
  ___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




  

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[Gary]

Hi,

I am unfamiliar with the nuances of Australian law however I do wonder the
following:

On Tue, 4 Sep 2018 at 14:01, teor  wrote:

>
> The law specifically allows payments by the government.
>

Lets speculate and say there is a relay operator who runs their relay in
their spare time, and the Australian Government want to force this person
to spend time and rig their relay and turn it "bad", sucking up all sorts
of data as it goes through.

The real test would be if they could ask this person to quit their full
time job in order to complete this (for any) task. Sure they might get
'compensation' (pay) of some sort, perhaps hardware - but if they feel they
are being asked to do too much its unlikely they will be able to appeal -
and even if they can appeal it is likely it would be done in secret.

A member of the Australian Government is known for saying "the laws of
mathematics are great - Australian laws are better" (referring to back
doors in encryption), perhaps under these new laws they can force a person
to work more than 24 hours a day lol.

Thanks.

On Tue, 4 Sep 2018 at 14:01, teor  wrote:

>
> On 4 Sep 2018, at 21:57, Gary  wrote:
>
>
> On Tue, 4 Sep 2018, 11:20 Paul Templeton,  wrote:
>
>> But seriously -
>>
>> https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bill-2018
>> And -
>>
>> https://www.homeaffairs.gov.au/about/national-security/five-country-ministerial-2018
>>
>> The thing that worries me is that this bill will probably go through and
>> it can hoover up relay operators. That is they can force you to add/develop
>> tools to eavesdrop on you.
>>
>
> I remember reading about this a while ago. I don't have the links to the
> articles on the device I am using however they mentioned three things:
>
> 1). The organisation would need the skills and resources to bake in back
> doors (e.g. knowledgeable people).
>
>
> Good point.
>
> Although most relay operators can set up packet dumps and debug logging.
>
> 2). Free speech - Can you make a programmer code (speak) something they do
> not want to say.
>
>
> There is no general right to free speech under Australia law.
> As far as I'm aware, there are no precedents that treat code as speech,
> either.
>
> 3). Assuming someone is willing to help - it may take one person years to
> do as they have been asked, so during that time are they employed by the
> government? Do they get assistance (e.g. mentoring or hardware) to do the
> task?
>
>
> The law specifically allows payments by the government.
>
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] 9 routing security recommendations for relay operators

[nusenu]

(mostly a copy paste from [0])

1. Monitor your relay’s BGP prefix for suspicious BGP activity and share alerts 
with 
this mailing list.
The easiest way to do so is to subscribe to your prefixes using 
https://bgpmon.net/.
You should practically get zero alerts.

2. Check the following properties of the prefixes you use (ideally even before 
ordering servers):

prefix length and IRR state [1]
RPKI state [2] 

3. Ask your ISP/IP holder to create ROAs [4] for the prefixes you use, if the 
ROA is currently missing.

4. Ensure the ROA creator is aware of the risks of the maxlength attribute [3] 
and uses it accordingly (in the best case not at all)

5. Monitor the RPKI validity state of your prefixes (can also be done with 
bgpmon)

6. Ask your ISP to announce the IP space of your relays in /24 prefixes (/48 
for IPv6) 
to avoid more-specific prefix hijacks (this makes sense even if you have ROAs 
in place due to the low ROV coverage)

7. If your relay uses IP addresses from the RIPE region: 
ask your provider to create route(6) objects matching the announcements if they 
are not present yet. 
You can use RIPEstat’s prefix routing consistency widget [1] to check the 
current state
 (the “In RIS” and “RIPE IRR” columns should both say “yes”).

8. Be aware that “LEGACY” or “ERX” IP space might be less likely to get ROAs by 
your ISP

9. Enable IPv6 on your relays


[0] 
https://medium.com/@nusenu/how-vulnerable-is-the-tor-network-to-bgp-hijacking-attacks-56d3b2ebfd92
[1] https://stat.ripe.net/widget/prefix-routing-consistency
[2] https://rpki-validator.ripe.net/bgp-preview
[3] https://www.youtube.com/watch?v=I3Owb0u8Wuk
[4] 
https://www.ripe.net/manage-ips-and-asns/resource-management/certification/resource-certification-roa-management
https://www.arin.net/resources/rpki/using_rpki.html

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Sean Brown]

> On Sep 4, 2018, at 9:06 AM, Ralph Seichter  wrote:
> 
> On 04.09.2018 14:44, Sean Brown wrote:
> 
>> Using an obscure port only prevents attempts being logged, nothing
>> else.
> 
> I cannot agree with that. What an sshd logs is not determined by the
> port number it is listening on, and the quantity of failed login
> attempts across my servers is measurably lower when using a non-standard
> port.
> 

Ya, my mistake, I wasn’t clear. I don’t mean that sshd doesn’t log if it’s on a 
different port, I mean that only the worst bots won’t find it, cutting down on 
the amount of noise in the logs. If ssh is configured correctly (disable 
password, 2fa, keys etc.) password attempts are just noise.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Ralph Seichter]

On 04.09.2018 14:44, Sean Brown wrote:

> Using an obscure port only prevents attempts being logged, nothing
> else.

I cannot agree with that. What an sshd logs is not determined by the
port number it is listening on, and the quantity of failed login
attempts across my servers is measurably lower when using a non-standard
port.

-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[teor]

> On 4 Sep 2018, at 21:57, Gary  wrote:
> 
>> On Tue, 4 Sep 2018, 11:20 Paul Templeton,  wrote:
>> But seriously - 
>> https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bill-2018
>> And -
>> https://www.homeaffairs.gov.au/about/national-security/five-country-ministerial-2018
>> 
>> The thing that worries me is that this bill will probably go through and it 
>> can hoover up relay operators. That is they can force you to add/develop 
>> tools to eavesdrop on you.
> 
> 
> I remember reading about this a while ago. I don't have the links to the 
> articles on the device I am using however they mentioned three things:
> 
> 1). The organisation would need the skills and resources to bake in back 
> doors (e.g. knowledgeable people).

Good point.

Although most relay operators can set up packet dumps and debug logging.

> 2). Free speech - Can you make a programmer code (speak) something they do 
> not want to say. 

There is no general right to free speech under Australia law.
As far as I'm aware, there are no precedents that treat code as speech, either.

> 3). Assuming someone is willing to help - it may take one person years to do 
> as they have been asked, so during that time are they employed by the 
> government? Do they get assistance (e.g. mentoring or hardware) to do the 
> task?

The law specifically allows payments by the government.

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Lars Noodén]

On 09/04/2018 03:41 PM, Marcus wrote:
> Thanks Paul,
> I use fai2ban, but this amount of failed logins is new to me.
> Marcus

The failed logins are business as usual.  If the machine is on the net,
then bots will find it no matter where it is or which port it listens
on.  But they usually move on after a while, too.

While running fail2ban/sshguard helps, and changing the port helps
slightly, the biggest change you can make if you haven't done it already
is to use key-based authentication and turn off password based
authentication, at least for the outward facing address(es) on your box.
 It seems that many bots can tell when the SSH daemon will not respond
to passwords and move on without trying to actually log in.

/Lars
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Sean Brown]

On Sep 4, 2018, at 8:40 AM, Natus  wrote:
> 
>> Use some tool like fail2ban and/or ssh key authentication.
> 
> Also change the default port of your ssh endpoint (eg: )
> 
> 


Using an obscure port only prevents attempts being logged, nothing else. And if 
you’re going to use an alternate port, pick one under 1024. Make it so an 
attacker needs to be root before they replace your sshd process.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[nusenu]

Marcus Wahle:
> Since 14:00 my logs (middle node) are spamed with around 100 faild
> ssh login attemps from different ips. Is there anybody else
> affected?

I'd say that is business as usual and not much to worry about if you use strong 
authentication

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Marcus]

Thanks Paul,
I use fai2ban, but this amount of failed logins is new to me.
Marcus

--
Mein öffentliches Zertifikat finden Sie unter: 
https://web.tresorit.com/l#tDLNPX-QlTRTcpMEqRRSng
Am 04.09.2018 um 14:38 schrieb Paul Templeton :

>> Since 14:00 my logs (middle node) are spamed with around 100 faild
>> ssh login attemps from different ips.
>> Is there anybody else affected?
> Yes - it's constant 3-5 attempts per second - that's normal.
> Use some tool like fail2ban and/or ssh key authentication.
> 
> Paul
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[I]

 ssh key authentication.

and an obscure port




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Natus]

> Use some tool like fail2ban and/or ssh key authentication.

Also change the default port of your ssh endpoint (eg: )

-- 
regards, natus
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH login attempts

[Paul Templeton]

> Since 14:00 my logs (middle node) are spamed with around 100 faild
> ssh login attemps from different ips.
> Is there anybody else affected?
Yes - it's constant 3-5 attempts per second - that's normal.
Use some tool like fail2ban and/or ssh key authentication.

Paul
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] SSH login attempts

[Marcus Wahle]

Dear all,

Since 14:00 my logs (middle node) are spamed with around 100 faild ssh login 
attemps from different ips.
Is there anybody else affected?

Best regards 
Marcus
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[Nathaniel Suchy]

I live in the United States so they’d need to pass an act here for it to be
enforced, which would be constitutionally challenged with every last legal
measure available. Have you seen the legal shitstorm with social networks
censoring conservatives, can you imagine them hearing the government is
making people say things they disagree with?

Additionally I will sooner delete my relay keys and such down than ceed
control to the Australian government.

Cordially,
Nathaniel

On Tue, Sep 4, 2018 at 7:58 AM Gary  wrote:

> Hello,
>
> On Tue, 4 Sep 2018, 11:20 Paul Templeton,  wrote:
>
>> But seriously -
>>
>> https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bill-2018
>> And -
>>
>> https://www.homeaffairs.gov.au/about/national-security/five-country-ministerial-2018
>>
>> The thing that worries me is that this bill will probably go through and
>> it can hoover up relay operators. That is they can force you to add/develop
>> tools to eavesdrop on you.
>>
>
> I remember reading about this a while ago. I don't have the links to the
> articles on the device I am using however they mentioned three things:
>
> 1). The organisation would need the skills and resources to bake in back
> doors (e.g. knowledgeable people).
>
> 2). Free speech - Can you make a programmer code (speak) something they do
> not want to say.
>
> 3). Assuming someone is willing to help - it may take one person years to
> do as they have been asked, so during that time are they employed by the
> government? Do they get assistance (e.g. mentoring or hardware) to do the
> task?
>
> As you can see it would be difficult to implement I think.
>
> Thanks
>
>> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[Gary]

Hello,

On Tue, 4 Sep 2018, 11:20 Paul Templeton,  wrote:

> But seriously -
>
> https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bill-2018
> And -
>
> https://www.homeaffairs.gov.au/about/national-security/five-country-ministerial-2018
>
> The thing that worries me is that this bill will probably go through and
> it can hoover up relay operators. That is they can force you to add/develop
> tools to eavesdrop on you.
>

I remember reading about this a while ago. I don't have the links to the
articles on the device I am using however they mentioned three things:

1). The organisation would need the skills and resources to bake in back
doors (e.g. knowledgeable people).

2). Free speech - Can you make a programmer code (speak) something they do
not want to say.

3). Assuming someone is willing to help - it may take one person years to
do as they have been asked, so during that time are they employed by the
government? Do they get assistance (e.g. mentoring or hardware) to do the
task?

As you can see it would be difficult to implement I think.

Thanks

>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[Paul Templeton]

> Before getting into a death-spiral of geek solutions to political problems: 
> what makes you believe that 
> relay operators would get classed (under a legal definition) as 
> "communications providers"? 

A communications provider is "the provision by the person of an electronic 
service that has one or more end - users in Australia" 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] The Assistance and Access Bill 2018

[Alec Muffett]

On Tue, 4 Sep 2018 at 11:20, Paul Templeton  wrote:

>
> The thing that worries me is that this bill will probably go through and
> it can hoover up relay operators. That is they can force you to add/develop
> tools to eavesdrop on you.
>

Before getting into a death-spiral of geek solutions to political problems:
what makes you believe that relay operators would get classed (under a
legal definition) as "communications providers"?

Or, possibly, that may be off-topic for this list, in which case please
reply to tor-talk@

-a


-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] The Assistance and Access Bill 2018

[Paul Templeton]

On a satire note -

https://www.youtube.com/watch?v=eW-OMR-iWOE

But seriously - 
https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bill-2018
And -
https://www.homeaffairs.gov.au/about/national-security/five-country-ministerial-2018

The thing that worries me is that this bill will probably go through and it can 
hoover up relay operators. That is they can force you to add/develop tools to 
eavesdrop on you.

Is there any real defense against this bill? IE having a parameter in the torrc 
that would act like a canary? 

Paul


137CF322859E400455E457DB920F65FFDD222CDF

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Multi node management programs/platforms?

[I]

> what maintenance actions do you take? I merely keep the operating system
> up to date, which includes the tor package.
> So i do not ssh regularly into my machines. Sometimes maybe once a week.
> What are you guys doing every day?

If they're cheap VPSs, as mine are, the nongs who run them keep stopping them 
or doing something which affects them..

Rob


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] relayor v18.1.0 is released

[nusenu]

Hi,

relayor v18.1.0 is released.

relayor helps you with running relays with minimal effort (automate everything).

https://github.com/nusenu/ansible-relayor


Changes since v18.0.0:
--

 - enable NoExec by default on all platforms except CentOS
 - increase min. ansible version from 2.5.3 to v2.6.2
 - fix the ExitPolicy format in the example playbook
 - change default shipped exit policy (remove POP3, IMAP and kerberos ports)
 - change the ControlSocket location



-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays