Blocking Public IPs

[amd.64]

I have recently installed and setup my own Spam server using Xeams. If it matters I also have my own MS Exchange Server.

Almost as soon as I brought the spam server online I started getting notices that an IP address in Romania was trying to access the spam server. I assumed they were trying to access the configpage, but when I checked the logs they were trying to access it through port 25 (SMTP). I assume to send out spam.

In an attempt to stop their attempts I created firewall rules to block that IP address, however I am still getting notifications that this same IP is attempting to access my server.

Can someone verify that I have configured these rules correctly. They have an IP 4 address so the either one of these rules should work. I have checked on Spamhaus website, the IP in question is on their list, at least twice.

 

[amd.64]

I have a block of five IPs and would like to block on all five

[EricPerl]

Look for an established connection in Firewall > Diagnostics > States.
If the connection was not blocked before establishment, no amount of new rules is going to affect that traffic.
You can delete the state from there.
And then verify in the firewall logs that further attempts at re-establishing the connection fail.

[amd.64]

The IP address in question does not currently have an established connection.

I last received the notification email about an hour ago as I type this. The notification does tell me that the IP in question has been blocked for 10 minutes.

The full message in the notification email is as follows. Every time I receive the notification it is the same IP Address removed.

"Too many invalid login attempts made from X.X.X.X. This IP has been blocked for the next 10 minutes. Someone from this IP is trying to connect to the Smtp Server on spam. Total attempts so far: 5"

[EricPerl]

Oops, given your use case, you probably have a NAT Port Forward rule.
I have not experimented with these much but you should be able to change the source to !blocked.
Alternatively, I suspect you have an associated firewall rule that could be adjusted as well.

[amd.64]

Right after I made my last post I reboot my firewall to make sure all connections were broken and good ones would need to be reestablished. There is currently no connection to or from the IP in question.

I have received three notifications since.

The firewall rules I post images of are the first two rules so, if configured correctly the connection should make it passed the first one, or the second if it some how gets pass the first. Which  is why I would like some one to verify whether I have configured them correctly.

[EricPerl]

I experimented with port forwarding some more.
You must have a port forwarding rule from WAN address to your internal server.
In my tests, I was able to block an IP by either:
* Changing the source in the NAT port forward rule (!Blocked) directly, which actually updates the associated FW rule.
* Placing a FW rule above the FW rule associated with the NAT forwarding rule (on WAN, featuring your internal server and internal port, that can't be edited).
Note that this rule is a bit tricky because it applies AFTER the NAT rule has applied (hence the internal characteristics).

In the logs, when the connection is established, you first see the redirect rule it (blue in live log when successful, rdr in plain log).
Then the FW rules are evaluated.

Given your rules don't bother with destination, you can't really have an issue with the external/internal aspect.
Maybe they are placed below the FW rule associated with the NAT rule?

[Patrick M. Hausen]

Or if the firewall rule association in the NAT rule is set to "pass" that takes precedence over any explicit firewall rules.

So either follow @EricPerl's suggestion to change the source for that port forward to something like "! blocked" - "blocked" being an alias you create, or change from "pass" to explicitly associated rule.

Reason being that processing order is:

All NAT --> floating rules --> interface rules.

[EricPerl]

Thanks Patrick. I saw that option but forgot to take it into account...
I just used the default "add associated rule". It seemed so much safer. And seeing it made creating a precise override way easier.
With pass, no FW rule, no override possible...

[amd.64]

All NAT --> floating rules --> interface rules.

I understand what you are saying. What I don't understand is why NAT isn't last in the order of processing. Seems that if a specific rule for a specific IP or IPs or specific list are desired to be block no matter what port they are coming in on they should be processed before any thing else.

My rules for blocking the IP in question (alias Blocked_IPs) and the rules for blocking list from spam haus are the first three rules (below the automatically created one) including the spam haus list for IP6.

I have altered my NAT rule. Images of both FW rules to show order and priority and NAt rule are attached.

[EricPerl]

The rule precedence is documented and accommodates your scenario...
I know I'm in no position to argue the pros and cons of one approach versus another. And changing the behavior is likely a non-starter at this point.
OTOH, I'm in a position to know that rule ordering HAS TO be left to the users. And "specificity" when comparing aliases is a nightmare.

At the bottom of the port forward rule, there's a "filter rule association". If instead of pass, you opt for an explicit rule, then that rule appears in the FW rules list... It appears you can insert a block ahead of that rule.

[Patrick M. Hausen]

It appears you can insert a block ahead of that rule.

Or use source invert to get a "! blocked" rule as suggested already. It's probably more transparent and better to understand a few months from now to do it in an associated firewall rule than in the NAT rule itself.