Being hacked, block drop quick not blocking

U

urbanriot

While using my desktop I suddenly found that my user account was locked out due to numerous failed attempts at logging into my administrator account on my server. I checked the Windows' Server's eventlog and found that someone was denied entry using Rdesktop, the linux RDP client while I'm on mostly Windows' computers. Hmm...

# tcpdump -n dst port 3389 -e -ttt -i pflog0
Code: 
00:00:00.000000 rule 11..16777216/0(match): rdr in on igb0: 123.123.123.88.7081 > 192.168.1.10.3389: Flags [SEW], seq 277331287, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.000037 rule 34..16777216/0(match): pass out on igb1: 123.123.123.88.7081 > 192.168.1.10.3389: Flags [SEW], seq 277331287, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:02.983868 rule 11..16777216/0(match): rdr in on igb0: 123.123.123.89.53983 > 192.168.1.10.3389: Flags [SEW], seq 1904643054, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.000023 rule 34..16777216/0(match): pass out on igb1: 123.123.123.89.53983 > 192.168.1.10.3389: Flags [SEW], seq 1904643054, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Okay, so there's my culprit (I modified the IP addresses), this is an ongoing attempt at bruteforcing into my server.

So I create a new file called pf.hackers and add their IP addresses to it. Then I add the following lines in my pf.conf in the appropriate areas.

Code: 
table <hackers> persist file "/etc/pf.hackers"

block drop log quick on $ext_if from <hackers> to any
block drop log quick on $ext_if from any to <hackers>

# pfctl -F all -f /etc/pf.conf

Unfortunately despite all that I'm seeing a 'match' in my logs with the above code I pasted and I'm wondering what I'm doing wrong since block drop quick was supposed to be processed before my rdr.

Any help would be appreciated!
 
Interesting... so it seems this was the solution... ?

Original:

Code: 
block drop log quick on $ext_if from <hackers> to any
block drop log quick on $ext_if from any to <hackers>

Fix (?):

Code: 
block drop log quick from <hackers> to any
block drop log quick from any to <hackers>

So the block drop quick doesn't block the rdr on $ext_if, so I needed to block it on the other NIC:
Code: 
00:00:01.933679 rule 11..16777216/0(match): rdr in on igb0: 123.123.123.89.58623 > 192.168.1.10.3389: Flags [SEW], seq 2449828246, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:00.000046 rule 11..16777216/0(match): block out on igb1: 123.123.123.89.53983 > 192.168.1.10.3389: Flags [SEW], seq 2449828246, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
00:00:02.995880 rule 11..16777216/0(match): block out on igb1: 123.123.123.89.53983 > 192.168.1.10.3389: Flags [SEW], seq 2449828246, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Can someone more knowledgeable educate me as to what I got wrong in thinking I could block it on the external interface?
 
And this is why you should never allow access to 3389 from the internet.
 
urbanriot said:
It's actually redirected from 2001 but thanks for playing!
Click to expand...
As you already found out, it doesn't really matter on what port you're running it. The bad guys are going to find it. Never assume that a service won't be found just because you're running it on a non-standard port.

urbanriot said:
any insight into my pf question or no?
Click to expand...
Yes, kill the access, period. Use SSH's port forwarding if you need to RDP to a machine from outside the network. Or set up VPN access.
 
Sigh. Obviously you're unaware that out in the real world RDS servers have port 3389 open to the internet, but that has nothing to do with my query and your responses are foolishly missing a considerable amount of additional information such as 2FA, emailed alerts, etc.. The reason I know this was occurring is due to an email and text I received after a number of failed attempts at logging in, nevermind the alerts I would have received if they made it past that to the 2FA stage. Above all that none of this even matters as this was a temporary setup to test the idea of using freebsd VMs to replace some equipment.

Seriously though, my question was regarding pf and not this superfluous direction...

In summery it seems my question was does a rdr pass trump a block quick?
 
Try posting your entire pf.conf file. Remember that NAT and RDR rules are first match and Filter rules are last match. With only a snippet of your pf.conf file, nobody is going to be able to help because we can't see the complete logic flow of your firewall rules.
 
urbanriot said:
In summery it seems my question was does a rdr pass trump a block quick?
Click to expand...

From man pf.conf(5):

Packets that match a translation rule are only automatically passed if the pass modifier is given, otherwise they are still subject to block and pass rules.

So yes, ‘rdr pass’ rules trump block/pass rules. You can use it without the pass directive, and subject it to the filter rules, but you may need to add the appropriate rules where you want it to succeed.
 
Here's the deal, the original post was written late for me so my articulation and comprehension of rules were not the best. Furthermore I've spent more time with Cisco and alternative firewalls so my pf experience is limited to a home pf firewall (which has robustly protected my home network for years).

The hacker's target was focused on what I'd call a toy firewall in front of a lesser used RDS server with 2FA, email alerting, and a password for the software inside the RDS server in a production environment setup a few weeks back to evaluate the possibility of replacing an expensive bank of Cisco FIREpower equipment down the road. My idea was to evaluate how stable a freeBSD pf VM with PCI Passthrough on the NICs would be, how it would handle traffic, and how well it would / would not scale, etc., as there's some logic with pf that seems to offer features that you can't get with expensive firewall equipment and/or would be moderately cheaper via pf.

As such I'm dynamically rewriting the rules from scratch as required to learn the logic while combating activities that I'm monitoring in realtime.

Datapanic said:
Remember that NAT and RDR rules are first match and Filter rules are last match.
Click to expand...

Eric A. Borisch said:
So yes, ‘rdr pass’ rules trump block/pass rules. You can use it without the pass directive, and subject it to the filter rules, but you may need to add the appropriate rules where you want it to succeed.
Click to expand...

I was familiar with the order and have since pulled out the rdr pass into individual rdr's and pass's to make them clearer. Perhaps later I'll combine them with reverse logic along the lines of:
Code: 
rdr pass log on $ext_if inet proto { tcp udp } from !<hackers> to ($ext_if) port 2001 -> $rdserver port 3389

However my question was concerning block quick, so just to clarify regardless of whether or not I've blocked with the quick modifier, the pass within the rdr line will still trump it as the 'pass' is seen as an aspect of translation rather than filtering? As in, the block quick doesn't oppose the pass filtering because translation filtering rules are processed before standard filtering rules?

Thanks guys!
 
You must log in or register to reply here.
Back
Top