Is there any kind of compiled list of IPs that relay operators can refer to that are known bad IPs (sources of brute force SSH attempts, etc.)? Is there a reason to NOT block (drop) traffic from these IPs?
Here are some that I have seen recently trying to brute force common user accounts and root password attempts: 198.50.197.98 220.161.148.178 223.4.217.47 199.187.125.250 175.99.95.252 62.64.83.38 125.209.110.234 37.235.53.172
Also, in general what are some good security practices to keep in mind while running a Tor relay?
Thanks, Bryan
I wouldn't think such a database would exist because of the way Tor works.
Regards, Tom McLoughlin
On 02/08/2013 20:18, Bryan Carey wrote:
Is there any kind of compiled list of IPs that relay operators can refer to that are known bad IPs (sources of brute force SSH attempts, etc.)? Is there a reason to NOT block (drop) traffic from these IPs?
Here are some that I have seen recently trying to brute force common user accounts and root password attempts: 198.50.197.98 220.161.148.178 223.4.217.47 199.187.125.250 175.99.95.252 62.64.83.38 125.209.110.234 37.235.53.172
Also, in general what are some good security practices to keep in mind while running a Tor relay?
Thanks, Bryan
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi
Am 02.08.2013 21:18, schrieb Bryan Carey:
Here are some that I have seen recently trying to brute force common user accounts and root password attempts:
I remember this to be a common phenomena for at least 15 years now. Done by millions of (probably zombie) computers around the world. Do you really want to keep track and block each and every of them? That looks to me like a full time job keeping you busy for then next couple of centuries.
It's likely there are already some programs doing this to some extent, but that's a general internet server hardening issue and doesn't have much to do with tor.
Regards Peter
Quoth Bryan Carey:
Is there any kind of compiled list of IPs that relay operators can refer to that are known bad IPs (sources of brute force SSH attempts, etc.)? Is there a reason to NOT block (drop) traffic from these IPs?
Quite possibly I'm being stupid, but wouldn't these IPs just be other relay nodes? Or do you mean they're attempting foul play on your relay (not through your relay)?
Either way, I suspect the same sorts of security measures that sysadmins rely on in other situations apply here; temporarily ip blocking persistent bad actors may help, but tools like fail2ban are probably going to more effective, while having less chance of inadvertantly affecting other users on an IP block.
If you are just talking about regular server hacking attempts, and you are using debian, tben try demyhosts and have it query the demyhosts server every hour or so. It will download a list of known attacking ips On Aug 2, 2013 3:41 PM, "Bryan Carey" z0civic483@gmail.com wrote:
Is there any kind of compiled list of IPs that relay operators can refer to that are known bad IPs (sources of brute force SSH attempts, etc.)? Is there a reason to NOT block (drop) traffic from these IPs?
Here are some that I have seen recently trying to brute force common user accounts and root password attempts: 198.50.197.98 220.161.148.178 223.4.217.47 199.187.125.250 175.99.95.252 62.64.83.38 125.209.110.234 37.235.53.172
Also, in general what are some good security practices to keep in mind while running a Tor relay?
Thanks, Bryan
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/02/2013 03:18 PM, Bryan Carey wrote:
Is there any kind of compiled list of IPs that relay operators can refer to that are known bad IPs (sources of brute force SSH attempts, etc.)? Is there a reason to NOT block (drop) traffic from these IPs?
Here are some that I have seen recently trying to brute force common user accounts and root password attempts: 198.50.197.98 220.161.148.178 223.4.217.47 199.187.125.250 175.99.95.252 62.64.83.38 125.209.110.234 37.235.53.172
To block these types of attempts i disable root access in /etc/ssh/sshd_conf and i run fail2ban with a very strict ruleset for sshd in /etc/fail2ban/jail.conf. Turn the bantime way up and put the retries low like 2-3.
Fail2ban adds abusive ip addresses to the iptables in linux. You can save the rulesets if you like with a cron job.
- --- Marina
Also, in general what are some good security practices to keep in mind while running a Tor relay?
Thanks, Bryan
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Thanks everyone for your input! I already had root access disabled via sshd config. I will look into fail2ban as it sounds like it remedies the problem I'm having.
@Nick - I'm talking about attacks directed at the node, not going through it.
Thanks, Bryan
On Fri, Aug 2, 2013 at 2:04 PM, Marina Brown catskillmarina@gmail.comwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/02/2013 03:18 PM, Bryan Carey wrote:
Is there any kind of compiled list of IPs that relay operators can refer to that are known bad IPs (sources of brute force SSH attempts, etc.)? Is there a reason to NOT block (drop) traffic from these IPs?
Here are some that I have seen recently trying to brute force common user accounts and root password attempts: 198.50.197.98 220.161.148.178 223.4.217.47 199.187.125.250 175.99.95.252 62.64.83.38 125.209.110.234 37.235.53.172
To block these types of attempts i disable root access in /etc/ssh/sshd_conf and i run fail2ban with a very strict ruleset for sshd in /etc/fail2ban/jail.conf. Turn the bantime way up and put the retries low like 2-3.
Fail2ban adds abusive ip addresses to the iptables in linux. You can save the rulesets if you like with a cron job.
- --- Marina
Also, in general what are some good security practices to keep in mind while running a Tor relay?
Thanks, Bryan
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJR/BDXAAoJEEy/Yrjnmw6c4TEP/Rbl1wtepRS5uDIv/OIBzxYS VlkhTbVlgRh9fT2dK7IvHlQH0bTeQkt2sDxx4lWZJ2k157a6V2UDHuo7wZuz6NFq FU4N7tKUIgrfyjJi24O8YKskR3XJyayTnF71fyydWUbLhzMGgGLAePr6YpYtERci xRFfWRPbCx7zmWobR0SWtJdco+8ObsTDB6UDhn0HMPcFq5jc8+QE0j+R5/AOjFib F+r0KbUNscBQ6qqnjr8ufvoEP4Npy+0/tLG0tF1aSR6nQz1bHpf/piyjjns3N4Wt +a50QaXIQqUVNkgNo8KQfCDd6xktKGXtSqoaJJZulQ/37RiUhCZzkSsYZ1qa6PO/ F+k/5CJHScRblV8F5wkBJBeiFYbqMUdhF8aP5dFkHsDLL423HHYANxWfn2+ytT2A zHxd4Z9xxCDc5+X/OvCc/lM/NChDaHgFckY8yDCvoBKXkkts9RHbdnsNYIEJCnnl qcerY9JlFTrXbcDh1QDEkrL3yphTYTFHVb9QBMID+6xOoz2AIiy0ya9P5StoSSmB 3G/PC+DwlMzoVyoEsG7hw53EkZkeHvCnctTubIq3LGqxEgr6wJyRdTd4ONL0joZM mHsZlmE3Dko0ae4yYGcvdl62TPrDKvRT52sNROhSE2K+wv3nWVevKbM9zwmWW+lI xeH9tafItWfW9aI94Kyc =AKRd -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Fri, Aug 02, 2013 at 03:25:10PM -0600, Bryan Carey wrote:
Thanks everyone for your input! I already had root access disabled via sshd config. I will look into fail2ban as it sounds like it remedies the problem I'm having.
I'm confused, what's the actual problem you're having?
Is the problem the log messages from sshd? I just ignore them. Problem solved.
It's fairly odd, on the modern internet, to pretend that an attempt to guess your password is anything to worry about. Think of these attackers as soil bacteria -- if your immune system is so broken that you're vulnerable to such a trivial threat, you have no chance of surviving when a serious threat shows up, and your immediate demise is better for the species as a whole.
-andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/02/2013 05:44 PM, Andy Isaacson wrote:
On Fri, Aug 02, 2013 at 03:25:10PM -0600, Bryan Carey wrote:
Thanks everyone for your input! I already had root access disabled via sshd config. I will look into fail2ban as it sounds like it remedies the problem I'm having.
I'm confused, what's the actual problem you're having?
Is the problem the log messages from sshd? I just ignore them. Problem solved.
It's fairly odd, on the modern internet, to pretend that an attempt to guess your password is anything to worry about. Think of these attackers as soil bacteria -- if your immune system is so broken that you're vulnerable to such a trivial threat, you have no chance of surviving when a serious threat shows up, and your immediate demise is better for the species as a whole.
I also disable password access only leaving ssh key. They can try all they want but fail2ban will block them for a day with my settings. Some resume attacking after ban time is up.
- --- Marina Brown
-andy _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Quoth Bryan Carey:
Thanks everyone for your input! I already had root access disabled via sshd config. I will look into fail2ban as it sounds like it remedies the problem I'm having.
Changing the port sshd runs on has a suprisingly large impact on reducing the number of these attacks, too. Of course it's only security by obscurity, but for the zombie attacks you're describing it's quite effective.
On 3.8.2013 11:17, Nick wrote:
Quoth Bryan Carey:
Thanks everyone for your input! I already had root access disabled via sshd config. I will look into fail2ban as it sounds like it remedies the problem I'm having.
Changing the port sshd runs on has a suprisingly large impact on reducing the number of these attacks, too. Of course it's only security by obscurity, but for the zombie attacks you're describing it's quite effective. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I would also recommend using a key file for SSH authentication and disable password authentication. This way it's pretty much impossible for the attacker to gain access using SSH.
quote from archlinux wiki:
SSH keys serve as a means of identifying yourself to an SSH server usingpublic-key cryptography http://en.wikipedia.org/wiki/Public-key_cryptographyandchallenge-response authentication http://en.wikipedia.org/wiki/Challenge-response_authentication. One immediate advantage this method has over traditional password authentication is that you can be authenticated by the server without ever having to send your password over the network. Anyone eavesdropping on your connection will not be able to intercept and crack your password because it is never actually transmitted. Additionally, using SSH keys for authentication virtually eliminates the risk posed by brute-force password attacks by drastically reducing the chances of the attacker correctly guessing the proper credentials.
As well as offering additional security, SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.
SSH keys are not without their drawbacks and may not be appropriate for all environments, but in many circumstances they can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs. This article assumes you already have a basic understanding of theSecure Shell https://wiki.archlinux.org/index.php/Secure_Shellprotocol and have installed theopenssh https://www.archlinux.org/packages/?name=opensshpackage, available in theOfficial Repositories https://wiki.archlinux.org/index.php/Official_Repositories.
tor-relays@lists.torproject.org
-
Andy Isaacson -
Bryan Carey -
Marina Brown -
Nick -
Peter Guhl -
Richard Budd -
Tom McLoughlin -
Zimeon