Traffic in port 9050 in a relay (denial of service attack?)
Hello all, I've set up a tor exit relay (0.2.4.17-rc, debian testing) on a VPS, and it's running well (about 20Gbs/day). But a lot of traffic (about 50%!) is using port 9050 for incoming connections. It's something more than random scans. Because I am worried, I've run tcpdump on this port and the packets length is about 50-60 bytes long. It seems like DOS or flood traffic: external ip tries to connect and my server refuses (RST, ACK), each time. My OR port is 9001, and, of course, SocksPort = 0 in my torrc. Do you think something is wrong with my relay? Why that traffic if my only tor port is 9001? Should I block that traffic using iptables?
@jj tor If your torrc literally reads "SocksPort = 0" (no quotes) then the config parser will ignore this and fall back to the default internal setting which is port 9050 wide open. Your torrc needs to read "SocksPort 0" (no quotes) to disable SOCKS connectivity. Best, -- Parity parity.boy@gmail.com
@jj tor ...and before I forget, yes deploy IPtables anyway. :) Best, -- Parity parity.boy@gmail.com
Sorry for the confusión, the exact line in my torrc is "Socksport 0", so, SOCKS port is closed. Moreover, I haven't got any exit rule towards port 9050 Even if I block this traffic using iptables, I am very curious about why the server is receiving that huge amount Maybe, because my relay's exit policy? (exit policy--> doc/ReducedExitPolicy – Tor Bug Tracker & Wiki : https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy) 2013/11/5 Paritesh Boyeyoko <parity.boy@gmail.com>
@jj tor
...and before I forget, yes deploy IPtables anyway. :)
Best,
--
Parity
parity.boy@gmail.com
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
What is the fingerprint of your exit node, maybe someone here can take a look? 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... Tom On 5 November 2013 08:36, jj tor <jjproyects@gmail.com> wrote:
Sorry for the confusión, the exact line in my torrc is "Socksport 0", so, SOCKS port is closed. Moreover, I haven't got any exit rule towards port 9050
Even if I block this traffic using iptables, I am very curious about why the server is receiving that huge amount
Maybe, because my relay's exit policy? (exit policy--> doc/ReducedExitPolicy – Tor Bug Tracker & Wiki : https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy)
2013/11/5 Paritesh Boyeyoko <parity.boy@gmail.com>
@jj tor
...and before I forget, yes deploy IPtables anyway. :)
Best,
--
Parity
parity.boy@gmail.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
On Tue, 5 Nov 2013 13:39:50 -0800 I <beatthebastards@inbox.com> 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 ---------------------------------------------------------------------
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
On Tue, 05 Nov 2013 14:09:40 +0000, 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?) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On 06/11/13 06:09, Andreas Krey wrote:
On Tue, 05 Nov 2013 14:09:40 +0000, 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
On Wed, 06 Nov 2013 10:30:30 +0000 Kevin Steen <ks@kevinsteen.net> allegedly wrote:
On 06/11/13 06:09, Andreas Krey wrote:
On Tue, 05 Nov 2013 14:09:40 +0000, 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 ---------------------------------------------------------------------
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
On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén <lars.nooden@gmail.com> 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 ---------------------------------------------------------------------
On 2013-11-06 13:47 , mick wrote:
On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén <lars.nooden@gmail.com> 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
On Wed, 06 Nov 2013 14:00:15 +0100 Jeroen Massar <jeroen@massar.ch> allegedly wrote:
On 2013-11-06 13:47 , mick wrote:
On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén <lars.nooden@gmail.com> 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 ---------------------------------------------------------------------
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 <mbm@rlogin.net> wrote:
On Wed, 06 Nov 2013 14:00:15 +0100 Jeroen Massar <jeroen@massar.ch> allegedly wrote:
On 2013-11-06 13:47 , mick wrote:
On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén <lars.nooden@gmail.com> 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
On Wed, 2013-11-06 at 14:00 +0100, Jeroen Massar wrote:
On 2013-11-06 13:47 , mick wrote:
On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén <lars.nooden@gmail.com> 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.
I'd agree with the above logic if weren't 4 the f4c1 that OS fingerprinting is done though the analysis of the packets your system sends in replying to scans - the way the kernel generates packet headers tells info on your system. So besides what others have said, I would also add that there is indeed a great difference of info your intruder can get from your system when it generates some kind of answer to random unpredictable requests when compared to no answer at all. So I rather open only those ports to which I gave some love to and am willing to share, than just let my beloved machines to their own fate just to not let the =user= waiting for some seconds. I think the user can wait or close connection if impatient. If his interest on my machine was for just nano secs, I guess we can sidestep this whole gentleman's reply to a connection attempt. Also, I do not get this troubleshooting hassle. If you r the sysadmin u can write in time iptables rules, port scan, packet sniff and single out easily when it is network related or server software related.
On 2013-11-11 19:23, Luther Blissett wrote:
On Wed, 2013-11-06 at 14:00 +0100, Jeroen Massar wrote:
On 2013-11-06 13:47 , mick wrote:
On Wed, 06 Nov 2013 14:00:09 +0200 Lars Noodén <lars.nooden@gmail.com> 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.
I'd agree with the above logic if weren't 4 the f4c1 that OS fingerprinting
I was not talking about OS fingerprinting; completely different beast. While nmap can do that, in this case nmap is just used as an example for service discovery.
is done though the analysis of the packets your system sends in replying to scans - the way the kernel generates packet headers tells info on your system. So besides what others have said, I would also add that there is indeed a great difference of info your intruder can get from your system when it generates some kind of answer to random unpredictable requests when compared to no answer at all.
As a ICMP Port Unreachable is a standard response, there is nothing the attacker will learn 'more' from this. It WILL learn when you DROP that you chose to block that specific port though and thus that there is likely something you are hiding there. If the attacker wants to know your OS it will learn that from the services and packets that you will allow in (and allow answers from). Though if you are paranoid about your OS then you are doing something wrong. Best solution: let a friend pentest your host without telling them what is and what is not there. (hence why the pentesting industry is a happy and well paid place)
So I rather open only those ports to which I gave some love to and am willing to share, than just let my beloved machines to their own fate just to not let the =user= waiting for some seconds. I think the user can wait or close connection if impatient.
If you have 1 user that is fine, if you have a thousand or several hundred thousands of users and they start calling you up, you will be changing that ;) Please note again that DROP/REJECT choice is a personal one. Each has advantages and disadvantages.
If his interest on my machine was for just nano secs, I guess we can sidestep this whole gentleman's reply to a connection attempt.
TCP connections do not time out that quickly. Put a DROP on a port and then try to connect to it using your favorite browser or telnet client. A scanner (nmap et all) will not bother waiting around, real clients will. As such you are hurting real clients, not the scanners; and again you are just telling the scanner you are hiding something.
Also, I do not get this troubleshooting hassle. If you r the sysadmin u can write in time iptables rules, port scan, packet sniff and single out easily when it is network related or server software related.
While *you* will be able to figure it out, the user's perception will be quite different. They connect, it times out. As such, "The network is broken". And that is what they will call you with (and it can indeed be anything). While if they get 'connection refused', it is a much more clear message. PS: Try doing a packet sniff on a link with thousands of connections and where your user cannot tell you what source IP they have; next to the fact that they might just be using the wrong destination host... ;) Greets, Jeroen
On Mon, 2013-11-11 at 19:55 -0500, Jeroen Massar wrote:
PS: Try doing a packet sniff on a link with thousands of connections and where your user cannot tell you what source IP they have; next to the fact that they might just be using the wrong destination host... ;)
Greets, Jeroen
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I guess we can circle down our disagreement here. We are running on different case scenarios... but if I'm not terribly mistaken, I remember Roger said some weeks ago we should not put that many hosts behind one tor relay as it would decrease anonymity. gr33ts
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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.
I agree with the above document, but on really low-end hardware (hi, I'm the resident Raspberry Pi person ;)), and with consumer routers, REJECT can also cause problems during a Tor SYN flood by consuming resources on both the relay and the router. Since I *do* agree with REJECTing when possible, I do a two-stage approach and only DROP hosts which have proven themselves more aggressive than I can deal with during an overload condition. This saves some resources to keep the relay alive. Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSfHf6AAoJED/jpRoe7/ujyfQH/AyCj4Jh0fhOQn3nRFKibofL C0v7cJ3pzbgQCjaeBGwdCz+EDE4/aJaU4MOFAkv+HnMJbGGu9CpgQms+GVpY3P3T H2tmev4vNQ3dLeylRPlSa/fsXUzQxsGOFSnSMc0FD6tNQGVYljKwRGsLtM0olNee GN8GXLuLuYtoq25gF9ElAoUkDkHPHj5/R2f/3R7czY6S3SxkQs+V2rQ/uXb8VLBj eMNCen+kNU5fhi5MhUcixkgd7ovl8599XUnWlgeEuSzjMsWhJHjv0AfmU9eEEtIJ Sr1jY5ihgOp33ImRBr4/fuzndFI9oSTqChL8eg4ikHxsn8odQvdI9w5cflm4s8I= =IMno -----END PGP SIGNATURE-----
On Tue, 2013-11-05 at 09:36 +0100, jj tor wrote:
Sorry for the confusión, the exact line in my torrc is "Socksport 0", so, SOCKS port is closed. Moreover, I haven't got any exit rule towards port 9050
Even if I block this traffic using iptables, I am very curious about why the server is receiving that huge amount
Maybe, because my relay's exit policy? (exit policy--> doc/ReducedExitPolicy – Tor Bug Tracker & Wiki : https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy)
Sorry but I could not understand, which way are you seeing this traffic pass by? The port is open, closed or filtered? If it's from outside and you don't want it to be open, just close the door and filter it with iptables. You can also use iptables to log the traffic and maybe study it?
@jj tor The fact that your relay is refusing connections says that the port isn't open, which is a good thing. I suspect that persons unknown have port scanned your VPS, realised that you have Tor running (on standard ports) and is speculatively using a bot to (hopefully) connect to the SOCKS interface. I would a) move the Tor relay to non-standard ports b) use iptables to drop all incoming connections apart from the (new) Tor ports and shell access. Best, -- Parity parity.boy@gmail.com
Hello again, indeed, the port 9050 is closed, but not filtered. I've set up a drop rule in the VPS firewall( Parallels Plesk Panel) on this port, but it's not working fine. I am amazed by all the amount of this kind of traffic, more than 700 packets/second. According to Kent Backman, this is the clickfraud net called "Rotpoi$on" (a lot of info at https://b.kentbackman.com/2013/04/15/rotpoion-botnet-powered-by-thousands-of -servers/) Maybe I'll be able to block all these incoming connections, but I'm afraid that overall relay performance will decrease drastically because all the filtering work... The relay--> Atlas: newTorThird : https://atlas.torproject.org/#details/ACED456D102F634F8DB3CBE8BC9A96F2569EC3... 2013/11/5 Paritesh Boyeyoko <parity.boy@gmail.com>
@jj tor
The fact that your relay is refusing connections says that the port isn't open, which is a good thing.
I suspect that persons unknown have port scanned your VPS, realised that you have Tor running (on standard ports) and is speculatively using a bot to (hopefully) connect to the SOCKS interface.
I would
a) move the Tor relay to non-standard ports
b) use iptables to drop all incoming connections apart from the (new) Tor ports and shell access.
Best,
--
Parity
parity.boy@gmail.com
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 5 Nov 2013 20:10:09 +0100, jj tor <jjproyects@gmail.com> wrote:
Hello again,
indeed, the port 9050 is closed, but not filtered. I've set up a drop rule in the VPS firewall( Parallels Plesk Panel) on this port, but it's not working fine.
I am amazed by all the amount of this kind of traffic, more than 700 packets/second. According to Kent Backman, this is the clickfraud net called "Rotpoi$on" (a lot of info at https://b.kentbackman.com/2013/04/15/rotpoion-botnet-powered-by-thousands-of -servers/)
Maybe I'll be able to block all these incoming connections, but I'm afraid that overall relay performance will decrease drastically because all the filtering work...
iptables DROP is cheap. Best, -Gordon M.
participants (11)
-
Andreas Krey -
Gordon Morehouse -
I -
Jeroen Massar -
jj tor -
Kevin Steen -
Lars Noodén -
Luther Blissett -
mick -
Paritesh Boyeyoko -
Thomas Hand