# How to get PF and sshguard to stop this guy?



## max21 (Mar 3, 2018)

... and who are they really?

I been playing with my first ever remote server which will end up as a public web sever someday.  As I been told over and over by members _VPS will do_. (i was thinking dedicated). As a habit from my desktop experience I start off trying to capture the most frequent invaders IP’s.  I track by range and added each to be block by pf.

http://centralops.net/co/DomainDossier.aspx?dom_whois=1&net_whois=1&dom_dns=1

One line with tell the story but here’s the complete list. In the end I hope someone could tell me what is going on and if there a better way to stop them all to never be seen again.  It seems that the one call PONEY is the one that is giving new-comers multiple chances to get in, but they don’t!  Same results even with the new version of sshguard, which is one of the reasons why I choose to replace it with the old version. .. sshguard-1.6.4_1

Here is the complete sshguard blacklist:

```
1519580540|100|4|163.172.192.9
1519601699|100|4|175.208.140.113
1519612298|100|4|46.105.121.42
1519615091|100|4|186.46.90.101
1519631548|100|4|58.218.198.155
1519635658|100|4|217.61.5.246
1519726830|100|4|217.64.141.1
1519735236|100|4|116.52.12.242
1519827688|100|4|190.137.139.66
1519838869|100|4|196.216.8.110
1519839673|100|4|175.211.95.171
1519841180|100|4|179.228.242.120
1519842244|100|4|95.183.56.240
1519843000|100|4|51.255.166.189
1519845545|100|4|149.202.102.36
1519861273|100|4|23.105.70.110
1519874715|100|4|118.184.53.50
1519887392|100|4|38.89.136.12
1519999890|100|4|178.62.44.104
```
Here are all the IP’s being blocked by pf:

```
# RANGE
#.......................................................................#
block in quick on $_nic from 221.194.47.243 to any                      # China Unicom - HARD
block in quick on $_nic from 122.226.181.164 to any                     #
block in quick on $_nic from 163.172.192.9 to any                       # rev.poneytelecom.eu
block in quick on $_nic from 193.251.85.52 to any                       #
block in quick on $_nic from 212.83.179.97 to any                       #

block in quick on $_nic from 212.83.160.0     - 212.83.191.255  to any  # jcraft–got or trying for
block in quick on $_nic from 195.154.0.0      - 195.154.127.255 to any  # jcraft–keyboard and mouse
#.......................................................................#
#block in quick on $_nic from 5.101.40.0       - 5.101.40.255    to any # UNITEDPROTECTION-NET
#block in quick on $_nic from 35.192.0.0       - 35.207.255.255  to any # goo-content cloud bye bye  SSH
#block in quick on $_nic from 41.83.74.216     - 41.83.75.255    to any # ADSL-pool

#block in quick on $_nic from 85.190.96.0      - 85.190.127.255  to any # neitherland-getinfo  SSH
#block in quick on $_nic from 103.79.140.0     - 103.79.143.255  to any # vietnam  SSH
#block in quick on $_nic from 112.112.0.0      - 112.115.255.255 to any # china-telco  SSH
#block in quick on $_nic from 115.46.0.0       - 115.46.255.255  to any # china
#block in quick on $_nic from 115.238.244.0    - 115.238.245.255 to any # china
#block in quick on $_nic from 122.226.181.160  - 122.226.181.191 to any # china FAT – IP’s
#block in quick on $_nic from 153.122.0.0      - 153.123.255.255 to any # japan
#block in quick on $_nic from 163.0.0.0        - 163.255.255.255 to any # poney2-ERX-NETBLOCK
#block in quick on $_nic from 177.69.0.0       - 177.255.255.255 to any # DE telec
#block in quick on $_nic from 182.112.0.0      - 182.127.255.255 to any # china uni
#block in quick on $_nic from 203.162.246.96   - 203.162.245.127 to any # vietnam
#block in quick on $_nic from 209.152.160.0    - 209.152.191.255 to any # WebHostPlus telecom.eu
#block in quick on $_nic from 210.121.128.0    - 210.121.255.255 to any # korea
#block in quick on $_nic from 211.58.0.0       - 211.58.255.255  to any # h-master
#block in quick on $_nic from 219.154.0.0      - 219.157.255.255 to any # china-1
#block in quick on $_nic from 221.176.0.0      - 221.183.255.255 to any # china-mobile SSH
#block in quick on $_nic from 221.192.0.0      - 221.195.255.255 to any # china uni
#block in quick on $_nic from 122.226.181.160  - 122.226.181.191 to any # china

#block in quick on $_nic from 107.170.0.0      - 107.170.255.255 to any # persistence
#block in quick on $_nic from 200.109.128/17 to any # vietnam  # CANTV Servicios, Venezuela 200.109.236.50
#block in quick on $_nic from 190.78/15 to any                          # de Argentina - speedy

block in quick on $_nic all
```
I forgot to jot-down all of block out quick.  Thinking out-the-box I thought this might help.  Could this be what is escalating the problem or is it doing anything useful from now into the future?  PONEY is trying everything possible… why should not I?

```
#.......................................................................#
block out quick on $_nic from 122.226.181.164 to any                    #
block out quick on $_nic from 163.172.192.9 to any                      # rev.poneytelecom.eu
block out quick on $_nic from 193.251.85.52 to any                      #
block out quick on $_nic from 212.83.179.97 to any                      #
block out quick on $_nic from 221.194.47.243 to any                     #
#.......................................................................#
```
Anyway, they just keep coming so I set some stronger variables in rc.conf.  How do I tell pardon_min_interval and prescribe_interval to say ="Never-Again"?  I’m not worried about locking myself out --  the VPS control panel is the way to recover.

```
sshguard_enable="YES"
sshguard_safety_thresh="3"             #  3 strikes your out
sshguard_pardon_min_interval="2592000" #  30 days   - lock out for 30 days
sshguard_prescribe_interval="86400"    #  24 hours  - retry within 24 hours
#sshguard_flags=""
```
Now after so many hours this is the bulk of what is trying to get in.  Basically it all the same IP’s that should had already been blocked, but the same just keeps coming in:
1) I don’t have diffie-hellman whatever.
2) I have RSA key but I don’t know if it’s working.  I always have to put password to access the server.

```
Mar  2 17:00:01 order newsyslog[22609]: logfile turned over due to size>100K
Mar  2 17:00:01 order sshguard[854]: Reloading rotated file /var/log/auth.log.
Mar  2 17:00:12 order sshd[22613]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:00:16 order sshd[22614]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:00:39 order sshd[22615]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:00:58 order sshd[22616]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:01:18 order sshd[22617]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:01:39 order sshd[22618]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:02:10 order sshd[22619]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:02:22 order sshd[22620]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:02:42 order sshd[22621]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:03:00 order sshd[22622]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:03:11 order sshd[22623]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:03:24 order sshd[22624]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:03:47 order sshd[22625]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:04:00 order sshd[22626]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(212-83-179-97.rev.poneytelecom.eu, AF_INET) failed
Mar  2 17:04:00 order sshd[22626]: refused connect from 212.83.179.97 (212.83.179.97)
Mar  2 17:04:00 order sshd[22627]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(212-83-179-97.rev.poneytelecom.eu, AF_INET) failed
Mar  2 17:04:00 order sshd[22627]: refused connect from 212.83.179.97 (212.83.179.97)
Mar  2 17:04:07 order sshd[22628]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:04:30 order sshd[22629]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:05:00 order sshd[22632]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:05:13 order sshd[22633]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:05:36 order sshd[22634]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:05:57 order sshd[22635]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:06:09 order sshd[22636]: Received disconnect from 122.226.181.167 port 52002:11:  [preauth]
Mar  2 17:06:09 order sshd[22636]: Disconnected from 122.226.181.167 port 52002 [preauth]
Mar  2 17:06:18 order sshd[22638]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:06:39 order sshd[22639]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:06:59 order sshd[22640]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:07:31 order sshd[22641]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:07:40 order sshd[22642]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:08:02 order sshd[22643]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:08:23 order sshd[22644]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:08:45 order sshd[22645]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:09:06 order sshd[22646]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:09:27 order sshd[22647]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:09:50 order sshd[22648]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:10:18 order sshd[22651]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:10:30 order sshd[22652]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:10:53 order sshd[22653]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:11:13 order sshd[22657]: refused connect from 58.218.198.155 (58.218.198.155)

Etc …
Etc …                             AND SOMETIMES A BIG BLOCK OF THIS:
Etc …

Mar  2 18:32:03 order sshd[22875]: user NOUSER login class  [preauth]
Mar  2 18:32:04 order sshd[22875]: Connection closed by invalid user admin 124.133.5.210 port 55342 [preauth]
Mar  2 18:36:42 order sshd[22882]: Received disconnect from 124.117.241.152 port 25869:11: Bye Bye [preauth]
Mar  2 18:36:42 order sshd[22882]: Disconnected from 124.117.241.152 port 25869 [preauth]
Mar  2 18:36:48 order sshd[22883]: Address 14.231.252.56 maps to static.vnpt.vn, but this does not map back to the address.
Mar  2 18:36:48 order sshd[22883]: Invalid user admin from 14.231.252.56 port 50185
Mar  2 18:36:48 order sshd[22883]: user NOUSER login class  [preauth]
Mar  2 18:36:49 order sshd[22883]: Connection closed by invalid user admin 14.231.252.56 port 50185 [preauth]
Mar  2 18:36:55 order sshd[22886]: reverse mapping checking getaddrinfo for 201-148-117-91.tvactiete.com.br [201.148.117.91] failed.
Mar  2 18:36:55 order sshd[22886]: Invalid user admin from 201.148.117.91 port 32919
Mar  2 18:36:55 order sshd[22886]: user NOUSER login class  [preauth]
Mar  2 18:36:56 order sshd[22886]: Connection closed by invalid user admin 201.148.117.91 port 32919 [preauth]

Etc …
Etc …                MORE   PONEY – PONEY - PONEY
Etc …

Mar  2 17:49:35 order sshd[22793]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(163-172-192-9.rev.poneytelecom.eu, AF_INET) failed
Mar  2 17:49:35 order sshd[22793]: refused connect from 163.172.192.9 (163.172.192.9)
Mar  2 17:49:36 order sshd[22794]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(163-172-192-9.rev.poneytelecom.eu, AF_INET) failed
Mar  2 17:49:36 order sshd[22794]: refused connect from 163.172.192.9 (163.172.192.9)
Mar  2 17:49:43 order sshd[22795]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  2 17:50:05 order sshd[22798]: refused connect from 58.218.198.155 (58.218.198.155)

                    THIS IS ME LOGGING IN:

Mar  2 17:50:50 order sshd[22799]: user MAX-21 login class  [preauth]
Mar  2 17:50:50 order last message repeated 2 times
Mar  2 17:51:09 order sshd[22799]: Accepted keyboard-interactive/pam for MAX-21 from 67.162.0.144 port 10101 ssh2
Mar  2 17:51:23 order su: MAX-21 to root on /dev/pts/0

                    THIS IS WHAT FOLLOWS BUT IT IS NOT ME or my IP(s):


Mar  2 17:51:41 order sshd[22823]: Received disconnect from 121.18.238.39 port 46030:11:  [preauth]
Mar  2 17:51:41 order sshd[22823]: Disconnected from 121.18.238.39 port 46030 [preauth]
Mar  2 17:55:14 order sshd[22832]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(212-83-179-97.rev.poneytelecom.eu, AF_INET) failed
Mar  2 17:55:14 order sshd[22832]: refused connect from 212.83.179.97 (212.83.179.97)
Mar  2 17:55:14 order sshd[22831]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(212-83-179-97.rev.poneytelecom.eu, AF_INET) failed
Mar  2 17:55:14 order sshd[22831]: refused connect from 212.83.179.97 (212.83.179.97)

Mar  2 18:12:03 order sshd[22847]: Unable to negotiate with 103.79.143.62 port 60773: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 [preauth]

Mar  2 18:14:53 order sshd[22852]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(163-172-192-9.rev.poneytelecom.eu, AF_INET) failed
Mar  2 18:14:53 order sshd[22852]: refused connect from 163.172.192.9 (163.172.192.9)
```

Sometime I think *PONEY* is part of sshguard or trying to do me a favor.  For a minute on my way to believing it.


----------



## Lamia (Mar 3, 2018)

What you need is an IDS/IPS for your VM.

Please check here.


----------



## max21 (Mar 3, 2018)

lamia, you got my thinking cap on 

1) If I just let pf and sshguard keep doing what it’s doing I will have less overhead and nothing will ever get in anyway.

2)  Just a guess:  I think Snort & BRO are for the big-boys, it should be on a machine of its own because of the additional overhead.

I got the impression that bruteforceblocker works just like sshguard.   So PONEY and crew are only an annoyances?  Wow!

EDIT:  Those attempts only comes in 10 – 15 seconds (not minutes) and it's only those main two that keeps coming back. Evidently SShGuard kick a lot of butt to get there, but it can't stop those two.  I think I have to try bruteforceblocker.  If that fail, I'll reinstall and watch my ever move.

I’ll be using Snort & BRO when it’s time!  Right now those lozzy two can't be worth all of that. I just wonder how they got to be so slick vs. all the rest.  I'll better contact the providers.

Thanks for all of this lamia!


----------



## Lamia (Mar 3, 2018)

max21 said:


> lamia, you got my thinking cap on
> 
> Thanks for all of this lamia!


You are welcome max21. You can hit the thumb up/thanks button at the adjacent of this reply for me!


----------



## max21 (Mar 4, 2018)

After looking thing over all the information I provided above it would be foolish to think that pf and sshguard are not doing there jobs.  Now consider the fact that VPS’s including most dedicated server are on the provider’s network.  The last line at shut-down time reads “Controller still running” for KVM’s.  So at login time it recapture everything that never got shut-down in the first place. Evidently, FreeBSD is not in charge of KVM, if it was it would disconnect everything to flush, then somehow cleverly re-attach the controller so that the customer can still access his VM.  There got to be a way to almost do anything.

It’s their network that have been compromise and your node is on it.  Pass-through in full-effect to ease the pain.  Just when I thought the Let's Encrypt phishing attack was the worse, now my a**ie could be re-owned every time I boot my node.  And to think my most recent goal is get VPS-> master Let's Encrypt-> HAProxy pass-through-> web server(s).  But hey, these are the breaks:

https://www.linuxquestions.org/questions/linux-security-4/poneytelecom-eu-attack-s-4175617328/

https://www.valueweb.gr/poneyteleco...tnets-scrappers-spammers-and-hacking-scripts/


Well, it’s back to the drawing board.. I mean corner guys
But you got to bring your own wine these days.


----------



## gkontos (Mar 4, 2018)

Just change your sshd port and then noise will go away.


----------



## ShelLuser (Mar 4, 2018)

In addition to what gkontos said: do you really need your SSH port to be publically open?

I also can't help wonder what authentication method you're using, don't tell me you rely on username / passwords?  Because that's basically a kiddie magnet in itself, it gives the kiddiots the idea that all they have to do is put in enough guesses in order to eventually get somewhere. Authenticate by keys and the whole thing becomes much less appealing.

See, there's another problem with your current setup: you're also opening yourself up for a rather easy DoS attack. If they poke often enough then they could even put some extra unwanted pressure on your system because SSHGuard might be doing its best to keep up.

All in all it's not worth the effort, and only a nuisance best removed. If you only log onto the server from specific locations then block the whole thing and open it up for only those IP's. If you need public access, follow gkontos' advise and most of all: don't rely on username / passwords.


----------



## Eric A. Borisch (Mar 4, 2018)

Are you on 11.1? Have you thought about using blacklistd(8) instead?

See: https://www.vultr.com/docs/how-to-install-blacklistd-on-freebsd-11-1 -- it is the more direct (part of base, integrated into sshd) solution going forward.

Also, as recommended above, use a shared key for any public-facing SSH (even on a non-standard or port-knocked setup.) Or -- even better -- a shared key and security/pam_google_authenticator. If you've never played with PAM before, just stick with the shared key.


----------



## no-pain-no-gain (Mar 5, 2018)

When you have pf already in place, then a bruteforce table can help you. 
https://home.nuug.no/~peter/pf/en/bruteforce.html


----------



## SirDice (Mar 5, 2018)

Note, that while sshguard works well for single attacks, it has problems with distributed attacks where each attempt will come from a different IP address. Regardless of the tool you're going to use, none of them are going to help much with distributed attacks. Also note that these are likely not a single person who's attacking you but multiple, infected, hosts running an automated script. 

And it looks like your pf.conf isn't configured correctly for sshguard. SSHGuard adds IP addresses to a table named sshguard. And it's this table you need to add to your /etc/pf.conf:

```
ext_if="em0"

table <sshguard> persist

block drop in quick on $ext_if from <sshguard>
```

You appear to have an odd mix of custom rules and hosts.allow(5).


----------



## max21 (Mar 6, 2018)

FYI: My domain-name and this VPS have absolutely no importance outside of learning.  It’s a favor to see the worse before going public with the real thing.  I’m a server newbie with some basic knowledge, but never written until now.  Too much to list to track down what’s going on.



SirDice said:


> Note, that while sshguard works well for single attacks, it has problems with distributed attacks where each attempt will come from a different IP address. Regardless of the tool you're going to use, none of them are going to help much with distributed attacks. Also note that these are likely not a single person who's attacking you but multiple, infected, hosts running an automated script.
> . . .



SirDice, now I seriously understand and I can say as a witness “that’s exactly what it is”!  The good thing is SSHGuard and pf has and still is proving itself.  If I had ordered DOS protection I would have learn nothing about it.  I read about how one can be given an IP that has been under attack long before you got it.  I don’t see anything that I done wrong in any configuration file.  All I have is rc.conf, pf and sshguard same stuff that works at home for years.  But still you detected something wrong.  It could be because I did monkey around with hosts.allowed and sshguard-blacklist.  I put those two most active offenders at the top of each list, by switching it with whatever was there already, but I did not touch the time-stamp, fingerprint or whatever its call.  The interesting thing was it only gave the same warning, the same everything but it did not stop  SShGuard form working.  I see that SShGuard might catch new offenders even hours apart, but a few phony-poney sticky get block every 10 – 20 sec.  Not bad I kind of think.  I would test it in production just to see how well the system hold up while giving cron something useful to do, or just to say I DARE you.

Thank you for the most in depth description that I have ever seen or read.  You always seem to say so much more in so fewer words.  Got it!  Down-to-Earth is what it is.



ShelLuser said:


> In addition to what gkontos said: do you really need your SSH port to be publically open?
> 
> I also can't help wonder what authentication method you're using, don't tell me you rely on username / passwords?  Because that's basically a kiddie magnet in itself, it gives the kiddiots the idea that all they have to do is put in enough guesses in order to eventually get somewhere. Authenticate by keys and the whole thing becomes much less appealing.



ShelLuser, it was not my intent to rely on username and password.  I created and install the key but now I realize it had never worked because I always have to use the username and password to access the machine.  I’m going to get it right very soon.  However, either way it seems that ssh is going to have to be used.  If I turn it off there are no attacks what-so-ever, but when I turn it back on, phony-poney comes back.  I often wonder if I’m using the most recommend state here?


```
pass in quick on $_nic proto tcp from any to port $_ssh $ib_state    #  needed regardless
pass in quick on $_nic proto udp from any to port $_ssh keep state          #  does nothing
```

Anyway, I understand that gkontos solution is the only way to go to solve this kind of problem. DOS protection is good and it should be free.  I think it’s good to know how dirty the drawls has gotten, then change the port number.

But when you said "becomes much less appealing."  Do you mean hacker and cracker are on the verge of killing that too   ... can't be.  This a positive, I'm just not reading it right 

..............
I want to Thank everyone for all of these great tips.  Much as I love SShGuard, nothing stop me for testing other ways, especially now that I know that the base-system has a way.  A member here name fred974 learned all of that and more.  His examples are already in my pf.  I keep it on the backburner for future study.  You got to at least know how it works.

. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Although I had this VPS since the 1st of last month, This was the day or about the day I installed the system and I saved all the log files before the very first reboot.  My home system is secure.  I don’t know who live in Comcast pool.  I’m the renter and the VPS has only one user and that is me.  I don’t know eric or anyone else but as you can understand he is not the only one who is so close to grabbing the keyboard.  Everybody want the keyboard and mouse, but no one have ever got it yet.  I watched like a hawk like I had nothing else to do in life.  I’ll leave off showing a few bits and pieces and I post my final solution once I rebuild again and rent a new VPN, elsewhere for comparison.  In my book FreeBSD-11.1 won already!

*Maybe useful, it at least show how some can do it.*

```
Feb 20 22:46:39 order sshd[962]: Disconnected from 121.18.238.125 port 45661 [preauth]
Feb 20 22:48:43 order sshd[964]: Invalid user eric from 150.60.158.42 port 14832
Feb 20 22:48:43 order sshd[964]: user NOUSER login class  [preauth]
Feb 20 22:48:43 order sshd[964]: user NOUSER login class  [preauth]
Feb 20 22:48:43 order sshd[964]: Postponed keyboard-interactive for invalid user eric from 150.60.158.42 port 14
Feb 20 22:48:44 order sshd[964]: error: PAM: authentication error for illegal user eric from ae170.secure.ne.jp
Feb 20 22:48:44 order sshd[964]: Failed keyboard-interactive/pam for invalid user eric from 150.60.158.42 port 1
……………..
……………..
Feb 25 17:27:23 order sshd[1135]: Invalid user castis from 175.208.140.113 port 50774
Feb 25 17:27:23 order sshd[1135]: user NOUSER login class  [preauth]
Feb 25 17:27:23 order sshd[1135]: Received disconnect from 175.208.140.113 port 50774:11: Normal Shutdown, Thank you for playing [preauth]
```


*And this shows that SSHGuard is still hard at work!*

```
Mar  6 06:30:04 order sshd[9892]: Connection closed by 174.138.77.33 port 42286 [preauth]
Mar  6 06:30:04 order sshguard[597]: blacklist: added 174.138.77.33
Mar  6 06:30:04 order sshguard[597]: 174.138.77.33: blocking forever (3 attacks in 661 secs, after 1 abuses over
Mar  6 06:30:33 order sshd[9897]: refused connect from 58.218.198.155 (58.218.198.155)
```


*MAR 6*

```
Mar  6 04:00:03 order newsyslog[9433]: logfile turned over due to size>100K
Mar  6 04:00:03 order sshguard[597]: Reloading rotated file /var/log/auth.log.
Mar  6 04:00:31 order sshd[9439]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:01:02 order sshd[9442]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:01:41 order sshd[9443]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:02:02 order sshd[9444]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:02:35 order sshd[9445]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:03:03 order sshd[9446]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:03:42 order sshd[9447]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:04:07 order sshd[9448]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:04:37 order sshd[9449]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:05:05 order sshd[9452]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:05:36 order sshd[9453]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:06:05 order sshd[9454]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:06:36 order sshd[9455]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:07:05 order sshd[9456]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:07:35 order sshd[9457]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:08:05 order sshd[9458]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:08:37 order sshd[9459]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:09:07 order sshd[9460]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:09:36 order sshd[9461]: refused connect from 58.218.198.155 (58.218.198.155)

Mar  6 04:11:06 order sshd[9469]: Received disconnect from 121.18.238.39 port 49434:11:  [preauth]
Mar  6 04:11:06 order sshd[9469]: Disconnected from 121.18.238.39 port 49434 [preauth]
Mar  6 04:11:07 order sshd[9471]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:11:34 order sshd[9472]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:12:06 order sshd[9473]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:12:35 order sshd[9474]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:13:10 order sshd[9475]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:13:35 order sshd[9476]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:14:10 order sshd[9477]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:14:34 order sshd[9478]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:15:04 order sshd[9481]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:15:41 order sshd[9482]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:16:09 order sshd[9483]: refused connect from 58.218.198.155 (58.218.198.155)
Mar  6 04:16:17 order sshd[9484]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(163-172-192-9.rev.poneytelecom.eu, AF_INET) failed
Mar  6 04:16:17 order sshd[9484]: refused connect from 163.172.192.9 (163.172.192.9)
Mar  6 04:16:17 order sshd[9485]: warning: /etc/hosts.allow, line 2: can't verify hostname: getaddrinfo(163-172-192-9.rev.poneytelecom.eu, AF_INET) failed
Mar  6 04:16:17 order sshd[9485]: refused connect from 163.172.192.9 (163.172.192.9)
Mar  6 04:16:32 order sshd[9486]: refused connect from 58.218.198.155 (58.218.198.155)
```

I think I can keep the rest from even touching with nothing more than the base-system method and such that Eric A. Borisch posted, and/or fred974.  I bet!


----------



## SirDice (Mar 6, 2018)

max21 said:


> My domain-name and this VPS have absolutely no importance outside of learning. It’s a favor to see the worse before going public with the real thing.


One thing to remember, _any_ port running _any_ service will get hit as soon as you open it up to the internet. Depending on the location (on the internet) it can take just a few seconds to a few minutes, but you can be certain you're going to get hit. The internet is rife with bots scanning for all sorts of easy ways in. And that's mostly what you'll be seeing, automated scripts running on infected hosts. Don't ever think you're not going to be a target just because nobody knows about your website. "They" don't need to know, they're just randomly scanning IP addresses. And with any random numbers, sooner or later, your number will come up. 

Also remember, the "bad guys" running those bots have all the time in the world. They don't care if a brute-force scan takes 5 minutes or 12 weeks to complete. It's simply a numbers game, try often enough on as many hosts as possible and sooner or later you can get a foothold. That foothold is all the automated scripts need and seconds later your machine has become part of that botnet, scanning for other vulnerable hosts.


----------



## max21 (Mar 16, 2018)

SirDice said:


> One thing to remember, _any_ port running _any_ service will get hit as soon as you open it up to the internet. Depending on the location (on the internet) it can take just a few seconds to a few minutes, but you can be certain you're going to get hit. The internet is rife with bots scanning for all sorts of easy ways in. And that's mostly what you'll be seeing, automated scripts running on infected hosts. Don't ever think you're not going to be a target just because nobody knows about your website. "They" don't need to know, they're just randomly scanning IP addresses. And with any random numbers, sooner or later, your number will come up.
> 
> Also remember, the "bad guys" running those bots have all the time in the world. They don't care if a brute-force scan takes 5 minutes or 12 weeks to complete. It's simply a numbers game, try often enough on as many hosts as possible and sooner or later you can get a foothold. That foothold is all the automated scripts need and seconds later your machine has become part of that botnet, scanning for other vulnerable hosts.



I see what you mean SirDice.  It’s real-life now and if I say nothing more I will never forgive myself.  I been keeping an eye on both vps’s from coast to coast … _I always wanted to say/do that_ and I notices one main thing.  On my brand-new 2nd server I installed blacklist and it’s pf rules immediately after the first install of FreeBSD before reboot.  Of course I did all the testing with *services * start, and rerun pf.  This time I did my old stuff.  A full shutdown –p now, including pulling the plug power-off.  But as you know with KVM the controller will not turn-off.  If it did you can’t connect back to it.

The interesting thing was, about 15 minutes latter, at the control-panel, I boot this brand new node.  Would you know it had a kernel panic immediately after the beastie-screen, within the first few few lines.  So I power-off again and rebooted.

All went well and it noted BLACKLIST running!!!

I ran all the commands from the only two how-to and they all WORKED!

All of this to say, as you guys already know; on my first node it been through the ringer all ready with Phony-Poney and when I replaced sshguard with BLACKLISTd -- > then ONLY rebooted, because that is what we do …  those commands turn up nothing for over 24 hours.

So now I know what I need to do and it will serve as proof of concept at least to myself:  I re-check all my settings … then I powered-off the system.  It did not crash _node-1_ but I be darn,  BLACKLISTd was now running!   My guest is it’s a KVM thing which never turns off the controller.  FreeBSD has no choose in the matter.  Bottom line, it did something to initiate blacklistd, even for 11.1. This is could be why others got it to working before the 11.1 mostly-fix and never knew how they actually got it to work.  It's just a guess. 

https://hackertarget.com/ssh-blacklist/

Edit:

In the link*:*


> A system of running *SSH Blacklisting* can quickly devolve into a game of whack a mole as the attacking IP addresses will frequently change.



SirDice*:*


> It's simply a numbers game, try often enough on as many hosts as possible and sooner or later you can get a foothold.



What a match about the numbers game.  Good info!


----------



## aurora (Mar 20, 2018)

Hello 

I run sshd and to keep intruders off I activated the PF like:

pf.conf:

```
anchor "emerging-threats"
load anchor "emerging-threats" from "/etc/pf.anchors/emerging-threats"
```

/etc/pf.anchors/emerging-threats:

```
table <emerging_threats> persist file "/etc/emerging-block-ips.txt"
block log from <emerging_threats> to any
```
Whenever a new intruder comes up I add its IP to the .txt and so far so good but today the IP of 59.63.166.104  defeated the PF i.e. though it's on the block ips .txt file, it still keeps on intruding the server like so:

`20.03.2018 16:01:12,879 sshd: error: PAM: authentication error for root from 59.63.166.104 via 192.168.1.120`

What should I do in that case?


----------



## SirDice (Mar 20, 2018)

The file is only loaded when you (re)load the firewall. It's not loaded dynamically.


----------



## aurora (Mar 20, 2018)

I reload the firewall by `pfctl -f /etc/pf.conf` i.e. the changes take effect. But that particular IP defeats the PF


----------



## SirDice (Mar 20, 2018)

It's only going to block _new_ connections. If the attacker already has a state in the firewall it's going to keep its connection.


----------



## aurora (Mar 20, 2018)

SirDice said:


> It's only going to block _new_ connections. If the attacker already has a state in the firewall it's going to keep its connection.


How can I reset that state in firewall / Packet Filter? A simple restart (pfctl -f /etc/pf.conf) didn't cut it.


----------



## SirDice (Mar 20, 2018)

aurora72 said:


> A simple restart (pfctl -f /etc/pf.conf) didn't cut it.


No, that only reloads the rules. It's going to leave all current states as-is. You can add `-F all` to flush all the states but this will kill _every_ connection. To kill the states for a specific host use `pfctl -k <host>`, see pfctl(8).


----------



## Lamia (Mar 21, 2018)

aurora72 said:


> How can I reset that state in firewall / Packet Filter? A simple restart (pfctl -f /etc/pf.conf) didn't cut it.


You don't have to periodically reset the state in the firewall. A combination of bruteforceblocker and sshguard might be what you need. Their tables will automatically get populated. They serve different purposes.
You may need some additional lines like the below to your pf.conf.

```
# Stateful Tracking Options.
# To clear <blocked_hosts> add to root's crontab:
# * * * * * /sbin/pfctl -t blocked_hosts -T expire 600 > /dev/null 2>&1
# This will block bad hosts for 10-11 minutes
sto_ext_ports="(max-src-conn-rate 500/10, overload <blocked_hosts> flush globa
l)"
sto_nat_ports="(max-src-conn-rate 100/1)"
...........
### Tables ###
table <sshguard> persist
table <bruteforce> persist
table <blocked_hosts> persist

.....
.....
block log quick from <bruteforce>
block in log on $ext_if from <blocked_hosts>
......
.....
pass in log on $ext_if proto {tcp} from any to ($ext_if) port $tcp_pass \
     keep state (max-src-conn 500, max-src-conn-rate 15/5, \
     overload <bruteforce> flush global)
.....
......
# block all IPs from  sshguard-pf blocklist without any further evaluation
block drop in log quick on $ext_if inet from <sshguard> to any
block in log on $ext_if from <blocked_hosts>
```
I guess the blocked_hosts table would serve as your emerging-threats table. It is pretty much empty here but not my sshguard & bruteforce tables, which are very long lists of IP addresses.


```
pfctl -t sshguard -T show            
   2.191.118.226
   5.8.10.202
   5.39.218.19
......
......
# pfctl -t bruteforce -T show
   1.164.55.52
   2.226.155.188
   5.100.250.159
.......
........
........
```

Please take note of the order of rules in PF.


----------



## max21 (Mar 21, 2018)

aurora72 said:


> Hello
> 
> I run sshd and to keep intruders off I activated the PF like:
> ....
> ...




I got a lot of those types of warning, but they always had one IP and not two difference IP unless I had login.  I can't really help because I still going through it, but FYI,  I got the suggested blacklistd and sshguard running, but out of many, only a few manage to keep coming back.  This was before I change the port.  It’s interesting to see and try to learn of the difference ways they try to come back with no success and to know how long it takes for a IP to try again.  I knew gkontos idea was the way to go but if I had change port to soon I would had been spoil to quick.

Below: notice how they found me and how long it took after changing the port to 2222.  If this is all she wrote, I can spare that bit of cpu.  That might be a win win already.  And if I can’t stop them I’ll create a CRON process to change port the second they max-up on me.  From the look of things it might be weeks to months.

This is an another interesting form of trickery  \026\003\001.  I think that IP is the only one that does it.  BTW: thanks to the port change it got rid of Phony-Pony and near, if not all the rest.  He was the most powerful.  As Anyway, I have not check these IP yet but I know I seem them.  These must be some power-boys sent by Pony to find me.  I'll see soon.

```
Mar 18 01:12:21 order login: ROOT LOGIN (root) ON ttyv0
Mar 18 16:33:48 order sshd[1823]: Did not receive identification string from 213.149.105.28
Mar 18 18:57:50 order sshd[1928]: Invalid user ubnt from 218.144.207.79 port 44819
Mar 18 18:57:50 order sshd[1928]: user NOUSER login class  [preauth]
Mar 18 18:57:51 order last message repeated 5 times
Mar 18 18:57:51 order sshd[1928]: error: maximum authentication attempts exceeded for inval
Mar 18 18:57:51 order sshd[1928]: Disconnecting invalid user ubnt 218.144.207.79 port 44819
----------------------------------------------------------------------------------------------------------------------------------------
Mar 19 17:28:28 order sshd[3297]: Did not receive identification string from 5.8.10.202 por
Mar 19 17:28:29 order sshd[3298]: Connection closed by 5.8.10.202 port 44128 [preauth]
Mar 19 17:37:20 order sshd[3307]: Bad protocol version identification '\026\003\001' from 5.8.10.202
----------------------------------------------------------------------------------------------------------------------------------------
Mar 20 05:19:26 order sshd[4156]: User root from 222.186.46.11 not allowed because not list
Mar 20 05:19:26 order sshd[4156]: user NOUSER login class  [preauth]
Mar 20 05:19:26 order sshd[4156]: Connection closed by invalid user root 222.186.46.11 port
----------------------------------------------------------------------------------------------------------------------------------------
Mar 20 17:19:56 order sshd[4688]: Did not receive identification string from 196.52.43.115
----------------------------------------------------------------------------------------------------------------------------------------
Mar 21 01:30:37 order sshd[5152]: Connection closed by 125.212.217.215 port 45254 [preauth]
Mar 21 01:30:37 order sshd[5154]: Connection closed by 125.212.217.215 port 45652 [preauth]
```

BTW: I know not to log in as root in production.  For now I don't care.  I'm the hunter!

Below:  the first use to have 40-50 and the next had about 7 entries.  Since changing the port and rebooting, it’s now empty or not working due to the port change – or working.  Whatever the case someday I’ll re-touch all my setting, shutdown, pull the plug and give it some air. Or could it be blacklistd really need port-22 in order to work properly.  It was recently just fix in 11.1.  I don’t think it was 11.0.  I forgot.

```
(/)blacklistctl dump
        address/ma:port   id      nfail  last access
(/)
(/)blacklistctl dump -b
        address/ma:port   id      nfail  last access
(/)
```


----------



## gkontos (Mar 21, 2018)

Lamia said:


> You don't have to periodically reset the state in the firewall. A combination of bruteforceblocker and sshguard might be what you need. Their tables will automatically get populated.



That is not true. A firewall does stateful inspection. Which means that if someone is brut-forcing you, even if you block them in the firewall you need to clear that state.


----------



## max21 (Mar 21, 2018)

gkontos said:


> That is not true. A firewall does stateful inspection. Which means that if someone is brut-forcing you, even if you block them in the firewall you need to clear that state.


.
*On that note* after the touch-up; to participate in this number game, I’ll run this as a script when it time to all clear all /var/log, auto-rotate port via CRON and service restarts.  So far I rerun pf and flush-log quite often.  That could be why most of them never came back.

```
rm -Pr /var/log/auth.log.*
cat /dev/null > /var/log/auth.log
etc . . .
sleep 1

pfctl -F all                         # flush rules
pfctl -d                             # stop pf
pfctl -f /etc/pf.conf                # load rules
/etc/rc.d/pf start                   # pf start
pfctl -vvnf /etc/pf.conf
sleep 1
exit;
```

About SirDice suggestion, I'll include this; pfctl -k 0.0.0.0/0 -k 0.0.0.0/0 but I never figure out how to do it automatically and not have to manually input each everytime one pop-up.  kill-all is no good unless it's an emergency.  When I find the time I write a program for this.  Somebody got to do it.  It need to be in C for speed to pounce like a lion.


----------



## Lamia (Mar 22, 2018)

gkontos said:


> That is not true. A firewall does stateful inspection. Which means that if someone is brut-forcing you, even if you block them in the firewall you need to clear that state.


Referring to your message - The file is only loaded when you (re)load the firewall. It's not loaded dynamically.-, I reckon that (when you make changes to the pf.conf) is the only time you (re)load  the firewall. You don't have to run a cron job or anything similar to periodically reload PF/Firewall. That is how I know PF to work - and - was what I meant by not periodically resetting/reloading. Of course, if someone is bruteforcing into your machine and you have updated your PF to stop/block the attempt, you definitely need reload PF for the update to take effect.

max21: While it is strongly recommended that your change your ssh port, it is also strongly recommended that you use key authentication over password authentication. And for the bruteforceblocker, it is the only agent among the three (sshguard, blacklisted & bruteforceblocker), as far as I know for now, that has a list of blacklisted IP addresses that exploit/attack other machines. The list is regularly updated from the danger.rulez.sk website (i.e. author of the pkg) on startup. And you can run a cron job to periodically update the list.


----------



## max21 (Mar 22, 2018)

Unbelievable! They dump me.  Not a single hit since my last post.

Lamia, It is easy to be misunderstood.  Such as:  My plan is to clear all states by restarting PF every blue moon during maintenances hour.  At the rate things are going I might not ever have that type of attack again; if so, I’m going to use my procedure to evade them.
I’ll get my keys working latter.  That was my original issue.  I actually thought I was using keys but I end up learning more than I ever image about pf, DDOS attacks, sshd, blaklistd and more.

Anyway, whatever hits I get with-in a full 48 – 60 hours will tell me all I ever wanted to know. 

I just got one doing the *bad protocol* thing. Dang! /003.  Maybe it's a way to latch-on when one connect ot disconnect.


----------



## max21 (Mar 22, 2018)

aurora72, I use to use everything here to try to get rid of persistence IP’s but there are occasions where nothing what-so-ever will work.   Yesterday while thinking about your post, I was trying to Close Connection for an IP using XP TCPView.  Then I notice that it was in TIME_WAIT and I could not close it.  Ten years and I never thought that deep about it.   We have  no choice but to bring the interface down, THEN wait, OR drop the connection immediately using pfctl double –k.   I think scrub or sysctl.conf setting can help.  Other than that I’m all ears.


----------



## max21 (Mar 22, 2018)

After one measly comment, here they come again.  Bottom-line:  changing port number is the first and/or final option.  Everything else seems to be a matter of taste but blacklistd rides deeper however I found no log-file with the list of blocked IP's.



Lamia said:


> . . . And for the bruteforceblocker, it is the only agent among the three (sshguard, blacklisted & bruteforceblocker), as far as I know for now, that has a list of blacklisted IP addresses that exploit/attack other machines.  ....


There it is. Logging.  If I were working in the field I would have been fired.  How did I miss that?  I think blacklistd spoil me, but it has no logging, and after reboot it seems whatever was there is now gone it seems.  But something somewhere it still seem to be working.

Anyway, one or more of them GOT to be in-place.  Now that I seen it all except death to the node itself it time to get my ssh keys working.  I realize that all I can ever do is to keep an eye on the logs and rotate the ssh port-number when needed.  That’s cool by me, maybe I can tell it to call me or something before crunch time using a script.


```
Mar 21 22:26:02 order sshd[6586]: Did not receive identification string from 77.72.83.21
Mar 21 22:26:03 order sshd[6587]: Bad protocol version identification '\003' from 77.72.
Mar 21 22:26:05 order sshd[6588]: Bad protocol version identification '\003' from 77.72.
Mar 22 07:10:03 order sshd[7315]: Did not receive identification string from 71.6.146.18
Mar 22 07:10:03 order sshd[7316]: Connection closed by 71.6.146.185 port 41236 [preauth]
Mar 22 07:10:03 order sshd[7318]: Connection closed by 71.6.146.185 port 41348 [preauth]
Mar 22 07:44:02 order sshd[7344]: Address 191.102.120.201 maps to azteca-comunicaciones.
Mar 22 07:44:02 order sshd[7344]: User root from 191.102.120.201 not allowed because not
Mar 22 07:44:02 order sshd[7344]: user NOUSER login class  [preauth]
Mar 22 07:44:03 order last message repeated 5 times
Mar 22 07:44:03 order sshd[7344]: error: maximum authentication attempts exceeded for in
Mar 22 07:44:03 order sshd[7344]: Disconnecting invalid user root 191.102.120.201 port 9
Mar 22 11:49:58 order sshd[7554]: Invalid user admin from 123.59.182.194 port 37803
Mar 22 11:49:58 order sshd[7554]: user NOUSER login class  [preauth]
Mar 22 11:49:59 order last message repeated 5 times
Mar 22 11:49:59 order sshd[7554]: error: maximum authentication attempts exceeded for in
Mar 22 11:49:59 order sshd[7554]: Disconnecting invalid user admin 123.59.182.194 port 3
```

I flush the log then they gone.  No more attempts for the rest of the day at minimum i get.

Thanks for all


----------



## Eric A. Borisch (Mar 22, 2018)

aurora72 said:


> Hello
> 
> I run sshd and to keep intruders off I activated the PF like:
> 
> ...



You should be able to do something like this.


```
#!/bin/sh
pfctl -t emerging_threads -T add $1 && pfctl -k $1
```

and run `./add_threat 59.63.166.104` to add it to the table and kill states (no reload required.)

Add something like `0 2 * * * root /sbin/pfctl -q -t emerging-threats -T show > /etc/emerging-block-ips.txt` to your crontab to save off the table nightly. You can also do an expiration via crontab if you have any desire to age them out.

If you go this route, you don't need to have the separate anchor file; just put those directives into pf.conf (unless you like the separation for other reasons.)


----------



## SirDice (Mar 27, 2018)

max21 said:


> Everything else seems to be a matter of taste but blacklistd rides deeper however I found no log-file with the list of blocked IP's.


`blacklistctl dump -d`:

```
root@maelcum:~ # blacklistctl dump -d
        address/ma:port id      nfail   last access
  45.40.138.145/32:22           1/3     2018/03/26 15:47:04
    68.34.7.131/32:22           1/3     2018/03/27 02:12:19
   5.196.65.134/32:22           1/3     2018/03/27 09:52:50
 80.254.122.201/32:22           1/3     2018/03/26 13:27:59
  97.74.232.159/32:22           1/3     2018/03/26 10:52:08
 220.245.146.47/32:22           1/3     2018/03/26 16:07:17
 124.124.99.216/32:22           1/3     2018/03/27 07:12:49
 114.241.199.75/32:22           1/3     2018/03/26 11:21:40
 49.156.148.212/32:22           1/3     2018/03/26 15:27:06
 131.72.216.146/32:22           1/3     2018/03/26 17:12:18
 75.136.156.134/32:22           1/3     2018/03/27 00:41:16
 103.200.22.113/32:22           2/3     2018/03/26 11:21:59
  123.21.107.27/32:22           1/3     2018/03/26 15:33:47
  46.105.20.171/32:22           1/3     2018/03/27 01:48:56
 161.139.115.25/32:22           1/3     2018/03/27 08:39:15
   13.124.92.51/32:22           1/3     2018/03/27 09:06:32
 210.121.196.10/32:22           1/3     2018/03/26 17:02:24
  82.211.44.200/32:22           1/3     2018/03/26 21:06:10
 110.10.174.179/32:22           1/3     2018/03/27 08:01:42
 14.207.167.214/32:22           1/3     2018/03/26 15:34:00
167.249.224.154/32:22           1/3     2018/03/27 03:44:58
125.212.228.165/32:22           1/3     2018/03/27 10:08:41
   89.27.251.12/32:22           1/3     2018/03/26 21:10:43
  193.70.90.250/32:22           1/3     2018/03/27 01:06:08
 202.54.249.131/32:22           1/3     2018/03/26 20:38:49
125.212.249.115/32:22           1/3     2018/03/26 16:31:31
 219.148.149.90/32:22           1/3     2018/03/26 20:57:31
  193.70.46.201/32:22           1/3     2018/03/27 08:04:12
   54.37.17.179/32:22           1/3     2018/03/26 13:41:32
 195.53.115.116/32:22           1/3     2018/03/27 08:01:51
 109.92.176.135/32:22           1/3     2018/03/26 12:39:00
181.111.193.251/32:22           1/3     2018/03/26 15:16:58
 162.105.92.153/32:22           1/3     2018/03/26 19:09:09
 211.72.203.250/32:22           1/3     2018/03/27 05:34:11
 180.101.145.87/32:22           1/3     2018/03/26 22:42:44
 180.250.19.128/32:22           1/3     2018/03/27 08:16:22
 217.112.91.190/32:22           1/3     2018/03/27 02:42:07
203.198.158.147/32:22           1/3     2018/03/27 06:46:46
   187.64.128.7/32:22           1/3     2018/03/27 08:01:15
 114.221.101.15/32:22           1/3     2018/03/26 15:34:13
175.117.145.239/32:22           1/3     2018/03/26 17:21:17
   43.242.84.52/32:22           1/3     2018/03/26 18:03:16
   221.146.5.81/32:22           1/3     2018/03/26 18:42:27
128.199.138.212/32:22           1/3     2018/03/27 00:32:30
 61.220.209.219/32:22           1/3     2018/03/27 02:29:41
 35.160.134.253/32:22           1/3     2018/03/26 13:09:32
 60.250.168.200/32:22           1/3     2018/03/27 03:37:16
103.231.218.254/32:22           1/3     2018/03/27 04:08:23
 216.245.215.98/32:22           1/3     2018/03/27 08:20:07
   138.68.7.146/32:22           1/3     2018/03/26 21:30:48
   139.99.119.2/32:22           1/3     2018/03/27 02:19:35
  94.102.60.135/32:22           1/3     2018/03/27 08:12:54
183.203.220.234/32:22           1/3     2018/03/26 17:42:08
  46.32.104.210/32:22           1/3     2018/03/26 22:37:04
   85.199.232.4/32:22           1/3     2018/03/27 06:48:55
 41.223.142.211/32:22           1/3     2018/03/26 19:50:28
  182.61.42.204/32:22           1/3     2018/03/27 02:33:35
 120.92.142.135/32:22           2/3     2018/03/27 03:20:23
 201.147.183.55/32:22           1/3     2018/03/26 10:50:56
  193.70.85.206/32:22           1/3     2018/03/26 17:44:53
 180.168.36.170/32:22           1/3     2018/03/26 17:57:45
  218.38.121.17/32:22           1/3     2018/03/27 08:44:07
  61.82.251.224/32:22           1/3     2018/03/27 08:51:53
 210.187.25.165/32:22           1/3     2018/03/26 11:38:44
   103.26.14.92/32:22           1/3     2018/03/26 16:39:52
   41.138.51.69/32:22           1/3     2018/03/26 18:39:41
   5.135.161.94/32:22           1/3     2018/03/26 18:50:59
 110.10.189.182/32:22           1/3     2018/03/26 23:16:12
   14.23.77.154/32:22           1/3     2018/03/26 12:05:17
 218.147.99.252/32:22           1/3     2018/03/26 14:21:49
  54.37.139.198/32:22           1/3     2018/03/26 18:30:28
  123.20.53.104/32:22           1/3     2018/03/27 03:44:51
  103.27.239.27/32:22           1/3     2018/03/27 05:45:14
 188.165.68.135/32:22           1/3     2018/03/27 09:37:50
   93.99.147.90/32:22           1/3     2018/03/27 10:30:17
 175.139.146.66/32:22           1/3     2018/03/26 11:37:21
  82.200.205.71/32:22           1/3     2018/03/26 14:00:04
   45.65.140.20/32:22           1/3     2018/03/26 15:07:23
 203.217.56.210/32:22           1/3     2018/03/26 15:57:11
 125.212.248.37/32:22           1/3     2018/03/26 20:18:44
 138.68.149.171/32:22           1/3     2018/03/27 01:27:35
113.162.168.211/32:22           1/3     2018/03/27 03:45:08
  121.28.142.44/32:22           1/3     2018/03/26 10:34:26
  211.23.154.14/32:22           1/3     2018/03/26 17:02:02
159.203.191.201/32:22           1/3     2018/03/27 02:42:08
  69.162.101.38/32:22           1/3     2018/03/27 07:42:27
  213.58.172.26/32:22           1/3     2018/03/26 20:16:36
  91.121.77.149/32:22           1/3     2018/03/26 17:57:03
  81.149.95.177/32:22           1/3     2018/03/26 22:31:34
```


----------



## SirDice (Mar 27, 2018)

Oops, it should be `blacklistctl dump -b`, not -d.


----------



## Lamia (Mar 27, 2018)

Here is a non-exhaustive list of blacklisted IP addresses by bruteforceblocker.


----------



## max21 (Mar 28, 2018)

SirDice, I know how to use the blacklistd dump command, I just like to know where is that list kelp.  It seems that it’s inside the kernel because I can’t find it anywhere.  SSHGuard has his in /var/db/sshguard. According to the docs the way FreeBSD blacklistd works got the be the strongest of them all, however here is a part of my list that show where something went wrong – it missed.  It make me think that although SSHGuard works at a higher level it don't miss.  I also notice that I only been running blacklistd, I forgot to include SSHGuard but thought I had it running.  Question:  Is it possible to run both blacklistd and sshguard?

```
192.169.155.230/32:22           1/3     2018/03/21 20:47:57
92.222.119.202/32:22           1/3     2018/03/21 18:35:53
  103.26.99.120/32:22           1/3     2018/03/21 17:49:03
   14.23.77.154/32
211.72.203.250/32:22           1/3     2018/03/21 02:55:32
190.147.88.247/32:22           1/3     2018/03/21 22:45:08
  178.22.48.137/32:22           1/3     2018/03/21 13:28:53
```

About something else; since those last few hits I posted above I never got hit again … so I commented out this line the same day and iirc I still did not get hit or if I did it was few and far between, like 36 hours for one.  The reason I remove this rule is that I was asked why would I even want to open up the ssh port to the world.  Even today, it’s still commented-out.

I'm guessing that this solved that problem?  If so, that could be the reason why I didn’t get any more hits.  I should have wrote something down as a reminder, I did that for everything else.

```
# # # pass in quick on $_nic proto tcp from any to any port 22
```

Anyway, I figure I’ll keep everything in place just incase I want to peep in on it in the future for some reason such as rechecking those moves.  THEN what I did was to change the port number and now I know for sure . . . me and my auth.log are so lonely.  I get board of seeing nothing everyday.  I forgot the reason of ordering the VPS in the first place.

So for contentment until I get fired up again I’m reading SSH(1) until I can recite it.  Right now it’s scary!  Until I know why to tamper with or disable hosts.equiv, rhosts and rlogin/rsh protocol, I’m going to stick with using a super strong password until I know how to divide and use keys at home and use password at the library.  I see now SSH(1) is no play toy.  You have to read it at least 15x to get it half-right and that is what I’m going to do.

So to sum it all up changing ports WON .. but blacklistd without the pass out rule seem to keep on working or ssh just got shutdown in the foreground or something.  Maybe they all are working together because I have TOTAL silence to date.  Not even a port-scan.



> Here is a non-exhaustive list of blacklisted IP addresses by bruteforceblocker.


Lamia, I ended up with more then half of that list.  It's not as large as I thought.  No offence but I heard about all of those oriental countries trying to hack the world, but Vietnam?  That takes the cake.  Maybe we doing the same to them, but how am I suppose to know.  Or maybe not because no one can ... Ahaa, they got the Great Firewall.


----------



## SirDice (Mar 28, 2018)

max21 said:


> No offence but I heard about all of those oriental countries trying to hack the world, but Vietnam?


Most of these aren't "hackers" trying to break in. They've been infected with malware and it's the malware that does the scanning. The owners of those systems are most likely not even aware of it. 



max21 said:


> Or maybe not because no one can ... Ahaa, they got the Great Firewall.


Looking at the huge list of IP ranges belonging to ChinaNet I block that Great Firewall isn't doing much. 
If you're interested, this is the list, I don't have Chinese visitors on my site so it's not an issue for me to block them preemptively. 


```
chinanet="{119.28.0.0/16,117.21.0.0/16,202.109.128.0/28,183.0.0.0/18,222.186.0.0/10,111.72.0.0/12,220.175.0.0/16,220.176.0.0/16,220.177.0.0/16,115.239.248.0/24,218.56.0.0/14,61.153.104.0/24,61.153.105.0/24,1.93.0.0/16,211.142.128.0/17,144.0.0.0/16,111.0.0.0/10,221.228.0.0/14,116.52.0.0-116.55.255.255,59.44.0.0-59.47.255.255,221.192.0.0/14}"
```


----------



## max21 (Mar 28, 2018)

Thanks SirDice, the quicker I get off my ridiculous theories the better, but now I know the facts.  I just checked top and I notice that pflogd and blacklistd are as active as he*l.  Exchanging chances to hit the top of the list pretty darn fast.  Something going on, and syslogd is in the mix too.  I better reboot so I can monitor resource usages for the next few days.  It good to have two nodes to play with.  I got enough faith to turn-off pf and/or blacklistd logging if need be because I know darn well it’s working.

edit: I'll take that back.  PF and blacklistd is empty.  It's just expecting.  Port change must be in control.


----------



## max21 (Apr 2, 2018)

ShelLuser said:


> In addition to what gkontos said: do you really need your SSH port to be publically open?
> 
> I also can't help wonder what authentication method you're using, don't tell me you rely on username / passwords?  Because that's basically a kiddie magnet in itself, it gives the kiddiots the idea that all they have to do is put in enough guesses in order to eventually get somewhere. Authenticate by keys and the whole thing becomes much less appealing.
> 
> ...




In my last few post I been trying to figure out what was actually blocking ssh attacks since I was trying nearly everything here at once.  Yesterday, it hit me. When to use? What to use? And why?.  ShelLuser already told me!  OK,   I’ll get ssh-keygen working latter.

For home access only; you HAVE to or should change the port-number .. then add the THIRD well-known `pf rule` below.  Since I don’t yet own a static-ip for home this command is using my provider IP _Comcast_. I thought I had to make my local IP work.  Now I wonder if this could be another security issue for being inside the providers pool and not fully direct?  Pure PF to the rescue.


```
_nic   =  "em0"
## anchor "blacklistd/*" in on $_nic

# ########################################################################################
pass in quick on $_nic inet proto tcp from 11.22.33.44 to $_nic port = ssh flags S/SA keep state label "USER_RULE: Allow SSH from 11.22.33.44"
# ########################################################################################

  pass in quick on $_nic inet proto icmp all icmp-type echoreq
# pass in quick on $_nic proto tcp from any to $_nic port 2222
```

Thanks for this super crash-course into networking +.

Over and out!


----------

