WAN Attackers handling

NogBadTheBad

@bambos They’ll be blocked by default unless you port forward to devices to your LAN.

Bambos

@nogbadthebad yes, i can understand that if there is no rule to allow, will be blocked. And also i know that on pfSense, by default everything is blocked.

But, most of the times, most people have some ports open or allowed (for example openVPN), with port forward or not (for example FTP).

Why let the attacker continue trying ? This is my point.

KOM

@bambos All that should be done from your application server. A port is a port, they're either open or closed. The traffic has to hit the firewall before the firewall can figure out what to do with it, so you can't stop attackers from hitting your open ports.

Bambos

@kom thanks for your comment. That is acceptable and you are right. any open port is somehow attack surface.

My question: is it possible on pfSense to have a more "smart" package to detect continuously blocked attempts from a specific source IP and permanent block it. (Like other enterprise firewalls do).

what about snort or suricata ?

KOM

@bambos I'm not aware of any integration like that, where an app server tells pfSense to block an IP if it fails too many app server logins.

NogBadTheBad

@bambos Either would do, if you port forward.

Cool_Corona

I block them on WAN if they try to scan the FW for open ports.

And I run Pfblocked with GeoIP blocking enabled.

It takes care of 99% of scriptkiddies and portbangers.

Bambos

@cool_corona said in WAN Attackers handling:

I block them on WAN if they try to scan the FW for open ports.

And I run Pfblocked with GeoIP blocking enabled.

It takes care of 99% of scriptkiddies and portbangers.

Block them on WAN? How ? manually ? or you have pfblocker functionality for that ?

Cool_Corona

@bambos Suricata

Gertjan

@bambos said in WAN Attackers handling:

Is there any way to block source IP if they do so much retries ?

"Blocking " like not reaching your pfSense device ?
That is not possible.

What pfSense does, as any other router : it just ignores new, incoming traffic.
All of it.
You might say that this ignoring looks like blocking. But the traffic comes in.

If you really want to 'block' == traffic doesn't even reach you, you should take control of the device in front of your pfSense. Most probably some hardware that your ISP is using. You'll agree with me : that won't happen.

So, no need for suricata, snort or whatever program or firewall rule : the default WAN NIC behaviour is already perfect : it will 'record' the incoming traffic. And then it discards that data. Done.
Why spending CPU cycles on non wanted traffic ??

Things change a bit when you want to host a service, and it should be accessible to the world.
Like, for example, a mail server.

So you 'open ' port 25 - TCP, and have the traffic redirected to a LAN device that is your mail server. You have to create a NAT rule (for simplicity, I presume IPv4 tarfic).

Now your mail server gets bombarded with some valid mail traffic and pure BS traffic like :

May  7 08:53:17 ns311465 postfix/smtpd[11978]: lost connection after RCPT from sm1.emverifyengine.com[51.254.229.236]
May  7 08:53:17 ns311465 postfix/smtpd[11978]: disconnect from sm1.emverifyengine.com[51.254.229.236]
May  7 08:53:17 ns311465 postfix/smtpd[11968]: connect from sm2.emverifyengine.com[51.254.229.237]
May  7 08:53:17 ns311465 postfix/smtpd[11968]: lost connection after RCPT from sm2.emverifyengine.com[51.254.229.237]
May  7 08:53:17 ns311465 postfix/smtpd[11968]: disconnect from sm2.emverifyengine.com[51.254.229.237]
May  7 08:53:17 ns311465 postfix/smtpd[11978]: connect from unknown[203.159.80.233]
May  7 08:53:17 ns311465 postfix/smtpd[11978]: lost connection after AUTH from unknown[203.159.80.233]
May  7 08:53:17 ns311465 postfix/smtpd[11978]: disconnect from unknown[203.159.80.233]
May  7 08:53:18 ns311465 postfix/smtpd[12868]: connect from unknown[45.133.1.149]
May  7 08:53:18 ns311465 postfix/smtpd[12868]: lost connection after AUTH from unknown[45.133.1.149]
May  7 08:53:18 ns311465 postfix/smtpd[12868]: disconnect from unknown[45.133.1.149]
May  7 09:53:18 ns311465 postfix/smtpd[13599]: connect from cluster-d.mailcontrol.com[85.115.60.190]

Take note : This was a one (1) second mail log of my mail server.
Now it's time to enter tools like fail2ban.

Normally, a mail or web server is not placed behind a router like pfSense.
For educational reasons you might do so - we all did that ones.
When done with learning, your put them on a dedicated host, some where in a data centre. As you don't want to maintain such a server (massive hardware, raid drives, many giga bytes of RAM, double power block, expensive processor) feed it (electricity !!) and cool it (airco).
These kind of servers always run - never stop. And that's never like in never.
Also, a mail server behind an ISP type IP is 'not done' (read : won't work : yahoo, gmail, hotmail etc won't send you any mail - and will not accept mail from you).

To make the long story short : fail2ban parses the web, mail and all other server logs, and when it finds suspected entries like the ones shown above, blocks the IP for xxx time.
Or, more fancy : when it detects an IP several times within xx minutes doing something that is not valid traffic, it blocks.

This is what happens. I only block IP's for 3 days or so. if I blocked IP's longer, the firewall rule set would became 'just to big'.
And that's for IPv4. IPv6 is still rather quiet these days. That will change ....

Btw : fail2ban exists for FreeBSD, not for pfSense. As it would have to run on the device on which runs the mail or web server.

Bambos

@gertjan thank you very much for your comments. you help me get things going.
It seems that maybe there is a way to use abuseipdb through the pfblockerNG plugin.

Gertjan

Just keep in mind :

pfSense is a SOho type router firewall.
This means : it handles outgoing connections, none or very few incoming connections. What I mean : you're not hosting any server type of application on your local networks, so you have no "NAT/PAT" rules.
In this case : Your WAN interface does what it has to do : they drop silently any incoming unknown traffic. This is one of the core principles of a state-full firewall.
This is the perfect case of : you doing nothing to have the perfect setup. The setup is perfect the moment you install pfSense.

Bambos

@gertjan Hello Sir,

i have realize that pfSense by default has WAN locked down.

But i'm not using it as a Ho, i'm using it as a So, and also i'm running web services (FTP port forward and and some allowed ports on WAN for VPN's)

Because the FTP i'm using is simple, most probably they see my traffic through sniffing and try to connect.

I don't think pfSense lacks something. If i had "enterprise" firewall, the problem will remain.

So i'm looking for something to detect the sequencial failed retries. pfblockerNG and suricata is something that i also examine.

Bambos

@cool_corona

how you can block with suricata ? today i had an incident again, from a specific IP brute forcing specific port. How to make autoblock in such cases ? You can see that same source IP was retrying the same port.

Can this be done with suricata as you mention ?

Gertjan

@bambos

Why did you remove the Source IP list ? You want to protect the attacker ?

You can never make some device somewhere on the WAN interface stop sending traffic to you. Not in this world.
That is, if you do not want traffic from

to arrive on your WAN interface, you have to block it upstream.

Bambos

@gertjan yes Sir i understand what you say, my question is about the pfsense firewall itself. of course priority is correct firewall rules , that i believe are in place. this is the first and most important and we agree.

What i'm asking is the ways we can derease the amount of those incidents. IF for example a bot or human is bruteforcing vpn key or user password, and hit the correct port (if firewall keep accepting retries - which shouldn't) then this is a security concern. An adaptive add to block for random attacks would be great (like most commercial firewalls doing) - most times paid.

So:

firewall rules on WAN
pre-block upfront IP's that are known as bad reputation. This can be done with pfblocker for example, Geo IP blocking etc.
adaptive blocking when someone does the attack specified.

Can you reccomend something as added functionality ? perhaps suricata or pfblocker or other method or package ? ? Thanks for any suggestions.

Gertjan

@bambos said in WAN Attackers handling:

a bot or human is bruteforcing vpn key

A human ? Thousands of generations won't be able to do that.
A bot ? Even with a big uplink, all the mainframes combined of all the 3 letter agencies won't be able to that in this decade.

VPN : do not only use a user + password. Use also TLS, and you'll be fine.

pfblocker can block upfront known 'bad' IP addresses. If the IP is listed.
suricata, if it recognizes ( a rule has to be crated that does this) the VPN connect attempts, might intercept the traffic and have it hit a firewall rule created for the occasion.. Cant' tell you more about it, never used suricata.

johnpoz

@bambos you sure that is just not out of state traffic?

What is the source of that traffic? You sure you didn't go there, and then the states got reset..

Seems highly unlikely to be hitting some rando high port from source of 443 as any sort of "attack" or probe..

Bambos

@johnpoz oh i see what you mean, it might be access from my network that requested this kind of traffic, right ?
I don't think is possible, because the blue source have scanned my whole /29 block. So most probably is not caused from my Lan. Same as the blue source.
So now the green source, made the same thing and include port 21 also.

I'm not stating that i'm under attack or something, I'm saying that those kind of patterns are to be suspicious activity from the source. Why not log the source ip, auto-block and publish this ip for others to be informed ?

is this something pfblockerNG supposed to do ?
Is there any other method to perform this kind of auto-block ?

johnpoz

@bambos those are ALL SYNs (S)... Those others were ACKS - and from 443.. And all to 1 random high port.. Now even close to the same thing..

6379 is redis (common exploitable port), which is common scan for port. 21 (ftp), etc..

You don't see that is different then coming from port 443 (https port)..

See how the source port is some high port that is all different...

Yes you connect to the public internet - your going to see NOISE.. There is NOTHING you could do about that traffic - nothing!! Its all blocked... If you had open ports you were forwarding, and you don't want some china IP able to talk to it, then say limit your open ports to only the countries you want to allow.. I allow for example only IP from US to talk to my plex server port, because all my users are only going to be in the US..

What was the IP that was 443 as the source? Now you got me curious..