Anyway to do to avoid Brute Force attacks?

You can't avoid Them

You can protect against them using a tool like ConfigServer Firewall and Security
 
Shutdown your server or disconnect the network cable or only use private internet addresses. Everything else with a publicly routable internet address will get BF attacks. Deal with it by using very strong passwords and indeed a tool like csf.
 
Shutdown your server or disconnect the network cable or only use private internet addresses. Everything else with a publicly routable internet address will get BF attacks. Deal with it by using very strong passwords and indeed a tool like csf.
Lol, you made my day, thanks
 
I just want to figure out how DDoS Protection works if the IP is still accessible, and if install and setup SSL will be better, and adding Two-Step Authentication will help with DirectAdmin Login security improvement.

I know to avoid using password and use Key file will make it harder for SSH server login and disable password login, but seems a lot of services running that might have Brute Force attacks

What else do you think it might be helpful?
 
There are a couple of different things you could look into:

- ConfigServer Firewall.
This is a free firewall which you can install on the server if you do not have it already.

- host allow/deny.
This should allow you to block/allow access to different services on the server.

Adding a SSL to the site or server would just encrypt the connection, in concerns to a flood of traffic from multiple IPs I don't believe this would offer anything.

2FA on the panel of course would help if they identified the password unless the panel and your email password are the same.

It really depends on the target of the mentioned attacks. There if it is panel services, the above should definitely help.
 
I am not certain what that may entail. Could you provide more information as to what you mean by a ddos protected ip?
 
Denying login attempts after a couple of failures is the easiest way to setup basic brute force protection.
There are other measures you can take as well:

  • Disallow SSH/DirectAdmin/FTP access from all IP's except your own. I do this.
  • Use two-factor authentication. Won't stop brute force attacks but will stop a successful brute force attack.
 
Disallow SSH/DirectAdmin/FTP access from all IP's except your own. I do this.
Suppose your ip change over night due to network changes, how will you be able to get into your server then?
And you can't block FTP that way unless you don't give your customers FTP acces.
 
Suppose your ip change over night due to network changes, how will you be able to get into your server then?
And you can't block FTP that way unless you don't give your customers FTP acces.

Couple of ways for me.

GLOBAL_ALLOW in CSF is pointing to txt file with my current IP address. LFD grabs it every 30 minutes so I'd only be locked out for 30 minutes max this way.
KVM over IP is available in an emergency.
 
Suppose your ip change over night due to network changes, how will you be able to get into your server then?
And you can't block FTP that way unless you don't give your customers FTP acces.
SSH Portknocking or ssh keys only.
 
SSH keys won't help if your ip does not have access....

Portknocking... interesting. But there are articles advising to not use it. I also use SSH keys.
 
Last edited:
Haha true, but with ssh keys or port knocking, you don't have to whitelist your ip-address. username/passwords attacks are never going to work.

But you can't avoid brute force attacks, you can only make them less likely or impossible to succeed.
 
but with ssh keys or port knocking, you don't have to whitelist your ip-address.
Why not? Suppose I close port 22 as suggested, SSH keys don't bypass the firewall, do they?

But indeed, it's no solution to avoid bruteforces, they will always be there.
 
Why not? Suppose I close port 22 as suggested, SSH keys don't bypass the firewall, do they?

But indeed, it's no solution to avoid bruteforces, they will always be there.
I said 'you don't have to' because you don't have to close the ssh port in the first place.

Besides that I would recommend another port to run ssh on. This 'obscurity' isn't security of course but it's will make you logfiles a lot smaller so it's easier to track real problems.
 
I said 'you don't have to' because you don't have to close the ssh port in the first place.
Yep, but I was talking about what jayw1 was saying. Limit to your ip, but then what if the ip change. SSH keys won't help you then either, how do you get in without any DA, SSH or FTP access. That's a real risk.

By the way... I leave port 22 open just for fun and attack blocking, but my SSH does run on a completely other port with SSH keys enabled. Makes life a lot easier. :)
 
Yep, but I was talking about what jayw1 was saying. Limit to your ip, but then what if the ip change. SSH keys won't help you then either, how do you get in without any DA, SSH or FTP access. That's a real risk.

By the way... I leave port 22 open just for fun and attack blocking, but my SSH does run on a completely other port with SSH keys enabled. Makes life a lot easier. :)
I think solutions differ if you have one server or a lot of servers. We have more than one person's ip whitelisted so if one ip changes, the other can update the edge firewalls :)
 
Back
Top