Redirect outbound SMTP traffic to internal 'mail trap' system
-
@Bob-Dig Do you have the proper NAT rules to do that redirection? Right now we have 48 subnets for individual infections (VLANned off from each other) and need to redirect the port 25 traffic (and 465 and 587, which is just SSL and not SNI/verificed on most malware SMTP senders) to the endpoints. The problem is, even if we global it (i.e. Source: Any private IP, Dest: Any, port: WAN) it still doesn't properly get rerouted in the port forward rules.
The problem here is what should work with any forwarder rules is not working for forwarding, and I'm a little lost.
Right now V607 is the test network segment, if we can get it to work for v607 then we can apply it globally, but even a global catchall doesn't work to redirect the traffic it just goes into the void and the packets don't end up at the destination system (I checked in tcpdump with packet watching) and don't get handed off from the pfSense with the port forwarding NAT rule when it's observed.
-
@teward said in Redirect outbound SMTP traffic to internal 'mail trap' system:
Right now we have 48 subnets for individual infections (VLANned off from each other) and need to redirect the port 25 traffic (and 465 and 587, which is just SSL and not SNI/verificed on most malware SMTP senders) to the endpoints.
NAT rules can only be applied on the incoming traffic. So the rule doesn't work if it's on WAN, if the traffic is coming from inside your network.
If you have multiple interfaces to apply the same rule, just create an interface group, add all concerned interfaces to it and than select the if group in the NAT rule. Set the source to any or even RFC 1918 and the destination to any, dest port = 25.
However, consider that this doesn't work if source and target are within the same network segment. In this case you would have to masquerade the traffic additionally by an outbound NAT rule.
-
@viragomann Fortunately, none of those Malware systems are in the same network segment, but they are all private IPs.
For testing though, I would expect this to work fine, which is what I did in a lab:
IFace: V607
Src: (RFC1918 ranges) (alias: Private_IPv4
Dst: ! Private_IPv4
Dst Ports: 25,465.587 (alias: Email_Ports)
Redirect: 10.0.1.123
Ports: Email_Ports... and this doesn't work either, it just hangs and it's not processed or redirected.
For all intents and purposes it should work as intended this way, but for some reason it's not. Traffic is being tested from a machine inside the v607 subnet so it SHOULD be processing traffic properly but it's not. Not sure where else to look... unless it's something in say the Ubiquity switches downstream that would be eating or preventing the traffic flow.
-
@teward
It should work at least with unencrypted traffic.Traffic is being tested from a machine inside the v607 subnet so it SHOULD be processing traffic properly but it's not.
What does this machine exactly? Where does it send SMTP packets to?
If you capture the traffic on this interface you should see the packets arriving.
If you can see incoming packets, but no responses, sniff the traffic on the outgoing interface facing to the target machine.Yes, ensure that your VLAN switches are not leaking, otherwise TCP connections will not work.
-
@viragomann said in Redirect outbound SMTP traffic to internal 'mail trap' system:
@teward
It should work at least with unencrypted traffic.Traffic is being tested from a machine inside the v607 subnet so it SHOULD be processing traffic properly but it's not.
What does this machine exactly? Where does it send SMTP packets to?
If you capture the traffic on this interface you should see the packets arriving.
If you can see incoming packets, but no responses, sniff the traffic on the outgoing interface facing to the target machine.Yes, ensure that your VLAN switches are not leaking, otherwise TCP connections will not work.
This machine on v607 is just a test machine, for testing this rule it's got me generating an SMTP connection to what should be GMail's servers using Python's SMTPLib on port 25. I haven't specified encryption or StartTLS on this case so it should be able to go through as SMTP Plain or at least to initiate the socket connection without timing out or failing. Wiresharking the source machine shows no response packets, just more SYNs and retries.
On the pfSense system, capturing traffic on the VLAN/Interface of ingress sees the packet traffic attempting to traverse (SYN) to Gmail's mail servers. Switching to the destination subnet (v601, which is not in the portgroup for a global rule) for listening shows that nothing is being relayed onto that subnet where the mail trap is present, nor does tcpdump on the mail trap system show any incoming packets.
It's almost as if Sense is unable to forward them for some reason. Despite the port forward rules looking right. Which baffles me.
-
@teward said in Redirect outbound SMTP traffic to internal 'mail trap' system:
It's almost as if Sense is unable to forward them for some reason.
I cannot think of any reason, why this should not work.
If you see the packets on the incoming interface, but not on the expected outgoing, the traffic must be either blocked or wrongly routed in pfSense.
Do you a rule to allow the traffic? Maybe an associated filter rule. -
@viragomann said in Redirect outbound SMTP traffic to internal 'mail trap' system:
@teward said in Redirect outbound SMTP traffic to internal 'mail trap' system:
It's almost as if Sense is unable to forward them for some reason.
I cannot think of any reason, why this should not work.
If you see the packets on the incoming interface, but not on the expected outgoing, the traffic must be either blocked or wrongly routed in pfSense.
Do you a rule to allow the traffic? Maybe an associated filter rule.We have rules that match this as follows:
in the new Malware_Subnets group (easier than floaty rules) that should permit SMTP and other email related ports per the linked NAT rule, but then deny other cross-VLAN talking between those subnets can't interact with each other and make one massive set of megainfections.
There's a floating rule also that allows all internal ranges access to the Internet, so malware infections function as expected and non-Malware ranges where we have infra, etc. separate can also talk out (Ubiquity switches to Unifi SDN or such for config fetching, etc.).
It is however my understanding that wouldn't break this type of traffic from flowing though?
-
@teward
This rule doesn't show any hit. So it obviously wasn't applied.
Do have a floating block rule, which could match to the incoming traffic by any chance?If you're unsure enable the logging in all concerned rule and check the filter log then.
-
@viragomann I only just redid that section and it's lunchtime, there haven't been any hits yet since i moved the rules into the subnet grouping. I'm going to obtain lunch then check back and test - there were hits on the NAT rule initially when it was one subnet but since we've narrowed it down to rules I may temporarily disable some rules and see what happens and then work backwards to determine what broke where. Assuming I can get the initial connections working (which should be doable thanks to NAT now)
-
@viragomann said in Redirect outbound SMTP traffic to internal 'mail trap' system:
@teward
This rule doesn't show any hit. So it obviously wasn't applied.
Do have a floating block rule, which could match to the incoming traffic by any chance?If you're unsure enable the logging in all concerned rule and check the filter log then.
Well, heck, I guess the Floating Rules were the problem. By removing the floating rules and putting them in the group itself rather than having floaty rules for the prevention of inter-vlan stuff it "just works" now.
Just tested and though the SMTP destination in the test was
smtp = smtplib.SMTP("google.com", 25), it properly ended up in the mail trap. Cool!So, ye, combo of NAT and Floating Rule things that broke it all. Figures.
Thanks to all who helped!
-
Lets hope it is for a good cause.
