I don't mean to come across as a "Pedantic Troll". I think you are correct in terms of the application, of letting others pay X for the appearance of using the public IP space and in this content, the problem and solution would make sense. This is NOT how I interpreted or even envisioned the problem from the stated definition, which was decidedly lacking in details. I envisioned a form of corporate network with remote users connecting via VPN to access shared resources. In this regard, the choice of words does matter and except for this fact, I don't care what we call it.

I think you meant to have:
Note the -j which needs to be followed by the action to take.
Similarly, one could use:
Note the inversion on the address, meaning if NOT 127.0.0.1, then drop it with log.

None of these rules will cover the case of a "VPN user" from spamming root or the OP.

I still assert, however, that if this type of activity is a problem that using a firewall is alone is not a safe approach but that they really need to address this issue in Sendmail too. This is a matter of proper network security practice. Unfortunately, when confronted with things that they don't want to hear, the novice user often times ignores the advice. Often times this is followed with return posts of "help my system has been compromised".

My apologies, that was not aimed at you - it was a generalisation of how 'religious' some people are about such matters.


Indeed, but having some fire-walling is a good starting point and it's better to have it, than not to have it IMHO. It certainly will drop the SMTP packets the OP wants dropped, but as you indicate more savvy users may be able to 'break in' if they are so inclined.

As for Sendmail, personally I've not used it for some time so I cannot speak of it as an MTA or it's place in the security of things - other than to mention that I believe it is considered insecure by people with a much better systems level knowledge than I posses.

Perhaps some ideas on how to better secure the OP's box would be more useful than to wave fingers and tut? I'm sure you have a great deal of experience and can positively contribute to tightening it up for the OP.

yep, and its why simple L4 filters are kinda useless these days. we need to use tools that "know" what the stream looks like 4-7. palo alto seems to be doing a ok job of that.

why would this "VPN" be able to send anything outbound? whats the purpose of this "VPN"? i will assume that "all of my outbound ports are open" is meant to mean "i do not filter any outbound destination udp or tcp ports".

i think OP means he does not filter any outbound connectivity, hence a wide open outbound pipe from any of those "VPN" segments. so if someone has a IP from one of those segments they could connect tcp-25 (or any port) to a external server. i think thats what he means, a tad confused when he mentions sendmail.

if the "server" is used as a gateway then i guess the allowed ports it provides needs to be defined. block all, allow few might be an ok approach. allow just src=VPN dst=tcp-443, tcp-80, udp-53. do the "VPN" clients need anything more than that (this says "no smtp for you")? if the server itself has sendmail then obviously it needs dst=tcp-25 and sendmail should be configured correctly to keep vpn'ers from using it.

Correct.

Correct, not at the moment.

That was the issue, I was trying to block port 25 but only for the VPN network.
Then there were a few posts about just blocking outgoing port 25.
I have sendmail on the server sending emails out as necessary but I don't want a VPN user to be able to use the tunnel to send anything out form their client on port 25, 2525, or other.
So, I need to allow my legitimate emails out but drop any email spam by the client (this however blocks all their email clients too).

So, would it be best to block as follows:

iptables -A OUTPUT -p tcp --dport 25 -s 10.8.0.0/24 -j DROP
iptables -A OUTPUT -p tcp --dport 25 -s 172.16.0.0/24 -j DROP
plus add other ports

I guess I cannot use 127.0.0.1 because when a user is connected via VPN, they will be in the network?

127.0.0.1 is a non route-able address that designates the loopback address on the NIC card itself. As long as you are not giving your users the IP address of the server, you should be able to allow this address without problem. Ideally, you should be giving them a designated block of addresses in their own subnet.

In actuality, the more I think about your situation, the more I wonder if you wouldn't be best served by using a filtering proxy on the gateway for your users. This would restrict them to use of http and https traffic, as well as any others you chose to allow, such as ftp. As I said, ideally you will be giving them a designated block of addresses that is reserved for this purpose. You should then separate YOUR personal and business systems from this block, at least logically.