Securing internal aliases and lists
Per Steinar Iversen
to be few useful answers:
How does one secure internal aliases so that only those
IP networks or domains that are allowed by an access db can post to lists?
The usual answers seems to be:
1) Use Local_check_rcpt
The problem with this is that is called before check_rcpt,
a careless implementation would thus give less protection than
what check_rcpt already already can give.
2) Use a list manager.
These can usually be fooled by using the mail address
of somebody on the list.
Recently I have seen more and more spam posted to various
lists, it seems that this problem is getting worse.
Any ideas, or even better, rulesets that works well?
-psi
Neil W Rickert
>How does one secure internal aliases so that only those
>IP networks or domains that are allowed by an access db can post to lists?
>The usual answers seems to be:
>1) Use Local_check_rcpt
If you use it to check IP address or hostname of the connecting
system, to see if it is in your network, this can work reasonably
well.
>The problem with this is that is called before check_rcpt,
>a careless implementation would thus give less protection than
>what check_rcpt already already can give.
It is hard to accidently give less protection. The bigger risk is
that you will prevent mail to ordinary users from outside the
network.
Unless "Local_check_rcpt" returns an answer of the form "$# mailer",
it is ignored. So just have it return "$# error error-message" for
unallowed attempts to send to a local alias, and return something
else (or roll of the end of the ruleset) in other cases.
>2) Use a list manager.
>These can usually be fooled by using the mail address
>of somebody on the list.
Right.
>Recently I have seen more and more spam posted to various
>lists, it seems that this problem is getting worse.
The completely reliable method is to use a list manager, and make
all lists moderated. That way, a human has to check.
Per Hedeland
PerSteina...@adm.hioslo.no (Per Steinar Iversen) writes:
>How does one secure internal aliases so that only those
>IP networks or domains that are allowed by an access db can post to lists?
>
>The usual answers seems to be:
>
>1) Use Local_check_rcpt
>
No, this is a feature.:-)
>a careless implementation would thus give less protection than
>what check_rcpt already already can give.
The interface is such that it should be easy to avoid this - from
cf/README:
These rules are called with the original arguments of the corresponding
check_* ruleset. If the local ruleset returns $#OK, no further checking
is done by the features described above and the mail is accepted. If the
local ruleset resolves to a mailer (such as $#error or $#discard), the
appropriate action is taken. Otherwise, the results of the local
rewriting are ignored.
I.e. just make sure you never return $#OK, and you can only
reject/discard or fall through to the standard ruleset.
>2) Use a list manager.
>
>These can usually be fooled by using the mail address
>of somebody on the list.
>
>Recently I have seen more and more spam posted to various
>lists, it seems that this problem is getting worse.
Are they really faking the sender address to be one on the list too? I
haven't seen that (yet), but find that type of "closed lists" (that are
becoming ever more common of course) rather cumbersome - people may want
to post from another address than the one they have subscribed with, or
the subscribed address is actually a local redistribution alias /
newsgroup gateway etc.
Of course for a "real" public mailing list, limiting based on sending
host won't work. On the other hand, for an internal alias, limiting on
sender address is probably OK - the member addresses aren't likely to be
known by spammers, and the issues with alternate addresses etc should be
less of a problem. But using sending host would be more secure, of
course.
>Any ideas, or even better, rulesets that works well?
Claus has some suggestions at:
http://www.sendmail.org/~ca/email/protected.html
--Per Hedeland
p...@erix.ericsson.se
Per Steinar Iversen
>In article <slrn8ht81q.rvh.P...@elbonia.p52.hioslo.no>
>PerSteina...@adm.hioslo.no (Per Steinar Iversen) writes:
>>How does one secure internal aliases so that only those
>>IP networks or domains that are allowed by an access db can post to lists?
>>
>>The usual answers seems to be:
>>
>>1) Use Local_check_rcpt
>>
>>The problem with this is that is called before check_rcpt,
>
>No, this is a feature.:-)
>
>>a careless implementation would thus give less protection than
>>what check_rcpt already already can give.
>
>The interface is such that it should be easy to avoid this - from
>cf/README:
>
> These rules are called with the original arguments of the corresponding
> check_* ruleset. If the local ruleset returns $#OK, no further checking
> is done by the features described above and the mail is accepted. If the
> local ruleset resolves to a mailer (such as $#error or $#discard), the
> appropriate action is taken. Otherwise, the results of the local
> rewriting are ignored.
>
>I.e. just make sure you never return $#OK, and you can only
>reject/discard or fall through to the standard ruleset.
Aha!
So, something like this should work? :
F{ProtAlias}/opt/sendmail-8.10.1/access/aliases
SLocal_check_rcpt
# If the alias is not listed in {ProtAlias}, pass on to check_rcpt
R$+ $: <@> $>3 $1
R<@> $={ProtAlias}<@$=w.> $: <$1@$2>
R<@> $={ProtAlias} $: <$1@$j>
# Not a protected alias, so exit this rule
R<@>$+ $@ NOPROTALIAS
# Alias is listed, is the client IP in the access db?
R$* $: $&{client_addr}
R$* $: $>LookUpAddress <$1> <?> <$1> <+Connect>
# Allowed IP address, so exit this rule
R<RELAY> $* $@ RELAY
# Alias protected and IP not in access db, exit with error
R$+ $#error $: 550 $&f not allowed to send to recipient
>Of course for a "real" public mailing list, limiting based on sending
>host won't work. On the other hand, for an internal alias, limiting on
>sender address is probably OK - the member addresses aren't likely to be
>known by spammers, and the issues with alternate addresses etc should be
>less of a problem. But using sending host would be more secure, of
>course.
True, but these lists are all internal, but sadly exposed so far.
Since about 12k persons have access to these lists they are not
particularly secret!
-psi
Per Hedeland
PerSteina...@adm.hioslo.no (Per Steinar Iversen) writes:
>
>So, something like this should work? :
>
>F{ProtAlias}/opt/sendmail-8.10.1/access/aliases
>
>SLocal_check_rcpt
># If the alias is not listed in {ProtAlias}, pass on to check_rcpt
>R$+ $: <@> $>3 $1
>R<@> $={ProtAlias}<@$=w.> $: <$1@$2>
>R<@> $={ProtAlias} $: <$1@$j>
># Not a protected alias, so exit this rule
>R<@>$+ $@ NOPROTALIAS
># Alias is listed, is the client IP in the access db?
>R$* $: $&{client_addr}
>R$* $: $>LookUpAddress <$1> <?> <$1> <+Connect>
># Allowed IP address, so exit this rule
>R<RELAY> $* $@ RELAY
># Alias protected and IP not in access db, exit with error
>R$+ $#error $: 550 $&f not allowed to send to recipient
Yes, from a quick read-through, that seems fine - assuming of course
that you only want to allow those hosts that have their IP address /
"subnet", with a RHS of RELAY, in the access db. The error (I know it's
the same as in Claus' examples) is of course a bit misleading, as you
aren't denying the sender address but the sending host - but that may be
a feature too...:-)
(You might also want to allow "local connections", i.e. basically
someone running 'sendmail -bs' from the commandline - from the
"standard" rules:
# check IP address
R$* $: $&{client_addr}
R$@ $@ RELAYFROM originated locally
R0 $@ RELAYFROM originated locally
)
--Per Hedeland
p...@erix.ericsson.se
Per Steinar Iversen
>
>Yes, from a quick read-through, that seems fine - assuming of course
>that you only want to allow those hosts that have their IP address /
>"subnet", with a RHS of RELAY, in the access db. The error (I know it's
>the same as in Claus' examples) is of course a bit misleading, as you
>aren't denying the sender address but the sending host - but that may be
>a feature too...:-)
>
>(You might also want to allow "local connections", i.e. basically
>someone running 'sendmail -bs' from the commandline - from the
>"standard" rules:
>
># check IP address
>R$* $: $&{client_addr}
>R$@ $@ RELAYFROM originated locally
>R0 $@ RELAYFROM originated locally
I added those and got:
SLocal_check_rcpt
# If the alias is not listed in {ProtAlias}, pass on to check_rcpt
R$+ $: <@> $>3 $1
R<@> $={ProtAlias}<@$=w.> $: <$1@$2>
R<@> $={ProtAlias} $: <$1@$j>
# Not a protected alias, so exit this rule
R<@>$+ $@ NOPROTALIAS
# Alias is listed, is the client IP in the access db?
R$* $: $&{client_addr}
R$@ $@ RELAY originated locally
R0 $@ RELAY originated locally
R$* $: $>LookUpAddress <$1> <?> <$1> <+Connect>
# Allowed IP address, so exit this rule
R<RELAY> $* $@ RELAY
# Alias protected and IP not in access db, exit with error
R$+ $#error $: "550 " $&f " not allowed to send to this recipient from " $&{client_addr}
Now this work well if the mail is sent directly to the list.
However, if there are more recipients than just the list,
then this fails. Presumably this means that the lookup
of protected aliases is not clever enough and is confused
by more than one address at a time. Any ideas?
-psi
Per Hedeland
>
>However, if there are more recipients than just the list,
>then this fails. Presumably this means that the lookup
>of protected aliases is not clever enough and is confused
>by more than one address at a time. Any ideas?
It should work fine with list + other - [Local_]check_rcpt is called
once for each RCPT command, i.e. it will never get more than on address
and the RCPT giving the list will be rejected, the others allowed -
isn't that what you want? You aren't trying to give multiple recipients
in a single RCPT command (while testing manually), are you - in that
case you need to read up on SMTP.:-)
--Per Hedeland
p...@erix.ericsson.se