On 5/18/2018 10:42 AM, Alberto José García Fumero wrote:
Im trying to block spam (for instance, from 185.234.217.232). As far as I know, it's trying to pass as a message from my very net: Transcript of session follows. De: Mail Delivery System <mailer-dae...@partagas.ettpartagas.co. cu> Para: Postmaster <postmas...@ettpartagas.co.cu> Asunto: Postfix SMTP server: errors from unknown[185.234.217.232] Fecha: Fri, 18 May 2018 10:10:39 -0400 (CDT) Out: 220 partagas.ettpartagas.co.cu ESMTP Partagas In: EHLO 190.6.79.98 Out: 250-partagas.ettpartagas.co.cu Out: 250-PIPELINING Out: 250-SIZE 15240000 Out: 250-ETRN Out: 250-STARTTLS Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: AUTH LOGIN Out: 503 5.5.1 Error: authentication not enabled Session aborted, reason: lost connection For other details, see the local mail logfile but the MTA correctly rejects it as a fake.
It might not be good to describe what happened here as your MTA rejected the connection as a fake. If your MTA is configured to reject a connection because the EHLO contains your IP address (which is unlikely), that isn't what happened here.
Your MTA returned a 503 error to the sending server because your MTA is not configured to accept an AUTH login. 250-AUTH is not part of its response to the EHLO. Most mail servers accept AUTH only on port 465 or port 587.
I have created an alias list (rechaza) in the menu Firewall/Aliases, where I put all the addresses known to be spammers, and tried to reject them with the rule in Firewall/Rules/WAN Action: Block Interface: WAN TCP/IP version: IPV4 Protocol: TCP Source: (single hots or alias) rechaza Destination: 190.6.79.98 Destination port range: any but I can not stop the spam right in the WAN interface.
If you take a look at Status > System Logs > Firewall and notice what you see for Source and Destination this can help you understand better how filtering and NAT works. For your WAN interface, Source will be the public IP of the origin of the packet. If there is no port forwarding configured for the destination port, no NAT occurs so the destination address will be your public IP. If port forwarding is configured for the destination port, then NAT does apply and the destination address will be your LAN IP. It helps to keep this in mind when developing rules.
It is a good idea to not be too specific with rules. Since you are running a mail server you must have port 25 forwarded to the mail server LAN IP. Because of NAT for port 25, specifying your public IP 190.6.79.98 as the destination prevents the rule from matching. Because of NAT, to have a match you would need to have the mail server LAN IP as the destination.
You probably want to block the IP from going to any destination though regardless of whether the destination port is forwarded or not. So in your rule you want
Destination: any instead of
Destination: 190.6.79.98
If you were to add another LAN interface to pfSense in the future the rule will continue to match then as well.
If you are intending to block all traffic, not just TCP, from the source, you want
Protocol: any On 5/18/2018 12:52 PM, Alberto José García Fumero wrote:
Could I create a rule saying, for instance: "reject packets originating (apparently!) from the WAN address and directed to my WAN address? (as they are trying to forge identity)
This is unnecessary. There is no way for a system on the Internet to establish a TCP connection that apparently originates from your WAN address.
If you are running a mail server or anything else that faces the Internet, hopefully you are using snort or suricata and are just trying to supplement with your own rules. There is no way you could maintain an effective list of addresses to block with just your own rules. You should also be using anti-spam measures on your mail server as well.
- John J. _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
