On 11/20/12 5:32 PM, SiNA Rabbani wrote:
> I think nmap is smart enough to adjust the number of packets and delay
> between them automatically.
Yeah but portscanning over Tor with nmap is not the best deal as it does
not have any native socks support and it expect to handle directly
socket operati
I think nmap is smart enough to adjust the number of packets and delay
between them automatically.
On Nov 20, 2012 6:25 AM, "Andreas Krey" wrote:
> On Tue, 20 Nov 2012 14:02:14 +, Fabio Pietrosanti (naif) wrote:
> ...
> > So, rather than "Blocking" it would be really nice to be able to apply
Hi Griffin,
my comments below.
On 11/20/12 3:11 PM, Griffin Boyce wrote:
> Hi Fabio,
>
> To recap the discussion for everyone else, we were talking about
> blocking portscans on exit nodes. While it's possible to block a
> targeted portscan by limiting what ports can be accessed in iptables,
>
On Tue, 20 Nov 2012 14:02:14 +, Fabio Pietrosanti (naif) wrote:
...
> So, rather than "Blocking" it would be really nice to be able to apply
> certain "Rate Limits" to the amount of outgoing, new TCP connection that
> can be done over an established circuit.
>
> Let's say that outgoing circuit
On 11/20/2012 08:02 AM, Fabio Pietrosanti (naif) wrote:
> Hi all,
>
> while discussing on twitter with the guy of http://cryptic.be it about
> "How to block outgoing portscan from a Tor Exit Node" it arise the idea
> that the best way would be to correlate the amount of "outgoing tcp
> connection/t
Hi all,
while discussing on twitter with the guy of http://cryptic.be it about
"How to block outgoing portscan from a Tor Exit Node" it arise the idea
that the best way would be to correlate the amount of "outgoing tcp
connection/time" from a specific "Tor Circuit".
So, rather than "Blocking" it
