Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[Kevin Steen]

On 06/11/13 06:09, Andreas Krey wrote:
> On Tue, 05 Nov 2013 14:09:40 +, Thomas Hand wrote:
> ...
>> Also, use iptables! If it is a dedicated VPS then drop anything you dont
>> recognize,
> 
> What for? The ports that you want to block are rejected by the kernel
> anyway, as there is no one listening. (The minor added protection that
> malware needs to be root to disable iptables and effectively listen -
> is that worth the work?)

Dropping bad requests will reduce your bandwidth usage through not
having to send TCP RST responses, and will also increase the workload of
the attacker as they'll have to wait for a timeout on each connection.

I wouldn't recommend dropping everything, though, as it makes
troubleshooting very difficult - just drop connections to ports which
get attacked.

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

[tor-relays] How to install Tor on Ubunt 12.10?

[The Maker]

I want to run a relay that starts every time I login to my machine. I 
went to the page that discusses how to add the correct PPA to Ubuntu but 
it stops at 11.10. Is this also the PPA I should use for 12.04 or is 
there another one?


Many Thanks,
The Maker

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

Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[mick]

On Wed, 06 Nov 2013 10:30:30 +
Kevin Steen  allegedly wrote:

> On 06/11/13 06:09, Andreas Krey wrote:
> > On Tue, 05 Nov 2013 14:09:40 +, Thomas Hand wrote:
> > ...
> >> Also, use iptables! If it is a dedicated VPS then drop anything
> >> you dont recognize,
> > 
> > What for? The ports that you want to block are rejected by the
> > kernel anyway, as there is no one listening. (The minor added
> > protection that malware needs to be root to disable iptables and
> > effectively listen - is that worth the work?)
> 
> Dropping bad requests will reduce your bandwidth usage through not
> having to send TCP RST responses, and will also increase the workload
> of the attacker as they'll have to wait for a timeout on each
> connection.

It is also good practice to whitelist traffic inbound. The fact that
there is no service currently listening on port "N" does not mean that
there will /never/ be a service listening on port "N". Blocking by
default can protect you from that WTF moment when you find that some
system upgrade or reconfiguration has fired up a service you didn't
expect or thought you had removed.

I've been there. I also believe in belt and braces. 

> I wouldn't recommend dropping everything, though, as it makes
> troubleshooting very difficult - just drop connections to ports which
> get attacked.

I disagree. Dropping all traffic other than that which is explicitly
required is IMHO a better practice. (And how do you know in advance
which ports get attacked?)

Best

Mick
-

 Mick Morgan
 gpg fingerprint: FC23 3338 F664 5E66 876B  72C0 0A1F E60B 5BAD D312
 http://baldric.net

-



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] Traffic in port 9050 in a relay (denial of service attack?)

[mick]

On Tue, 5 Nov 2013 13:39:50 -0800
I  allegedly wrote:

> Ip tables are a mystery to me.
> Can someone either explain them or point to a complete explanation,
> please?
> 
> Robert
>  
> "Also, use iptables! If it is a dedicated VPS then drop anything you
> dont recognize, "leaving only Tor ports (9001,9030 default) and maybe
> a service port like 22 for SSH for "something. Port 9050 should not
> be visible from outside..."

Robert

The linux kernel ships with a default network packet processing
subsystem called netfilter (see http://www.netfilter.org/ for a
description of the system). iptables is the mechanism by which you can
define rules to apply to packet filtering in that system. Most people
use iptables to set up default firewall rulesets allowing inbound
traffic only to certain services and denying all others. 

For example, on a webserver you might wish to allow in only
traffic aimed at ports 80 and, if you are running SSL/TLS, 443.
(Of course if that webserver is running remotely you almost certainly
need to allow in traffic to the ssh port to permit remote
administration). 

This is not strictly on-topic for the tor list so you might care to
spend some time perusing the netfilter web page and its related
resources (FAQs, lists etc). Short term  and if it helps you, I wrote
some recommended iptables configuration scripts a while ago. See
https://baldric.net/2012/09/09/iptables-firewall-for-servers/ 

Note, however, that whilst /I/ believe those configurations to be
safe and useful, I would not recommend that you blindly trust my
scripts without first understanding what they do. Netfilter is
complex, and trusting some unknown third party (me) with your
firewall configuration may not be the best idea in the world. :-)

Best

Mick

-

 Mick Morgan
 gpg fingerprint: FC23 3338 F664 5E66 876B  72C0 0A1F E60B 5BAD D312
 http://baldric.net

-



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] Traffic in port 9050 in a relay (denial of service attack?)

[Lars Noodén]

On 11/06/2013 01:26 PM, mick wrote:
> I disagree. Dropping all traffic other than that which is
> explicitly required is IMHO a better practice. (And how do you know
> in advance which ports get attacked?)

Using reject instead of drop simplifies troubleshooting.

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

Drop tends to get in the way.

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

Re: [tor-relays] How to install Tor on Ubunt 12.10?

[Martin Kepplinger]

The Maker:
> I want to run a relay that starts every time I login to my machine. I
> went to the page that discusses how to add the correct PPA to Ubuntu but
> it stops at 11.10. Is this also the PPA I should use for 12.04 or is
> there another one?
> 
> Many Thanks,
> The Maker
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

I'd really use the repository that the project's website recommends:
https://www.torproject.org/docs/debian.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How to install Tor on Ubunt 12.10?

[Lunar]

The Maker:
> I want to run a relay that starts every time I login to my machine. I
> went to the page that discusses how to add the correct PPA to Ubuntu
> but it stops at 11.10. Is this also the PPA I should use for 12.04 or
> is there another one?

What page are you talking about?

The canonical page mentoin quantal (12.04):


-- 
Lunar 


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

Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[mick]

On Wed, 06 Nov 2013 14:00:09 +0200
Lars Noodén  allegedly wrote:

> On 11/06/2013 01:26 PM, mick wrote:
> > I disagree. Dropping all traffic other than that which is
> > explicitly required is IMHO a better practice. (And how do you know
> > in advance which ports get attacked?)
> 
> Using reject instead of drop simplifies troubleshooting.
> 
> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> 
> Drop tends to get in the way.

Again, I disagree. But I recognise that this can be a religious
decision. My default policy is to drop rather than reject. I know
that strict adherence to standards implies we should “REJECT” with a
helpful ICMP error message. But, doing that can mean that
incoming packets with a spoofed source address can get replies sent
back to that (innocent) source address. DDOS bots exploit this
behaviour. 

I’d rather break standards than help a DDOS bot. :-)

Mick
-

 Mick Morgan
 gpg fingerprint: FC23 3338 F664 5E66 876B  72C0 0A1F E60B 5BAD D312
 http://baldric.net

-



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] Traffic in port 9050 in a relay (denial of service attack?)

[Jeroen Massar]

On 2013-11-06 13:47 , mick wrote:
> On Wed, 06 Nov 2013 14:00:09 +0200
> Lars Noodén  allegedly wrote:
> 
>> On 11/06/2013 01:26 PM, mick wrote:
>>> I disagree. Dropping all traffic other than that which is
>>> explicitly required is IMHO a better practice. (And how do you know
>>> in advance which ports get attacked?)
>>
>> Using reject instead of drop simplifies troubleshooting.
>>
>> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
>>
>> Drop tends to get in the way.
> 
> Again, I disagree. But I recognise that this can be a religious
> decision. My default policy is to drop rather than reject. I know
> that strict adherence to standards implies we should “REJECT” with a
> helpful ICMP error message.

Configure your host with DROP, do an nmap, then configure it with REJECT
thus for Linux:

IPv4: -j REJECT --reject-with icmp-port-unreachable"
IPv6: -j REJECT --reject-with icmp6-port-unreachable"

Now repeat that nmap; indeed, for the DROP it is shown that these ports
are filtered, for REJECT the ports are just 'closed'.

Hence, the adversary did not learn anything in the REJECT case (services
apparently are not there), but in the DROP case they learned that you
have a firewall configured and that those services are likely there...

Hence, not only is reject good for the user (as they do not time out
connecting to the port), but it is also good against adversaries as they
do not learn anything.

As you say it is one of those 'religious' decisions, but in this, the
facts show what should be preferred for multiple reasons ;)

> But, doing that can mean that
> incoming packets with a spoofed source address can get replies sent
> back to that (innocent) source address. DDOS bots exploit this
> behaviour. 

As there is no amplification (only a portion of the incoming packet is
included) this is not used; there are much better sources of attack.

Greets,
 Jeroen

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

Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[mick]

On Wed, 06 Nov 2013 14:00:15 +0100
Jeroen Massar  allegedly wrote:

> On 2013-11-06 13:47 , mick wrote:
> > On Wed, 06 Nov 2013 14:00:09 +0200
> > Lars Noodén  allegedly wrote:
> > 
> >> On 11/06/2013 01:26 PM, mick wrote:
> >>> I disagree. Dropping all traffic other than that which is
> >>> explicitly required is IMHO a better practice. (And how do you
> >>> know in advance which ports get attacked?)
> >>
> >> Using reject instead of drop simplifies troubleshooting.
> >>
> >> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> >>
> >> Drop tends to get in the way.
> > 
> > Again, I disagree. But I recognise that this can be a religious
> > decision. My default policy is to drop rather than reject. I know
> > that strict adherence to standards implies we should “REJECT” with a
> > helpful ICMP error message.
> 
> Configure your host with DROP, do an nmap, then configure it with
> REJECT thus for Linux:
> 
> IPv4: -j REJECT --reject-with icmp-port-unreachable"
> IPv6: -j REJECT --reject-with icmp6-port-unreachable"
> 
> Now repeat that nmap; indeed, for the DROP it is shown that these
> ports are filtered, for REJECT the ports are just 'closed'.
> 
> Hence, the adversary did not learn anything in the REJECT case
> (services apparently are not there), but in the DROP case they
> learned that you have a firewall configured and that those services
> are likely there...

Not true. Since my default is to drop for ALL ports not expicitly open
and receiving traffic, the adversary has learned nothing about what
other services may or may not be there. 

I have no need to say politely to anyone connecting to any random port
on my server, "Sorry, nothing here, you can close your connection". The
only legitimate connections inbound to my server are those for which I
advertise a service.

> 
> As you say it is one of those 'religious' decisions, but in this, the
> facts show what should be preferred for multiple reasons ;)

I also prefer vi to emacs :-)
 
> > But, doing that can mean that
> > incoming packets with a spoofed source address can get replies sent
> > back to that (innocent) source address. DDOS bots exploit this
> > behaviour. 
> 
> As there is no amplification (only a portion of the incoming packet is
> included) this is not used; there are much better sources of attack.
> 

I agree. DNS amplification is much more dangerous and useful to an
adversary. But that does not mean that no adversary will attempt to
use ICMP replies in an attack.

Mick 
-

 Mick Morgan
 gpg fingerprint: FC23 3338 F664 5E66 876B  72C0 0A1F E60B 5BAD D312
 http://baldric.net

-



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 and skype

[Eugen Leitl]

On Tue, Nov 05, 2013 at 09:59:11AM -1000, Ryan Winner wrote:

> Use Google Hangouts.

Which is different from Skype, how?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[Thomas Hand]

I agree with mick that dropping packets is more secure, though probably bad
practice. If everyone did this then, yes, the network would suffer on
average but when securing a vital server, e.g a tor node, i think it is
acceptable.
It really doesnt make it any harder to troubleshoot since any services
running can still respond on those ports you specify. You can always play
with ACK and FIN scans as well if you drop SYNs. I usually drop everything
except 113 IDENT which i reject.

Tom


On 6 November 2013 13:52, mick  wrote:

> On Wed, 06 Nov 2013 14:00:15 +0100
> Jeroen Massar  allegedly wrote:
>
> > On 2013-11-06 13:47 , mick wrote:
> > > On Wed, 06 Nov 2013 14:00:09 +0200
> > > Lars Noodén  allegedly wrote:
> > >
> > >> On 11/06/2013 01:26 PM, mick wrote:
> > >>> I disagree. Dropping all traffic other than that which is
> > >>> explicitly required is IMHO a better practice. (And how do you
> > >>> know in advance which ports get attacked?)
> > >>
> > >> Using reject instead of drop simplifies troubleshooting.
> > >>
> > >> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> > >>
> > >> Drop tends to get in the way.
> > >
> > > Again, I disagree. But I recognise that this can be a religious
> > > decision. My default policy is to drop rather than reject. I know
> > > that strict adherence to standards implies we should “REJECT” with a
> > > helpful ICMP error message.
> >
> > Configure your host with DROP, do an nmap, then configure it with
> > REJECT thus for Linux:
> >
> > IPv4: -j REJECT --reject-with icmp-port-unreachable"
> > IPv6: -j REJECT --reject-with icmp6-port-unreachable"
> >
> > Now repeat that nmap; indeed, for the DROP it is shown that these
> > ports are filtered, for REJECT the ports are just 'closed'.
> >
> > Hence, the adversary did not learn anything in the REJECT case
> > (services apparently are not there), but in the DROP case they
> > learned that you have a firewall configured and that those services
> > are likely there...
>
> Not true. Since my default is to drop for ALL ports not expicitly open
> and receiving traffic, the adversary has learned nothing about what
> other services may or may not be there.
>
> I have no need to say politely to anyone connecting to any random port
> on my server, "Sorry, nothing here, you can close your connection". The
> only legitimate connections inbound to my server are those for which I
> advertise a service.
>
> >
> > As you say it is one of those 'religious' decisions, but in this, the
> > facts show what should be preferred for multiple reasons ;)
>
> I also prefer vi to emacs :-)
>
> > > But, doing that can mean that
> > > incoming packets with a spoofed source address can get replies sent
> > > back to that (innocent) source address. DDOS bots exploit this
> > > behaviour.
> >
> > As there is no amplification (only a portion of the incoming packet is
> > included) this is not used; there are much better sources of attack.
> >
>
> I agree. DNS amplification is much more dangerous and useful to an
> adversary. But that does not mean that no adversary will attempt to
> use ICMP replies in an attack.
>
> Mick
> -
>
>  Mick Morgan
>  gpg fingerprint: FC23 3338 F664 5E66 876B  72C0 0A1F E60B 5BAD D312
>  http://baldric.net
>
> -
>
>
> ___
> 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] exit and skype

[Thomas Hand]

If you want to continue using skype, you could invest in a VPN just to hide
it from your ISP and make microshaft think you are coming from a different,
non-tor related IP.

Tom


On 6 November 2013 15:12, Eugen Leitl  wrote:

> On Tue, Nov 05, 2013 at 09:59:11AM -1000, Ryan Winner wrote:
>
> > Use Google Hangouts.
>
> Which is different from Skype, how?
> ___
> 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] What is iptables?

[I]

Mick! 

Thank you. Iptables is a programme!
I'm off and reading. It appears I need them on my VPSs.

Robert 


>> Ip tables are a mystery to me.
>> Can someone either explain them or point to a complete explanation,
>> please?
>> 
>> Robert
>> 
>> "Also, use iptables! If it is a dedicated VPS then drop anything you
>> dont recognize, "leaving only Tor ports (9001,9030 default) and maybe
>> a service port like 22 for SSH for "something. Port 9050 should not
>> be visible from outside..."
> 
> Robert
> 
> The linux kernel ships with a default network packet processing
> subsystem called netfilter (see http://www.netfilter.org/ for a
> description of the system). iptables is the mechanism by which you can
> define rules to apply to packet filtering in that system. Most people
> use iptables to set up default firewall rulesets allowing inbound
> traffic only to certain services and denying all others.
> 
> For example, on a webserver you might wish to allow in only
> traffic aimed at ports 80 and, if you are running SSL/TLS, 443.
> (Of course if that webserver is running remotely you almost certainly
> need to allow in traffic to the ssh port to permit remote
> administration).
> 
> This is not strictly on-topic for the tor list so you might care to
> spend some time perusing the netfilter web page and its related
> resources (FAQs, lists etc). Short term  and if it helps you, I wrote
> some recommended iptables configuration scripts a while ago. See
> https://baldric.net/2012/09/09/iptables-firewall-for-servers/
> 
> Note, however, that whilst /I/ believe those configurations to be
> safe and useful, I would not recommend that you blindly trust my
> scripts without first understanding what they do. Netfilter is
> complex, and trusting some unknown third party (me) with your
> firewall configuration may not be the best idea in the world. :-)
> 
> Best
> 
> Mick
> 
> -
> 
>  Mick Morgan
>  gpg fingerprint: FC23 3338 F664 5E66 876B  72C0 0A1F E60B 5BAD D312
>  http://baldric.net
> 
> -


GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at 
http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most 
webmails


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

Re: [tor-relays] exit and skype

[gq]

http://www.gnutelephony.org/index.php/GNU_Telephony  ?

On 11/5/2013 2:00 PM, Jan Hendrik den Besten wrote:

... she cannot use Skype anymore to chat with her mum.

I understand Microsoft blocks all tor exits from accessing Skype. Is there
anything I can do except converting the exit into a relay?



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

Re: [tor-relays] exit and skype

[jason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This would be an excellent time for me to suggest using Jitsi
(https://jitsi.org), which is FOSS, cross platform and does encrypted
voip and video. Biggest drawbacks are it's java based and doesn't
support SMP or PSK OTR yet.
- -Jason

On 11/06/2013 11:38 PM, gq wrote:
> 
> http://www.gnutelephony.org/index.php/GNU_Telephony  ?
> 
> On 11/5/2013 2:00 PM, Jan Hendrik den Besten wrote:
>> ... she cannot use Skype anymore to chat with her mum.
>> 
>> I understand Microsoft blocks all tor exits from accessing Skype.
>> Is there anything I can do except converting the exit into a
>> relay?
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSetptAAoJEJJlIjlYdaGY5dcH/3zz7L/bs6QhJuuhviTJXNi2
KZEZEv+0t5L4CmndrKGY4gylDYQ2KVz622rQeCWe+tjMOHlH0qJ8gxqdkS+myZEf
BzQEz8nOPZrFgo5nKmc/7MMXfUfxsMHCgx74vtt+MrRR2Rb/Gc/Qr1xaV0Gdg0tO
9SM0QiDk2oGVP5SPGwlLmzq/L3dks+F3zDHKCq+cVgV3A0qPws1p9igxEvekTdDG
S5O0Wnws79VpgSCGPiPUipA6o4pqttfQ93cO3GjpOxcFsMAXpdhNAIJDa1o4+kEJ
m1ec4tQQ03e1XWxMYO7za+boq4HcUBOWD/mzbEV/3q0VHYXN5iqBqdE4E3Nry+w=
=25lg
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays