Nick thank you for the command actually figured that one out browsing through google i found a few resources that might be helpful to another forum travler looking for solutions to the outlined problems
a few helpfull links i found that should help stopping Bruteforce attacks:
protect against brute force attacks fail2ban
Fail2ban development
Fail2ban Wiki Page doesn't look like there's much written there
that first link has a ton of information on it concerning Iptables Rules and the like.
thanks again Nick for the pointers and i hope the above outlined resources help others with the same and/or similar issues

yum install fail2ban --enablerepo=clearos-epel

I think all of these are very good suggestions. i have used other OS's such as FreePBX that come with Fail2Ban as a base package several other CentOS based distros that include good security practices has anyone written a ClearOS module for Fail2ban? i have no problems with Command-Line-Fu and honestly prefer it to any GUI how ever it is nice to be able to check up on servers and services in a time friendly fashion. after all checks are cheap. i'll continue to dig around and see what i come up with might just have to build a module for ClearOS myself for Fail2Ban

fail2ban is probably a better tool to block these attacks. Note often I get attacks from a rotating set of IP's with a single IP generally not used more than once in a day and I don't even have the port open. In this case fail2ban and snort are useless.

Clear don't maintain their ruleset for free. All you get is a basic open source set of rules. You may be better looking at Emerging Threats and incorporating some of their rules..

Almost a year later, and ClearOS doesn't include this by default? ive upgraded to the Beta release 6.6.0 (beta 2) and for about the last 3 months have been undergoing an SSH login attack from Hangzhou China (122.225.103.78) and Hong Kong (103.41.124.43)
at one point in my log files the Attack was detected and stopped:

Dec 13 19:13:34 demo sshd[10323]: reverse mapping checking getaddrinfo for 198.50.174.61.dial.wz.zj.dynamic.163data.com.cn [61.174.50.198] failed - POSSIBLE BREAK-IN ATTEMPT!

however after noticing several network slowdowns and bandwidth spikes i noticed more rouge packets flooding my network from the above listed addresses. being a fairly decent python scripter i decided to see if i could force the Intrusion Detection/Prevention System to block ip addresses so this morning i set up a multi-threaded python script to attempt an SSH login automatically from another Linux box on my network. RESULTS? no ban and the login attempts are still running from my test platform several hours later attempting of up to 60 logins a minute.
with the growing security failures in todays age of technologies i think this should be included as a configurable parameter in the ClearOS Web interface. I will sit down configure the above rules provided by Nick and Peter. Also Tim thats a good answer for securing an SSH server, but that only keeps the honest people out the above listed IPs have been black listed on several anti hacking databases and is a genuine threat to security not some employee that forgot there password and is logging in several times and failing. i think a good addition to the SSH module for ClearOS should include the ssh-keygen as this has to be done on the command line.
some suggestions for possible improvements to the already solid OS

The block time takes various different units and, I think, can take days or d as well. Refer to the manual for snortsam.

Thanks! Nick, that was exactly what I was missing. The block works great, though I changed the 24h to seconds since all the other block rules are that way.

Tony, that is also helpful, though I use other security systems that log the attempts.

If you know the external address(s) that are going to be used then you can use /etc/hosts.allow to restrict access.
eg

#

# hosts.allow   This file describes the names of the hosts which are

#               allowed to use the local INET services, as decided

#               by the '/usr/sbin/tcpd' server.

#





sshd:         202.135.

sshd:         220.239.35.

sshd:         58.172.180.36

You can even get an email when an attempt is made to access - and blocked - buy using /etc/hosts.deny

#

# hosts.deny    This file describes the names of the hosts which are

#               *not* allowed to use the local INET services, as decided

#               by the '/usr/sbin/tcpd' server.

#

# The portmap line is redundant, but it is left to remind you that

# the new secure portmap uses hosts.deny and hosts.allow.  In particular

# you should know that NFS uses portmap!



ALL: ALL : spawn (echo Attempt from %h %a %n to %d at `date` | tee -a /var/log/tcp.deny.log | mail -s "Unauthorised Access Attempt"%h your_username@your.ip.address)

This assumes your mail is set-up correctly and the mailx rpm installed

The email content is typically
Attempt from host210-43-static.61-88-b.business.telecomitalia.it 88.61.43.210 host210-43-static.61-88-b.business.telecomitalia.it to sshd at Sat Jan 25 23:46:06 EST 2014

or if unable to resolve the address

Attempt from 95.43.105.132 95.43.105.132 unknown to sshd at Sat Jan 25 22:40:27 EST 2014

If you need it open, you might consider moving it to another non standard port and also using SSH keys

You may want to look at adding a block element to the rule, perhaps by adding a:

fwsam: src, 24 hours;

for a 24h block to the end of it. I can't otherwise comment on the rule as I am not very familiar with them. You could look at the snort documentation on line. It is very detailed.