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
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.noo...@gmail.com allegedly wrote:
On 11/06/2013 01:26 PM, mick wrote:
I disagree. Dropping all traffic other than that which is
explicitly
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.noo...@gmail.com allegedly wrote:
On 11/06/2013 01:26 PM, mick wrote:
I disagree. Dropping all traffic
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.
On Wed, 06 Nov 2013 10:30:30 +
Kevin Steen k...@kevinsteen.net 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
On 2013-11-06 13:47 , mick wrote:
On Wed, 06 Nov 2013 14:00:09 +0200
Lars Noodén lars.noo...@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
On Wed, 06 Nov 2013 14:00:15 +0100
Jeroen Massar jer...@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.noo...@gmail.com allegedly wrote:
On 11/06/2013 01:26 PM, mick wrote:
I disagree. Dropping all traffic other than
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
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
@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
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
On Tue, 5 Nov 2013 20:10:09 +0100, jj tor jjproye...@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
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
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
@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
15 matches
Mail list logo
