Jan Engelhardt wrote:
Hmm, many people, including myself, think, that filtering in OUTPUT is
pointless. More troublesome than usefull. If you decide to set OUTPUT
policy to ACCEPT, you don't need the first two rules. Up to you.
Not at all. Because certains things can not happen in certain environments,
e.g. I read/write mail by logging into a mail server via SSH / no sendmail
running, I can exclude certain things. In netfilter parlance:
-P OUTPUT ACCEPT (same for FORWARD, btw)
-A OUTPUT -j REJECT -p tcp --dport 25
This stops users that also have access to my machine to not spam smtp servers,
should they find an open one.
(Be sure you also restrict access to any sendmail(1)-style mail
injection binary in that case, if there's an MTA running.)
True, you have illustrated one example of sane OUTPUT filtering. The
OP's use of OUTPUT filtering was not in this category.
Note that OUTPUT filtering only controls non-root users. A root user can
disable or bypass it. If you have local shell users who cannot be
trusted, and if you didn't already understand all this, chances are
those users already have rooted you. :)
I agree with Joerg above. I don't think you have contradicted his
general point. Netfilters should:
1. Learn to walk before they try to run
Rule of thumb: if you need to post here to try to get explanations
of what your rules are doing, you're not ready for OUTPUT filters.
2. Only experiment with carefully-crafted OUTPUT rules
3. Generally not attempt "iptables -P OUTPUT DROP" (see #1.)
--
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header
