SSHGUARD logging attempts even though 22 is blocked?
-
I often see entries in my log such as:
Invalid user myuser from 11.22.33.44 port 40086 Attack from "11.22.33.44" on service SSH with danger 10. Failed password for invalid user myuser from 11.22.33.44 port 40086 ssh2 Attack from "11.22.33.44" on service SSH with danger 10. Received disconnect from 11.22.33.44 port 40086:11: Bye Bye [preauth] Disconnected from invalid user myuser 11.22.33.44 port 40086 [preauth] Attack from "11.22.33.44" on service SSH with danger 10. Blocking "11.22.33.44/32" for 240 secs (3 attacks in 0 secs, after 2 abuses over 297 secs.)I assume this attack is coming to my WAN interface since it's non-RFC1918. However, I have a rule restricting source access to port 22 on the WAN to my remote IP only. I've tested this from multiple other endpoints on the internet and none can reach SSH - only my IP address is in the SRC field.
This is the rule from 'pfctl -s rules', 123.123.123.123 is the pfsense, My_IP is my remote IP
pass in quick on ix0.5 reply-to (ix0.5 123.123.123.123) inet proto tcp from <My_IP> to (self) port = ssh flags S/SA keep state label "USER_RULE: WAN allow admin" label "id:1602206417" ridentifier 1602206417Are these login attempts somehow getting around the firewall to attempt a login?
-
@Troutpocket vs 1 specific rule that sure might limit to a source. We have no idea what interface that is on.. other than a vlan 5 on ix0
How about just a picture of your wan rules, and do you have any floating rules?
-
-
@Troutpocket the only rules showing any triggers on that are your icmp rule. and your bogon block.
Simple test - go to like can you see me . org and run a test to 22..
What does it say?
To be honest that first rule should be wan1Wiline address. not this firewall. which is every IP on the firewall.
Why are you changing this IP to be 11.22.33.44 if its some rando IP out on the internet? That sshguard warning could be coming in on any interface..
When you enable ssh (22) it would be listening on all IPs of pfsense - so the traffic could be coming in on any interface really. Since none of your rules allow on that interface, its safe to assume its coming in some other interface. The test from outside, the can you see me to your wan IP would validate that your rules are working as written where you only allow from your specific IP.
-
I've port scanned from many different locations with the same result:
22/tcp filtered ssh no-responseThe setup is a pair of 7100's in HA configuration. IX0 is the 10G SFP+ which is established as LAN. The two WAN's (WiLine and Comcast) are VLANs on that interface. Likewise, all the other VLANs are on IX0 except the CARP interface which uses one of the LAGG ports.
-
@Troutpocket and your still seeing sshguard? Maybe they are from before you put rules in place?
Keep an eye on your state table if your still seeing these logs. sshguard works by watching your auth.log - when it blocks it would put in a rule via the sshguard table.. so its not easy to see what interface the traffic came in on.
freebsd doesn't allow for sniffing on all interfaces at once with -i any or -i all etc..
So tracking down where this traffic is actually coming in might be a bit difficult. I would run multiple sniffs at same time with say tcpdump and looking for ssh traffic.
But as you have shown your rules are blocking traffic as they should.
edit:
you could try this... Create a floating match rule on "any" that logs.. This won't pass any traffic or anything so not a compromise to your current rules. But it should log the traffic which will give you the destination address and what interface it came in on.
I then tried coming in from box on my wlan, which was blocked by sshguard for failing.. But via the sshguard couldn't really see what interface traffic came in on or to what specific destination IP.. But with this match rule I could see that info..
Floating rules are evaluated before any interface rules.. So this should give you the info you need to see where the traffic is coming in so you could create a specific rule on that interface to block the traffic
-
@johnpoz said in SSHGUARD logging attempts even though 22 is blocked?:
freebsd doesn't allow for sniffing on all interfaces at once with -i any or -i all etc..
Though here you could pcap on ix0 and see all the traffic in every VLAN on it.
-
@stephenw10 said in SSHGUARD logging attempts even though 22 is blocked?:
Though here you could pcap on ix0 and see all the traffic in every VLAN on it.
true - that could be helpful... I think the match rule might be simpler than waiting for a sniff.. Were they using any other interfaces other ix0
-
@johnpoz said in SSHGUARD logging attempts even though 22 is blocked?:
I think the match rule might be simpler
I agree. That should show it quick enough.
An alternative, if the connections are happening fast enough, might be to dump the states created and filter them like:
[2.8.0-DEVELOPMENT][admin@cedev.stevew.lan]/root: pfctl -vvss | grep -A 4 :22 all tcp 172.21.16.22:22 <- 172.21.16.8:44260 ESTABLISHED:ESTABLISHED [2550671808 + 2147156224] wscale 7 [549496530 + 65792] wscale 7 age 00:02:42, expires in 24:00:00, 164:169 pkts, 15025:18617 bytes, rule 91, log id: df7c156500000000 creatorid: 4006bd43 reply-to: 172.21.16.1@em0 origif: em0You can then see what the original interface was and the rule number that created the state:
[2.8.0-DEVELOPMENT][admin@cedev.stevew.lan]/root: pfctl -vvsr | grep -A 3 @91 @91 pass in quick on em0 reply-to (em0 172.21.16.1) inet all flags S/SA keep state label "USER_RULE: Allow all ipv4+ipv6 via pfSsh.php" label "id:1643147168" ridentifier 1643147168 [ Evaluations: 557 Packets: 8830 Bytes: 2741203 States: 2 ] [ Inserted: uid 0 pid 78052 State Creations: 18 ] [ Last Active Time: Thu Sep 28 15:14:01 2023 ]An 'allow all' rule in this case. On an internal test box.
Steve
-
Ugh... missed an interface on the DMZ. It's a /27 routed through the WAN. There was a virtual IP assigned which was acting as a gateway for the network behind it. I failed to manually block the admin ports.
Thanks for helping me with my troubleshooting gymnastics!
