# How to deny attackers



## rhinestone89 (Jul 3, 2010)

I really don't know where to put this subject that's why I posted it on the firewall section. Hopefully, you can me regarding this  matter.

It's been more than week that our server prompts messages about "authentication error for illegal user...". We thought of it as a brute force attack. We already tried "denyhosts" and so far it is working fine but the problem is that denyhosts can only deny attackers basing on their IP. If the attacker changes their IP, denyhosts won't be able to deny them. Now, the attackers keeps on changing it's IP using different user name and we think if we will not do something about it, the attacker might be able to access the server. 

Does anyone know any other options in blocking attackers from accessing the server?
Any help is appreciated.


----------



## graudeejs (Jul 3, 2010)

If it's ssh attack, bes thing you can do is to change default port sshd is listening (in /etc/ssh/sshd_config)

also search forum, there have been many similar threads


----------



## mfaridi (Jul 3, 2010)

you can install denyhost and use for stop ssh attack


----------



## serhiy (Jul 3, 2010)

If you use the pf firewall, you can add this to your /etc/pf.conf:


```
table <cool_hackers> persist
block in quick inet from <cool_hackers>
pass in quick inet proto tcp from any to $your_external_ip port 22 flags S/SA synproxy state (source-track rule, max-src-conn 3, max-src-conn-rate 2/60, overload <cool_hackers> flush)
```

You can adjust max-src-conn and max-src-conn-rate parameters to fit your needs.
And then you can see who tried to access your server, using the command

```
# pfctl -t cool_hackers -T show
or
# pfctl -t cool_hackers -T show -v
```
And you must flush this table over time, using the command

```
# pfctl -t cool_hackers -T flush
```


----------



## dennylin93 (Jul 3, 2010)

Take a look at PF and security/sshguard-pf.



			
				killasmurf86 said:
			
		

> If it's ssh attack, bes thing you can do is to change default port sshd is listening (in /etc/ssh/sshd_config)
> 
> also search forum, there have been many similar threads



While changing the port may be effective, I don't think it's a good solution. Portknocking is better in my opinion (or use SSH keys).


----------



## alphajim (Jul 4, 2010)

Assumong this is an ssh attack...
Coordinated multihost attacks are so common now that the various ssh "guard" type programs are useless.  Port knocking is ok.  The only real solution is ssh key login only.


----------



## SageRaven (Jul 5, 2010)

*So many philosophies...*

For servers that are mine or that I get paid to support, I prefer to have direct root logins without any host/address restrictions.  Here is how I set up these machines:

1.  Only allow authentication with keys and disable password auth altogether.

If you care about SSH security at all, this is the only solution that really matters.  

2.  Run SSH on some other port.

Yes, this is "security through obscurity" but it keeps my logs cleaner -- I'm a neat freak, so this matters.  Plus, it is a solution that works out of the box.  It also reduces wasted bandwidth/traffic by the script kiddies, since they don't continuously hammer on standard port if it isn't open.

3.  Run SSH via inetd with rate limiting.

It might seem lame, but there are good reasons for this.  First, it's another out-of-the-box method that works.  I add "-C 3" to my "inetd_flags" option in rc.conf, which limits the number of connections to 3 per address per minute.  For the few non-distributed scripts running SSH attacks anymore, this does the trick.  They get 3 guesses, then they're cut off for a little while.  Most seem to move along and not return.  (Note this this never even gets invoked due to #2 above.)  Also, an idle inetd takes up less memory than an idle sshd when nobody is logged in, which makes a difference when you're running in a small VPS or you're running SSH access for tons of individual jails or VPSs.

I'm a minimalist, so I don't like the idea of using any extra firewall rules if they are not necessary.  Why slow down all traffic with one more rule to test for or a list of IPs to scan through, both taking up memory?

While I personally think port knocking is cool as hell, it's an even less portable method than changing the default port number (which a lot of people seem to grumble about).  It's not difficult to tell people (or to program scripts) to use a different port.

Another good step is to use tcp_wrappers (hosts.allow) to deny ssh from all but authorized machines.  But like I said, I desire access from anywhere, so I don't use this myself.


----------



## dennylin93 (Jul 5, 2010)

About the inetd part, this can be achieved by using PF (stateful tracking options).


----------



## SageRaven (Jul 5, 2010)

dennylin93 said:
			
		

> About the inetd part, this can be achieved by using PF (stateful tracking options).



Did you miss the part where I didn't want to slow down the entire IP stack for the sake of a single application?  That's why I prefer application-level access controls where possible.


----------



## anomie (Jul 5, 2010)

alphajim said:
			
		

> Coordinated multihost attacks are so common now that the various ssh "guard" type programs are useless..



Agreed. Single host attacks are trivial to stop. Distributed attacks (where each of thousands of constantly changing hosts connect - at most - two or three times) now account for probably 95% of the sshd login attempts on my 'net facing servers.


----------



## Alt (Jul 5, 2010)

Since i changed sshd port, never seen bruteforce in log xD
There is really many ways to shut this hole, so its no problem at all)


----------



## snesreviews (Jul 23, 2010)

Great thread and some good insight from you guys - thanks. I was seeing some random ssh login attempts and I think port alteration and password protected ssh keys seems to be the path of least resistance for me!


----------

