How to get PF and sshguard to stop this guy?

max21

Well-Known Member

Thanks: 24
Messages: 441

#1
... 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:
Code:
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:
Code:
# 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?
Code:
#.......................................................................#
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.
Code:
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.
Code:
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.
 
Last edited:
OP
OP
M

max21

Well-Known Member

Thanks: 24
Messages: 441

#3
lamia, you got my thinking cap on o_O

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!
 
OP
OP
M

max21

Well-Known Member

Thanks: 24
Messages: 441

#5
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.
 

ShelLuser

Son of Beastie

Thanks: 1,590
Messages: 3,450

#7
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

Well-Known Member

Thanks: 215
Messages: 353

#8

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,617
Messages: 28,158

#10
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:
Code:
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).
 
OP
OP
M

max21

Well-Known Member

Thanks: 24
Messages: 441

#11
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.

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.

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?

Code:
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.
Code:
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!
Code:
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
Code:
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

Administrator
Staff member
Administrator
Moderator

Thanks: 6,617
Messages: 28,158

#12
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.
 
OP
OP
M

max21

Well-Known Member

Thanks: 24
Messages: 441

#13
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!
 

aurora72

Active Member

Thanks: 1
Messages: 239

#14
Hello

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

pf.conf:
Code:
anchor "emerging-threats"
load anchor "emerging-threats" from "/etc/pf.anchors/emerging-threats"
/etc/pf.anchors/emerging-threats:
Code:
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

Administrator
Staff member
Administrator
Moderator

Thanks: 6,617
Messages: 28,158

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

aurora72

Active Member

Thanks: 1
Messages: 239

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

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,617
Messages: 28,158

#17
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.
 

aurora72

Active Member

Thanks: 1
Messages: 239

#18
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

Administrator
Staff member
Administrator
Moderator

Thanks: 6,617
Messages: 28,158

#19
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

Active Member

Thanks: 29
Messages: 173

#20
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.
Code:
# 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.

Code:
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.
 
OP
OP
M

max21

Well-Known Member

Thanks: 24
Messages: 441

#21
Hello

I run sshd and to keep intruders off I activated the PF like:
....
....
20.03.2018 16:01:12,879 sshd: error: PAM: authentication error for root from 59.63.166.104 via 192.168.1.120

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.
Code:
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.
Code:
(/)blacklistctl dump
        address/ma:port   id      nfail  last access
(/)
(/)blacklistctl dump -b
        address/ma:port   id      nfail  last access
(/)
 

gkontos

Daemon

Thanks: 464
Messages: 2,126

#22
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.
 
OP
OP
M

max21

Well-Known Member

Thanks: 24
Messages: 441

#23
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.
Code:
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

Active Member

Thanks: 29
Messages: 173

#24
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.
 
OP
OP
M

max21

Well-Known Member

Thanks: 24
Messages: 441

#25
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.
 
Top