On Sat, 26 Feb 2011 18:34:48 +0100 Moritz Bartl <moritz@torservers.net> allegedly wrote:

Hi,

On 25.02.2011 17:32, Bianco Veigel wrote:

...

How could I detect such a scan and take counter measures to prevent a network scan through tor?

This is a dangerous route to go. At least I consider exits that filter security scans are "bad" and would want them to be flagged accordingly.

I agree.

...

I've attached the report from the abuse mail. Does anyone have an idea, what steps should/could be taken?

Try to explain to them why network scans are not illegal, and might as well be part of some security researcher activity. Change your hosting provider.

But here I disagree. In many jurisdictions network scans /are/ illegal. No reputable security researcher would a) scan a network without that network owner's explicit permission, nor b) use tor for that scan. Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------

On Sat, 26 Feb 2011 12:13:53 -0800 Chris Palmer <chris@eff.org> allegedly wrote:

On Feb 26, 2011, at 9:53 AM, mick wrote:

...

No reputable security researcher would a) scan a network without that network owner's explicit permission, nor b) use tor for that scan.

Lots of reputable security researchers who scan the entire internet without getting permission. You can't get permission from every operator in the world, but you still need to do good and interesting research. Examples of reputable researchers who have scanned the whole internet include Dan Bernstein, Dan Kaminsky, and EFF. (At least I think we're reputable. :) ) I don't know for sure, but I can't imagine Arbor, CAIDA, and Renesys can do their jobs without scanning the internet.

Using Tor to scan the internet is a good way to see how the internet looks from different perspectives at once, which can be quite valuable.

Hmmm. Maybe I should have said "should" rather than "would". And you seem to have missed the point about network scanning being illegal in some jurisdictions. Section 3 of the UK Computer Misuse Act of 1990, as amended by the Police and Justice Act of 2006 makes such "reckless" activity an offence. I cannot believe I am entirely alone in taking network scanning as potentially hostile activity, or at least as potentially the precursor to hostile activity. UK pen testers and researchers are usually pretty careful to ensure that they have written authority from owners of networks they wish to test before undertaking any remote scanning. Further, they will undertake that scanning from known, identifiable networks of their own. Hiding behind tor (or any other anonymising service) is not a good idea. At the least it could result in tor being seen as the source of hostile activity when we all recognise that is unhelpful. And regardless of the legality of the action, the AUPs of the service providers that most of us use for our tor nodes will specifically preclude network scanning (along with mail spamming etc). This means that providers could (as has been the case for Bianco Veigel) get irritated enough to shut down the service. I run (currently) three exit nodes which I provide on VPSs and pay for out of my own pocket because I believe that tor offers a valuable service. I can (and have) defend what appears to be hostile action emerging from my node as the action of "bad guys" beyond my control. In a particular recent case I was lucky to have an understanding MSP willing to listen to my explanation rather than just pulling the plug. If my exit node was cited as the source of potentially hostile network scanning and my MSP /did/ pull the plug, I'd be disappointed, and tor would be shy of at least one exit node. But if I believed that the activity was the result of some "reputable" researcher simply using tor for his or her own ends /without/ warning tor relay owners, I'd be pretty pissed off. I'd welcome the views of other node providers here. Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------

Thus spake cmeclax-sazri (cmeclax-sazri@ixazon.dynip.com):

Here's my proposal: Add a parameter PortScanLimit to the relays section of torrc. It can be set to any nonnegative integer. If PortScanLimit is n>0, then as soon as a circuit has made n failed attempts to connect, the relay shuts down the circuit. If PortScanLimit is 0, there is no limit on failed attempts to connect. Relay operators in jurisdictions or ISPs that prohibit port scanning can set this to, say, 10, and relay operators not in such jurisdictions who have no qualms about their exit node being used for scanning can set it to 0. This parameter should not be listed in the directory; any client running a port scan will eventually find an exit that allows scanning, if there are any.

This isn't a bad idea on face, but it has some finer points that need a little thought. For instance, what if n connections have failed, but some are still alive? And what if this behavior is triggered by a malicious or broken website with tons of external, broken elements. If the circuit is just forcibly closed, streams that did carry traffic could be cut short.. If the circuit is not closed, the client will wonder why all of their future Tor streams are now failing. Which one do we choose? Is the first really that bad? It seems in this case, the website is already broken, so no one should mind.. But what about other protocols? The other problem is that one could imagine a port scanner or attacker that pre-builds all of the circuits it needs.. Does this mean that this defense is pointless, or will only stopping the script kiddies be enough here? What is the likelyhood that someone will distribute a Tor Controller specifically designed to use tor in an optimal fashion with nmap? This would be the way that this defense gets broken, possibly even unintentionally. Note that we can try to solve this problem in a more general sense: https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-cl... But if a client is only sending RELAY_BEGIN cells, it can still send a lot of them before any of these throttling limits kick in. I would be surprised if this was enough for an effective synflood, but it is enough to portscan. -- Mike Perry Mad Computer Scientist fscked.org evil labs

On Mon, 28 Feb 2011 22:09:56 -0800 Chris Palmer <chris@eff.org> allegedly wrote:

On Feb 27, 2011, at 8:59 AM, mick wrote:

...

in some jurisdictions. Section 3 of the UK Computer Misuse Act of 1990, as amended by the Police and Justice Act of 2006 makes such "reckless" activity an offence.

I'm not sure how it counts as "reckless" to connect to a TCP port and then disconnect.

Chris I used the word "reckless" because that is the wording used in the UK CMA (as amended). See section 3 at: http://www.legislation.gov.uk/ukpga/1990/18/section/3 which says: "Unauthorised acts with intent to impair, or with recklessness as to impairing, operation of computer, etc." I agree that a single full TCP connect does not constitute such "reckless" activity, but an aggressive, rapid, portscan, perhaps using (deliberately) badly formed TCP packets which took no account of the potential impact on the target, might. Some network devices may not handle such traffic well. Indeed, the scan may cause a DOS. IANAL, but it seems to me the drafters of the amendments to the UK legislation may have had such activity in mind when using the term "reckless". The term implies to me a "lack of care or due diligence". I suspect that "intent to impair" may sometimes be difficult to prove so lack of care was added.

The kind of research I'm talking about — us, Kaminsky, Bernstein, et al. — involves simply talking to every server once. For example, the SSL Observatory does a "scan" that is very similar to what happens when a user clicks a link and then immediately clicks the Stop button in the browser: SYN, SYN/ACK, ACK, Client Hello, Server Hello + Certificate, goodbye. We do this once per IP every few months. Out of 4 billion IP addresses, we got one complaint that I know of.

This work is not hostile or dangerous. It is clearly beneficial to the internet community. We've convinced CAs to tighten their loose certification standards, convinced them to meet the EV spec when we found they weren't, and provided hard evidence to fuel substantive debate on PKI policy. Nick and Jake are using the results to improve Tor. That's just to start.

I can't see that sort of activity as being deemed reckless - and it is highly unlikely to be spotted anyway.

It's also worth nothing that the various tricks to hide or evade IDSs that some scanners like Nmap can do, tend not to work over Tor since Tor normalizes TCP streams before exiting.

Port scanning can sometimes be the precursor to hostile activity, but it is not in itself hostile, and it is often either for a good cause or *indistinguishable from normal application activity*.

I disagree. In my view, port scanning in and of itself can be hostile if such activity is aggressive enough to cause difficulties - hence my concern. I am attracted to cmeclax's idea of some form of torrc config option which could limit the potential for deliberate (or accidental but "reckless") scanning. Is there any mileage in pursuing something like that further? And if not, are there any other (current) recommended configurations which could mitigate possible problems? Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------

Thus spake Jacob Appelbaum (jacob@appelbaum.net):

...

I am attracted to cmeclax's idea of some form of torrc config option which could limit the potential for deliberate (or accidental but "reckless") scanning. Is there any mileage in pursuing something like that further? And if not, are there any other (current) recommended configurations which could mitigate possible problems?

I don't think such a configuration option makes any sense at all. We have many streams on a given circuit for load balancing. A clever scanner would simply use one circuit per connect attempt and it would generate a lot of load on the network.

Right. In fact, if you think of this from the perspective of the self-interest of a scanner, I think it is quite likely that most scanners who use Tor already use the Tor Control Port to optimally pre-build as many custom, fast circuits as they can, and then use these either in as optimally parallel configuration as they can, or in as randomized a configuration as they can, depending upon the desire for stealth versus speed. Sophisticated people who use Tor to scan the Internet will likely just laugh at this thread, having defeated these measures already by accident while seeking either speed or stealth independently of them. They will have no problem using their custom Tor Controllers to port scan through your node using multiple circuits in parallel, bypassing the minimal protections provided by this torrc option by accident. I say this because I personally know academic researchers who ethically use Tor to scan the Internet for malware, botnets, and other things. They have written their own Tor Controllers to build custom-chosen circuits optimally for them. Academics typically are considerate about the load they place on the network. They do not do this specifically to cause your node to show up in (laughably absurd) UK court proceedings, or to scan at optimal speed. Black hat scanners will be much less considerate. So it comes down to this question: Are we only really interested in stopping the script kiddies? And can we even stop the script kiddies without opening up vulnerabilities and DoS conditions against regular Tor users that can be exploited at will by malicious websites and even other Tor clients? So far, I think the answer is "no", and we need to look for better solutions. If nation-states and megacorps can't manage to properly implement filtering to avoid these conditions, it seems unlikely that Tor will be able to either. But maybe we just need more tech savvy UK politicians to show us how to protect ourselves. They seem to be doing a great job with technology over there so far.. -- Mike Perry Mad Computer Scientist fscked.org evil labs

Hi On 03.03.2011 11:43, mick wrote:

OK, so that idea may not be a runner - but surely the whole purpose of the exit policy system is to allow us to run exit nodes which /do/ limit activity to that which we deem acceptable (or legal).

Exactly. The *exit policy* is there to limit exit activity. Not iptables or "IDS" afterwards. -- Moritz Bartl https://www.torservers.net/

Hi, On 03.03.2011 12:29, Fabio Pietrosanti (naif) wrote:

Still i would like to point out a *practical* feeling that i got from a lot of person i tried to say "hey, run an exit node!".

I fully accept and understand your point. That's exactly why I started Torservers.net, so you can "run" a Tor exit without having to bother with complaints. That's the "low maintainance Tor exit" you are talking about. :) Centralization IS bad. That's why the purpose of Torservers.net is to also want to encourage other people to follow our example, form organizations etc. We were able to find a pro-bono lawyer, our headquarters are based in his office etc, and bandwidth bought in bulk is much cheaper. Hopefully I can publish some more guides, but a few are already available in our wiki: https://www.torservers.net/wiki/ e.g. the complete server setup we use: https://www.torservers.net/wiki/setup/server

Some person tried to run an exit node, then they got their internet connection disconnected due to high number of claim.

Most people are better of by running a node with a very limited exit policy. I get NO complaints whasoever for the exit that only allows 22, 53 and 443, for example.

That person would be happy to support Freedom of Speech and fight for anti-censorship in support to people living in non-free world. At the same time they don't want to get involved in cyber attacks.

You can show your support for Freedom Of Speech in a lot of ways. Money: Some people feel their purpose in life is to make a lot of dough. Most "full time activists" live off nearly nothing. They NEED you the same way you need them, and will be much better at fighting for the cause than you are. A LOT of people are willing to give up their lifes for some organizations, if only they had some money for their food. Be Public: Spend a couple of bucks on printouts, flyers, whatever. Distribute them. Go out, hold workshops. Write an excellent blog. In general: SHOW your opinion. FIGHT propaganda. Our world is in such a bad shape because people stay quiet, not because too few people run exits. etc etc.

In such condition I DO NOT WANT any traffic to go to italian networks,

Italy has worse problems than someone trying to run an exit. Work on those. Make people understand that looking at half-naked women on government TV isn't something that helps. You can still form an organization that lobbies for Tor, organizes local Tor user groups, coding sessions etc. This is time much better spent than fighting for the right to run some [relatively] small exit. Again, I understand your thoughts. For example, a list of public bittorrent trackers that lead to DMCA complaints would be excellent to have. Unfortunately, we don't have an ISP that allows us to test this. I would begin by using a public tracker list, block all, and gradually unblock trackers until you receive DMCA complaints again. I do not need to block P2P as a whole. I need to block those that are being monitored by the "entertainment" industry, and that can be done using Tor's ExitPolicy. -- Moritz Bartl https://www.torservers.net/

Hi, On 04.03.2011 14:52, tazoi wrote:

After all, in another thread you suggested to "do not run exits in your own country", that could be "do not allow exit for IP addresses in your country".

These are two different things completely. GeoIP does not work. Do not allow all the services around it make you believe it really works as expected. For example, our Gbit/s exit is physically located in the Czech Republic, but uses IPs owned by FDC in the US. GeoIP thus shows USA as location. -- Moritz Bartl https://www.torservers.net/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.03.2011 12:29, schrieb Fabio Pietrosanti (naif):

On 3/3/11 12:13 PM, Moritz Bartl wrote:

...

Hi

On 03.03.2011 11:43, mick wrote:

...

OK, so that idea may not be a runner - but surely the whole purpose of the exit policy system is to allow us to run exit nodes which /do/ limit activity to that which we deem acceptable (or legal).

Exactly. The *exit policy* is there to limit exit activity. Not iptables or "IDS" afterwards.

I know and fully understand your point, it's a controversial issue the filtering or not at exit node level.

The TOR ExitPolicy provide a too reduced degree of flexibility to properly fine tune the risks/exit policy decision of a person just basing on IP/port and with a limitation on how many IP/port can be allowed/filtered.

Still i would like to point out a *practical* feeling that i got from a lot of person i tried to say "hey, run an exit node!".

Some person tried to run an exit node, then they got their internet connection disconnected due to high number of claim. Such person think that if they would be able to remove the claims that cause their internet connection being cutted off, they would be happy to run a server.

Some other person just does not run TOR exit node due to the perceived and concrete risks that their node will be used to start cyber-attacks and that they will have trouble because of this. That person would be happy to support Freedom of Speech and fight for anti-censorship in support to people living in non-free world. At the same time they don't want to get involved in cyber attacks.

Some other person, like me, live in country where the justice and judicial system is in a drammatic situation. In italy if you have legal problem you will take between 5 up to 10 years to solve the issue. In such condition I DO NOT WANT any traffic to go to italian networks, because a stupid and dumb prosecutor would probably raise my home at morning and i will have to manage 5-10 years of legal handling. Unfortunately there's no way to create an exit policy that's able to load the blocking destinated to a specific country (Tor just crash and there's an issue about it due to the high number of ExitPolicy statements).

I think that all those issues are absolutely reasonable and understandable and, if properly managed without a technology-taliban approach, would allow a lot of more person to run exit node.

So still my goal is to test, implement, document and create howto to:

- Block P2P to avoid P2P related claims - Block Portscan to avoid portscan related claims - Block web attacks to avoid web attacks related claims - Block traffic going to the country where i live to avoid stupid prosecutor causing me 5-10 years of legal trouble

Yes, i understand that this is outside the concept of *perfect freedom* related to TOR, but still it would be an answer to the many persons that would be happy to run an Exit Node to support freedom of speech limiting their risks, personal feeling and effort for maintance and running a TOR node.

If that's something not acceptable for the community i accept to be marked as a untrusted node, or rough node or whatever. Being marked as a bad exit means that clients won't choose you for exit connections. So why not save the trouble and run a non-exit-node instead?

According to http://infosecurity.ch/20110124/my-tor-exit-node-experience-trying-to-filter... the node concerned is https://torstatus.blutmagie.de/router_detail.php?FP=a65b8fdc571220dbf80fd409...

Still i think that this approach is reasonable and can create value for the TOR project grow.

-naif http://infosecurity.ch _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJNb4DHAAoJEBINFmKST816kw8QAIBIckmU5sjcFxLgDnAUUnYV 4s++QqtKm/9GsXXiN3qUflouWHpgsJtC0EUZ4oMbs0opV23XqJDVO+OQmon7HNZx b5Hb4b5sdd6AIwFhfIucP7seS5qEEb7b9lveYbsJcORk4SCS1lKdK6vy64M/T422 OK+Do4WKNWpFFwCTBJAQu3oi1wZqobRrMi2D7+anX4vy5/CodXPQSjQlnCiIWfSg TA88buGiotLh6tLKij3d83Ka5rihqo0oPOWNhT+7fQEnwPy85NUMeXs6QPgYW7Gu XwbQFBsuQ3QHaRhFg4xX70j1945c2y2C8SQQLTwYuuqqUgyseZLkySGwvJaNWOK/ 0PdTDPsjXp4MaORuYVZEGdwtZArK8KEUgoZ44uFQKKz5Y65+GBQsQ6c7XjeS3iHw pcmzXheP0/pcUFhg4Vz++x72EUF+yoUFUZxdLR/Bcq9+xT2kfBUAXpQhLQxWF1eB 1GJBaHBAkOdamY1f+bZCUt4UHNN1Ao0ATlUdFbcJrNhSKhl0pjngIUEl6rdGExJE SYSvNRiGVU5kqfqufeTrLIEIq2eZpF9yiti0HL1I041/JjC/JnvW0Jd4gd8NKUYo mufOv7UzBHz3jW2ETKhDylLtS0EZO+25Xg4THBFMtTxDnIUbB9GdWR/JLYFin40I AXlUYxDS3rpXFsQeJRaO =fUwg -----END PGP SIGNATURE-----

On 3/5/11 9:21 AM, Mike Perry wrote:

Thus spake Fabio Pietrosanti (naif) (lists@infosecurity.ch):

...

So still my goal is to test, implement, document and create howto to:

- Block P2P to avoid P2P related claims

Did you try doing this without doing iptables DPI? The Reduced Exit Policy should work fine for this by itself.

DPI killing P2P connections is the least of my worries with your approach, though.. I feel like your node is a minefield of accidental censorship just waiting to explode on innocent users..

You are right that there's a risk of blocking traffic of innocent users. Now it's just some early testing trying to refine the idea, i fully agree that the approach must be as finely tuned and as precise as possible in order just to drop the annoying things while leaving 'everything allowed'. For example to be able to apply a transparent proxy to try to detect bruteforce/web attacks in a effective it's required to patch TOR to be able to bind the TOR Exit IP to a Virtual IP address. Now there's no way to verify what's HTTP traffic on port 80 and what's not, so if you put a transparent proxy in the middle you would break part of the TOR node traffic. Unfortunately i'm not that skilled at c coding, if someone would like to do such a patch it would be cool. Being able to bind to a dedicated IP address for TOR-Exit traffic would allow also a TOR-maintainer to tunnel his Exit Traffic trough a VPN, or even to route different kind of traffic trough different systems with proper IP policy routing.

...

- Block Portscan to avoid portscan related claims

I would be really surprised if this does not end up causing massive collateral damage to just about everything running through your exit node. Please keep a close eye on how often this goes off on killing sprees. I'm going to guess most of the time it will just end up censoring popular sites and dense colo facilities that happen to attract heavy amounts of legit Tor traffic.

Sure, now i tried it for 1 week with very bad results:

From 500k up to 1000k connection blocked per day.

Unfortunately this method is absolutely not good, i disabled it. The issue of detecting and blocking outgoing portscan remain open and till now i am not able to block it with iptables. Question to the list: How to implement some hackish techniques to block outgoing portscan from the exit node? I tried everything with iptables but without success!

...

- Block web attacks to avoid web attacks related claims

I think that Mortiz is right, you're unlikely to stop most of the annoying web shit you get with snort. By complaint volume, it's mostly comment spam. I suppose there are worm probes and such it might catch, but snort seems unlikely to stop very dumb attacks, nor very sophisticated ones.

It does seem likely to censor random docs about computer security, as well as computer security mailinglists. I suppose it depends on which rules you enable, though.

Maybe snort will not be the right tool, but eventually some other approach like using modproxy+modsecurity with a transparent proxy for web attacks and properly finely tuned rules. Detecting brute force, known attack pattern related to SQL injection should be easier. Detecting comment spam sounds a little bit more complex, but it would be also very useful for tor-exit node maintainer. Any idea on which tricks to try to implement comment spamming filters?

...

- Block traffic going to the country where i live to avoid stupid prosecutor causing me 5-10 years of legal trouble

Tor actually does have some slightly more sophisticated machinery already in place to communicate this sort of filtering to clients.. Tor nodes can send "EXITPOLICY" reason codes when they close streams that got created to them despite being forbidden by their exit policy. Clients would then automatically retry on a different circuit.

This would work for your country blocking. It would make Italian sites slower for Tor users who chose your node, but at least it wouldn't effectively censor them.

However, it is not possible to do this EXITPOLICY rejection code once data has already begun flowing on the tcp stream, because at that point it is up to the application to retry, not Tor. In otherwords, this technique won't work for DPI.

I know that the DPI approach it's not clean, but still it's not possible with current TOR to do country black/whitelisting. To properly implement this we would really need to be able to: a) OR load-up ExitPolicy with 3-5k lines b) OR implement some geo-ip logic in the cached-descriptors It will not be in both case a perfect implementation (i have an italian registered netblock configured on a swiss provider in switzerland) but still provide a good level of protection for who can stay in such kind of conditions.

...

Yes, i understand that this is outside the concept of *perfect freedom* related to TOR, but still it would be an answer to the many persons that would be happy to run an Exit Node to support freedom of speech limiting their risks, personal feeling and effort for maintance and running a TOR node.

I think you're right, and we should suport this idea where we can. However, we *must* find ways to do this that are 100% transparent to users. If a user experiences censorship because of this, we're doing it wrong, and such a node should be BadExited.

I think your approaches here are going to lead to situations where users who try to view legitimate content are going to become randomly censored through your node and not understand why. I don't think this is acceptable.

Fully agree. The methods being implemented now are very rough and the most important improvement would come when i'll be able to cleanly transparent proxy the TOR web traffic. For example on the basis of your idea maybe it would be also possible to inject some javascript that connect to ControlPort and issue a NewNym to automatically allow the Client to go trough another node while telling to the client what's happening, or instead of blocking just re-tunnelling the request inside TOR (doubling the latency of such specific circuit/request) ? Again there's no simple idea, i will try to rationalize all such discussion on a Wiki one of those days. It would be fine to try to collect all the consideration (good and bad) related to filtering at TOR exit node.

It might be *barely* acceptable if it didn't happen very often, and when it did, you somehow redirected users to a web page that gave them instructions on how to use the "New Identity" button to avoid your exit.. I doubt this is possible in all cases, and I'm still not sure it's a valid solution.

P.S. Is your contact email correct for the node? Otherwise, as soon as the Tor Exit Scanner notices anything fishy from your node, you will be BadExited without notice.

Sure, everything properly setup, just now i have the node hibernated that should resurrect today (i have a 1TB/month bandwidth with weekly quota configured). Which are the kind of control applied by Tor Exit Scanner? I mean, my node is not doing SSL MITM or stuff like that, the traffic "blocked" is very reduced compared to the amount of traffic that get trough. -naif http://infosecurity.ch

Hi! On Tue, Mar 1, 2011 at 7:09 AM, Chris Palmer <chris@eff.org> wrote:

For example, the SSL Observatory does a "scan" that is very similar to what happens when a user clicks a link and then immediately clicks the Stop button in the browser: SYN, SYN/ACK, ACK, Client Hello, Server Hello + Certificate, goodbye. We do this once per IP every few months. Out of 4 billion IP addresses, we got one complaint that I know of.

Interesting. We were doing the very same thing (opening only 80 and 443 ports to check for certificates) just few weeks ago over whole IP space and got a few complaints: from ATT, usu.edu and usi.com. Maybe the difference was in speed of scanning? We randomized order of scanning but still some networks detected us as scanning their whole ranges. And what is even more interesting is that our ISP was much more eager for us to reply to those complaints than to complaints for us running a Tor exit node some time ago. At that time they didn't even require from us to respond. They just forwarded us e-mails in a FYI manner. Maybe they changed some policies in meantime. Mitar

On Wed, 2 Mar 2011 10:39:44 -0800 Chris Palmer <chris@eff.org> wrote:

On Mar 2, 2011, at 5:04 AM, Mitar wrote:

...

And what is even more interesting is that our ISP was much more eager for us to reply to those complaints than to complaints for us running a Tor exit node some time ago. At that time they didn't even require from us to respond. They just forwarded us e-mails in a FYI manner. Maybe they changed some policies in meantime.

Beats me. I hypothesize that some people think scanning is the same as fuzzing or DoSing or sending actual attack packets or something, because they don't know the difference.

That's probably because 'intrusion detection' tools report network scans as attacks. Unfortunately, an IDS's author has an incentive to continue misrepresenting scans as attacks because if he/she/it does not, his/her/its competitors will advertize the fact that their software detects more types of 'attacks'. Robert Ransom

Hi, On 03.03.2011 07:32, Fabio Pietrosanti (naif) wrote:

i am trying to create a low-responsibility TOR exit node that would allow the node to run without too much issue for the maintainer (few claim from operators).

Sounds interesting.

P2P is out (OpenIPS), traffic to my originating country is out (iptables), i am testing removal of web attacks (trough snort inline) but i am not able to remove outgoing portscan that are now generating at least 1-2 claim per week.

You know that your exit will be chosen based on your ExitPolicy, and not anything you do with iptables? I encourage you to play with different exit policies, but ANYTHING you do after already receiving the packets will hurt the network and should be badexited.

- long-lived tor exit node

What properties does a "long-lived tor exit node" have, other than being up for a long time?

- low-maintenance tor exit node

Run stable Tor. Use a limited Exit Policy. Hire an admin. Donate to Torservers.

- a tor exit node that cannot be used for P2P, Web attacks and Portscan

Tor exit nodes (and the Tor network as a whole) should be seen as an ISP. I would not want my ISP to filter or block anything, especially when I have NO CHANCE but to manually build a new circuit and retry. Like Mike Perry said, it will only make those laugh that run portscans or "web attacks" over Tor. How do you plan on filtering "web attacks"? Let me give you an example: We run the "limited exit policy" on a number of exits [1]. Most of the complaints we are getting for our exits are stupid web spams (forum posts etc) and mail spam sent through webmailers. How are you going to stop them? Suggestion: ExitPolicy reject *:80

- a tor exit node that generate very few claims (that means more resiliency against carrier/hosting disconnecting hte server)

See above.

http://infosecurity.ch :-(

[1] https://www.torservers.net/services.html#servers -- Moritz Bartl https://www.torservers.net/