# bruteforce



## cruzler (Jul 27, 2009)

hi all, i want to ask about bruteforce, i have this message on my log :


```
tail -f /var/log/messsages
```

----------------------------------------------------------------

```
Jul 27 17:25:34 ns sshd[37861]: error: PAM: authentication error for root from 66.249.9.51
Jul 27 17:25:59 ns sshd[37864]: error: PAM: authentication error for illegal user admin from 81.248.26.11
Jul 27 17:26:31 ns sshd[37871]: error: PAM: authentication error for root from 58.16.7.172
Jul 27 17:27:04 ns sshd[37874]: error: PAM: authentication error for illegal user admin from 213.97.64.34
Jul 27 17:27:25 ns sshd[37877]: error: PAM: authentication error for root from 217.125.54.170
Jul 27 17:28:05 ns sshd[37880]: error: PAM: authentication error for illegal user admin from 199.71.115.118
Jul 27 17:28:23 ns sshd[37883]: error: PAM: authentication error for root from 221.7.58.37
Jul 27 17:29:16 ns sshd[37894]: error: PAM: authentication error for root from 210.3.35.110
Jul 27 17:29:53 ns sshd[37904]: error: PAM: authentication error for illegal user admin from 59.90.32.14
Jul 27 17:30:31 ns sshd[37910]: error: PAM: authentication error for root from 196.211.53.74
Jul 27 17:30:50 ns sshd[37918]: error: PAM: authentication error for illegal user admin from 222.247.55.59
Jul 27 17:31:32 ns sshd[37925]: error: PAM: authentication error for root from 196.192.46.46
Jul 27 17:31:32 ns sshd[37927]: error: PAM: authentication error for illegal user admin from 190.144.3.114
Jul 27 17:32:41 ns sshd[37931]: error: PAM: authentication error for illegal user admin from 60.49.234.149
Jul 27 17:32:57 ns sshd[37934]: error: PAM: authentication error for root from audioshare.net
Jul 27 17:33:52 ns sshd[37952]: error: PAM: authentication error for root from 210.3.35.110
Jul 27 17:34:00 ns sshd[37950]: error: PAM: authentication error for illegal user admin from 89.19.5.56
Jul 27 17:34:20 ns sshd[37956]: error: PAM: authentication error for illegal user admin from 189.200.60.2
Jul 27 17:35:27 ns sshd[37962]: error: PAM: authentication error for root from 88.54.58.190
Jul 27 17:35:33 ns sshd[37964]: error: PAM: authentication error for illegal user admin from 80.153.19.225
Jul 27 17:36:24 ns sshd[37969]: error: PAM: authentication error for illegal user admin from 81.92.155.48
Jul 27 17:36:50 ns sshd[37976]: error: PAM: authentication error for root from 200.119.7.142
Jul 27 17:37:03 ns sshd[37979]: error: PAM: authentication error for root from 161.28.54.253
Jul 27 17:37:10 ns sshd[37982]: error: PAM: authentication error for illegal user admin from 165.139.150.133
Jul 27 17:37:46 ns sshd[37985]: error: PAM: authentication error for root from 216.86.207.13
Jul 27 17:38:08 ns sshd[37988]: error: PAM: authentication error for illegal user admin from 211.139.211.248
Jul 27 17:38:34 ns sshd[37991]: error: PAM: authentication error for root from 165.139.150.133
Jul 27 17:39:28 ns sshd[37996]: error: PAM: authentication error for illegal user admin from 80.34.177.167
Jul 27 17:39:35 ns sshd[37999]: error: PAM: authentication error for root from 189.200.60.2
Jul 27 17:39:58 ns sshd[38002]: error: PAM: authentication error for illegal user admin from 131.91.96.111
```

i had face it before, and i install bruteblock to face it, it happen 4 months ago..and it solve until today, i don't know it happens again.. if i see the pattern, it only use user "root" and "admin" to attack, it's little bit different with bruteforce i face 4 months ago, which is use any username, not only "root" and "admin".. 

anyone have a clue about this?? what should i do to solve this problem? 

thanks


----------



## DutchDaemon (Jul 27, 2009)

Blocking a distributed bruteforce attack is very difficult, because blocking every single IP address is unfeasible. Three options:

1. if you know which IP addresses are allowed to use SSH, turn on a firewall and only allow those IP addresses there
2. run sshd on a port other than 22 and inform your ssh users
3. only use keys to log in, not user accounts


----------



## mk (Jul 27, 2009)

i try once putting -:ALL:ALL in /etc/login.access and try ssh to the machine and got instant connection reset.however i didn't make any further tests. * before you make any test read the manual page! the above example is part of what i have in login.access, this line - if only one will cut any access to the machine - from console and from network*


----------



## mk (Jul 27, 2009)

i just test this scenario:
user which is allowed to ssh into machine
with default /etc/login.access user can log in
with /etc/login.conf added -:ALL:ALL to that user login is refused and logs are quiet about that.
however if user is none existent to the system, then logs are filling up(/var/log/auth and messages)
Another thing about login.access is that you can specify host,ip,user.sshd_confing have option which can be used to the same AllowUsers and AllosGroups.using this maybe better that login.access


----------



## aragon (Jul 27, 2009)

DutchDaemon said:
			
		

> 3. only use keys to log in, not user accounts


This is arguably the best way to go.


----------



## mk (Jul 27, 2009)

aragon said:
			
		

> This is arguably the best way to go.


express some other methods


----------



## cruzler (Jul 28, 2009)

DutchDaemon said:
			
		

> Blocking a distributed bruteforce attack is very difficult, because blocking every single IP address is unfeasible. Three options:
> 
> 1. if you know which IP addresses are allowed to use SSH, turn on a firewall and only allow those IP addresses there
> 2. run sshd on a port other than 22 and inform your ssh users
> 3. only use keys to log in, not user accounts



Hmm.. i see..i never do that way before to block bruteforce, because i thought use bruteblock is enough, because 4 month ago i use that way..but now on, i will try what u suggest sir.. n sir, do you have any best link to try a way no. 3? 



			
				mk said:
			
		

> i try once putting -:ALL:ALL in /etc/login.access and try ssh to the machine and got instant connection reset.however i didn't make any further tests. * before you make any test read the manual page! the above example is part of what i have in login.access, this line - if only one will cut any access to the machine - from console and from network*





			
				mk said:
			
		

> i just test this scenario:
> user which is allowed to ssh into machine
> with default /etc/login.access user can log in
> with /etc/login.conf added -:ALL:ALL to that user login is refused and logs are quiet about that.
> ...



Huoo..thanks for ur suggest sir..



			
				aragon said:
			
		

> This is arguably the best way to go.



yeah, i think i would try it..


----------



## gilinko (Jul 28, 2009)

cruzler said:
			
		

> i had face it before, and i install bruteblock to face it, it happen 4 months ago..and it solve until today, i don't know it happens again.. if i see the pattern, it only use user "root" and "admin" to attack, it's little bit different with bruteforce i face 4 months ago, which is use any username, not only "root" and "admin"..
> 
> anyone have a clue about this?? what should i do to solve this problem?
> 
> thanks



I'm using PF+sshguard (http://sshguard.sourceforge.net/) to block bruteforce attacks, and I have it tuned rather aggressively. 

First of all I use only keys to login to my systems, and the sshguard daemon blocks at the second attempt to login within 8 hours and blocks for 24 hours. This both reduced the strain on my system and cleaned up the logs as the ip's got stuck in the firewall.


----------



## dennylin93 (Jul 28, 2009)

+1 for sshguard. I'm also using security/sshguard-pf. It works like a charm. You can set how many attempts within a limit of time are allowed before an IP is blocked. Quite easy to set up.

Some other solutions here: Unofficial FreeBSD Security Checklist / Links / Resources.


----------



## felix (Jul 28, 2009)

I'm using PF+bruteforceblocker (security/bruteforceblocker)


----------



## DutchDaemon (Jul 28, 2009)

The problem with this kind of _distributed_ bruteforce attacks is that it's likely that no single IP will make enough failed logins to ever trigger any automated blocker ..


----------



## cruzler (Jul 30, 2009)

@all, 

Thanks for ur suggestion, so i got a wrong turn when i only use bruteblock to handle brtueforce..but now, i will try to use ssh key, and PF too to hold this thing, n maybe with sshguards too if it's needed..


----------



## gilinko (Jul 30, 2009)

DutchDaemon said:
			
		

> The problem with this kind of _distributed_ bruteforce attacks is that it's likely that no single IP will make enough failed logins to ever trigger any automated blocker ..



That depends. I have blocked even the distributed attacks for the last year. I have found that most distributed login attempts will retry to login with an interval of 1-2 hours from each IP. My sshguard configuration will block on the second failed attempt within a 8 hour window, and keep you blocked for 24 hours.

So a wrong password once(which will not work as I have only allowed keys) shame on you, wrong password again within 8 hours, shame on you again and blocked.


----------



## mfaridi (Jul 30, 2009)

I use denyhost
it works like charm


----------



## Alt (Aug 2, 2009)

+1 for sshguard


----------



## danger@ (Aug 2, 2009)

a little advertisement for my piece of code never hurts :stud
security/bruteforceblocker


----------



## abefar (Aug 7, 2009)

I'm using the following in my pf.conf:

```
# the lists of known bruteforcers
table <attackers-ftp> persist file "/etc/attackers-ftp.list"
table <attackers-ssh> persist file "/etc/attackers-ssh.list"

# block all incoming connections from bruteforcers
block in quick on $ext_if from <attackers-ftp>
block in quick on $ext_if from <attackers-ssh>

# allow FTP with bruteforce protection
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 21 keep state \
(max-src-conn-rate 10/60, overload <attackers-ftp> flush global)

# allow SSH with bruteforce protection
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 keep state \
(max-src-conn-rate 5/30, overload <attackers-ssh> flush global)
```

It permanently blocks every IP trying to connect to my SSH more than 5 times in 30 seconds, or to my FTP server more than 10 times in 60 seconds - works like a charm without the need of any third-party scripts or applications.
Just remember to save the lists on shutdown using "pfctl -t attackers-XXX -T show > /etc/attackers-XXX.list" in _/etc/rc.shutdown_ (unless you want to clear the blocklists when rebooting).


----------



## Alt (Aug 9, 2009)

omg i must learn PF! xD


----------



## cruzler (Aug 10, 2009)

abefar said:
			
		

> I'm using the following in my pf.conf:
> 
> ```
> # the lists of known bruteforcers
> ...



Huooo..thanks a lot, sir..


----------

