[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: How to Run High Capacity Tor Relays (stateless iptables filtering)
- To: tor-relays@xxxxxxxxxxxxxx
- Subject: Re: How to Run High Capacity Tor Relays (stateless iptables filtering)
- From: tor_ml <tor_ml@xxxxxxxxx>
- Date: Fri, 27 Aug 2010 12:26:47 +0200
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: tor-relays-outgoing@xxxxxxxx
- Delivered-to: tor-relays@xxxxxxxxxxxxxx
- Delivery-date: Fri, 27 Aug 2010 06:28:16 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s1024; t=1282904819; bh=jHermxZVCTWRqwJitCKaOe8zRGoIcDUawpt8XBdIPtI=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=pvR6THK02W+MIfKFNH+GolLuDtqBpvzdMvdfKgOjMTxgehJaP9/xXewC7wYTpzWQ3aZv7NA/oSXisGZz0DU3LK5noHSTqCigvVivG+ARhRQpG+4XIFmCQDY5O/vp4YEbrxruAbgkWDO2t6PfxkjInawrrr4ilyAoXUTscknbCtg=
- Reply-to: tor-relays@xxxxxxxxxxxxxx
- Sender: owner-tor-relays@xxxxxxxxxxxxxx
I believe it actually does. There are tons of ssh scanning worms that
probe for ssh ports and try to log into them. Sure, disabling
passwords and/or enforcing strong ones will stop these scans from
succeeding, but they won't stop them if their zombies are repurposed
for an (admittedly unlikely) actual ssh exploit, or if one of the
users decides to upload a weak debian ssh key.
Causing such scans to take 2 days to find my (randomized) ssh port
instead of 2 seconds does makes this machine a harder target to find
by worms and impatient/shotgun attackers. If nothing else, it rids my
logs of a ton of distracting noise, which can make other intrustion
attempts harder to notice.
Ok, I see.
Do you actually see many ssh login attempts (by simple stupid ssh bots)
on randomized ssh ports?
Won't the first rule cause some connection teardown conditions to
just hang though? Causing extra tcp sockets to stay open is less
You are right, on my host (linux) it wouldn't be a problem because it
useses the 4way connection termination where no packet would match the rule:
FIN, ACK ->
but in general there is also another way (or many other ways) to close a
It is also possible to terminate the connection by a 3-way handshake,
when host A sends a FIN and host B replies with a FIN & ACK (merely
combines 2 steps into one) and host A replies with an ACK. This is
perhaps the most common method.
I agree with Olaf and would only use the -p tcp --syn rule to filter new
connection to the server on unwanted ports.