Local Message bypassing MX

One solution would be to move all the sites using the external mail service to another IP address on the server - and then firewall off port 25 on that IP address for all except the external mail service IPs. That way if the spammers tried to get the “A” records for the domain they’d be denied.

Paul

That’s a great idea!

One more thing, when I view the headers of one of these spam messages, I see this:

Received: from unknown (HELO cmwyzqtn) (87.123.129.69)
by host.designchemistry.com with SMTP;

host.designchemistry.com is our server’s hostname and points to our main server IP but our mail records all point to a different IP. Since I can’t tell by viewing the header exactly which IP they’re sending to,
would the best strategy be locking down port 25 on the existing IP we use for our mail records, and then change all the non-filtered domains mail records to the new IP address? I’m thinking this would be better since the spammers already have that IP. If we change it and lock the new one down, they could still send through on the original IP, right?

Yes, that’s right, they may still use the old IP and it would still work. So, that’s a fine idea, the only downside is the extra pain of moving potentially more sites (depending on how many use the external service vs how many don’t). But that may be moot.

Paul

Okay, with the APF firewall I was going to block port 25 for just this one IP and allow only MX Logic IPs to that port. I see how to add a rule to allow_hosts.rules so it specifies the inbound port and the IP the traffic is coming from but I don’t see a way to specify the inbound IP address the traffic is coming through. So, I’m not sure how to make this work now. Any ideas?

I’m still trying to get some help with APF firewall. Does anyone know if I can block/allow to a specific port AND IP address on my server?

And, if someone has specific information, please post it instead of sending it as a private message which keeps everyone on here from seeing the solution. Maybe shahzadmasih is just a “spammer” in disguise since he does have links to his sites in the signature.

shahzadmasih taken care of. Thanks guys. :slight_smile:

Whoisjb,

If you take a look in /etc/apf/allow_hosts.rules, you should see some text explaining the more advanced allow/deny rules you can set:

advanced usage

The trust rules can be made in advanced format with 4 options

(proto:flow:port:ip);

1) protocol: [packet protocol tcp/udp]

2) flow in/out: [packet direction, inbound or outbound]

3) s/d=port: [packet source or destination port]

4) s/d=ip(/xx) [packet source or destination address, masking supported]

Syntax:

proto:flow:[s/d]=port:[s/d]=ip(/mask)

s - source , d - destination , flow - packet flow in/out

Examples:

inbound to destination port 22 from 192.168.2.1

tcp:in:d=22:s=192.168.2.1

outbound to destination port 23 to destination host 192.168.2.1

out:d=23:d=192.168.2.1

inbound to destination port 3306 from 192.168.5.0/24

d=3306:s=192.168.5.0/24

also, from the APF readme (http://rfxnetworks.com/apf/README):

Advanced trust usage; The trust rules can be made in advanced format with 4
options (proto:flow:port:ip);

  1. protocol: [packet protocol tcp/udp]
  2. flow in/out: [packet direction, inbound or outbound]
  3. s/d=port: [packet source or destination port]
  4. s/d=ip(/xx) [packet source or destination address, masking supported]

Flow assumed as Input if not defined. Protocol assumed as TCP if not defined.
When defining rules with protocol, flow is required.

InterWorx “understands” these advanced rules, so you should be able to use these advanced rules and not worry about them getting overwritten by NodeWorx. For example, you could set a deny rule to something like (this is an example, it’s probably not the exact rule you need):
d=25:d=192.168.5.10

Assuming that 192.168.5.10 is an IP on your server, that should block inbound packets destined to port 25 on 192.168.5.10.

Thanks. I did see those rules but I just wasn’t sure if you could do both d=25:d=192.168.5.10 since all the examples show a destination port and a source IP for incoming traffic. I’ll give this a try. Any suggestions on how to test this without accidentally blocking all incoming mail traffic?

First, turn on APF devel/debug mode just to be safe.

Try telneting to port 25 on your server, from your local machine, and make sure you get some sort of connection.

Then, try blocking a specific IP in the deny rules, like your own IP address:

d=25:s=YOUR_IP

Then try telnet again and make sure you can’t connect this time. Similarly, you can do:

d=25:d=1.2.3.4

where 1.2.3.4 is an IP on your box. Then you’d test “telnet 1.2.3.4 25” and “telnet 1.2.3.5 25”, where 1.2.3.5 is another IP on your box. If the deny rule is working properly, you’ll be able to telnet to 1.2.3.5, but not 1.2.3.4.

Hope that helps,
Socheat

It’s working! Thanks for the help, I really appreciate it.