Prevent users from smtp other than main mail server

I have firewall/NAT router/mail server on a static IP, and a small network behind it. One of the internal computers caught a spamming worm, and now my static address is blacklisted. I’m going to fix that one computer but I’d also like to block any other attempt at spamming from my network.

My server if SuSE 9.2. Is there an option in SuSEfirewall2 to prevent users from internal network to connect to any computer other that the server itself (talking only about the smtp port)?

If there is no such option, then how can I do it manually from iptables? These manual settings shouldn’t interfere with or be overridden by SuSEfirewall2 settings.

I Googled for a while on this, but couldn’t find anything. Found only some other guy asking the same question without getting the answer SuSE: [SLE] How to block Win-hosted spamming worms with SuSEfirewall2.

Your 9.2 server is the gateway, right?

What you need to do is to put an iptables DROP rule ahead of the NAT rule so that SMTP is dropped and not allowed to NAT. A different way is to put an input rule saying that hosts on the LAN cannot use SMTP except for the one destination address of the gateway. This one is shouldn’t be position dependent. Something like, in pseudo-code:

if source == LAN and dest == not gateway and port == 25 then drop

I don’t know if this can be done with SuSEfirewall2. You may have to resort to a custom rule. I don’t know whether the custom rule can be inserted the right place.

OK, I guess there’s no such option in SuSE firewall. The iptables rule is simple,

iptables -I FORWARD 1 -p tcp --dport smtp -j DROP

. The only question is where to put it? When I change some firewall option from YaST my rule disappears from iptables.

Where should I place my rule so that it doesn’t interfere with SuSE firewall, and not be overridden by it?

It’s so many releases ago but wasn’t there a place to put CUSTOM rules in /etc/sysconfig/SuSEfirewall2?

Yes, there is such place! I placed my rule in section fw_custom_after_antispoofing, in chain forward_int, and it seems to be working. Thank you. And you’re right about the the version, maybe it’s time for an upgrade :slight_smile: