Jak mogę używać symboli wieloznacznych dla sendmaila TLS_Rcpt?

9

sendmail pozwala na jedno miejsce na ograniczenia w rozmowach TLS. Chcę sprawdzić, czy wiadomości wysyłane do example.com są wysyłane na serwer, który ma certyfikat * .messagelabs.com. Chcę chronić przed fałszowaniem DNS i MitM. Jeśli messagelabs miałby tylko jeden serwer, byłoby to łatwe:

TLS_Rcpt:example.com VERIFY:256+CN:mx.messagelabs.com

Jednak messagelabs ma wiele serwerów i klastrów różnych serwerów z unikalnymi adresami IP i certyfikatami dla tej samej nazwy. Wszystko w porządku, chcę tylko sprawdzić, czy serwer, na który wysyłam pocztę, jest certyfikowany jako należący do messagelabs.

próbowałem

TLS_Rcpt:example.com VERIFY:256+CN:messagelabs.com
TLS_Rcpt:example.com VERIFY:256+CN:*.messagelabs.com
TLS_Rcpt:example.com VERIFY:256+CN:.*.messagelabs.com

ale dostaję błędy jak

CN mail31.messagelabs.com does not match .*.messagelabs.com

W jaki sposób mogę to zrobić? To jest dla nas powtarzające się żądanie (głównie dla konfiguracji takich jak TLS_Rcpt: example.com VERIFY: 256 + CN: *. Example.com), więc byłbym gotowy zmodyfikować sendmail.cf, ale nie mam sensu

STLS_req
R $| $+         $@ OK
R<CN> $* $| <$+>                $: <CN:$&{TLS_Name}> $1 $| <$2>
R<CN:$&{cn_subject}> $* $| <$+>         $@ $>"TLS_req" $1 $| <$2>
R<CN:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " CN " $&{cn_subject} " does not match " $1
R<CS:$&{cert_subject}> $* $| <$+>       $@ $>"TLS_req" $1 $| <$2>
R<CS:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " Cert Subject " $&{cert_subject} " does not match " $1
R<CI:$&{cert_issuer}> $* $| <$+>        $@ $>"TLS_req" $1 $| <$2>
R<CI:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " Cert Issuer " $&{cert_issuer} " does not match " $1
ROK                     $@ OK

Sendmail 8.14.7 (wkrótce aktualizacja do wersji 8.15.2)

Law29
źródło
Tak więc, brak odpowiedzi (jeszcze?) Sam spróbuję na nie odpowiedzieć, ale nie jestem pewien, czy jeden dzień poświęcony integracji rozdziału 28 książki sendmaila wystarczy, czy nawet dałby odpowiedź.
Ustawa
2
Nie mam wystarczającej pewności, aby udzielić ostatecznej odpowiedzi, ale nie sądzę, że symbole wieloznaczne są obsługiwane zgodnie z sekcją „Ograniczenia w bieżącym wdrażaniu” tego postu na blogu: security-skywalker.blogspot.com/2013/01/…
Mike B,
... i tak, wiem, że „certyfikaty symboli zastępczych” różnią się od funkcji wzorców dopasowywania symboli zastępczych, których szukasz, ale artykuł podkreśla statyczny charakter tej funkcji. :-)
Mike B,
Być może twoja odpowiedź nie jest ostateczna, ale jest najlepsza, jaką znalazłem (z jakiegoś powodu nie znalazłem tego wpisu na blogu, dziękuję za zwrócenie mojej uwagi)
Law29,
Czy chcesz przetestować obsługę tagu CNRE? Sprawdziłby $ & {cn_subject} względem niestandardowego wyrażenia regularnego.
AnFi

Odpowiedzi:

1

Ustaw sklep sendmail.cf ${cn_subject}z rozebraną częścią hosta ${cn1_subject}.
To sprawia, że ​​zakończenie implementacji jest prawie banalne.

OSTRZEŻENIE: Zapytaj o opinie news:comp.mail.sendmailprzed wdrożeniem go w środowisku nie testowym. MOŻE działać, ale sendmail sprawia, że ​​unikanie „nieoczekiwanych efektów ubocznych” DUŻO żmudności, niż jestem gotów „zainwestować”. „Testowałem na sucho” za pomocą sendmaila 8.15.2.

dostęp do wpisu:

TLS_Rcpt:example.com VERIFY:256+CN1:messagelabs.com

sendmail.mc poprawka do obsługi powyższego wpisu

OSTRZEŻENIE: pamiętaj o TAB (\ t) między RHS i LHS w Rliniach.
Jest to bardziej brudna implementacja sendmail.mc tylko przez .

define(`_LOCAL_TLS_RCPT_')dnl
LOCAL_RULESETS
SLocal_tls_rcpt
R$*     $: $&{cn_subject}
R$-.$+  $@ $(macro {cn1_subject}  $@ $2 $)
R$*     $@ $(macro {cn1_subject}  $@ $)    

# Ruleset continued
STLS_req
R<CN1:$&{cn1_subject}> $* $| <$+>               $@ $>"TLS_req" $1 $| <$2>
R<CN1:$+> $* $| <$-:$+> $#error $@ $4 $: $3 " CN-1 " $&{cn_subject} " does not match " $1
ROK                     $@ OK
divert(0)dnl

Wyjaśnienie:

  1. Utwórz Local_tls_rcptsklep ${cn_subject}z ustalonymi regułami z rozebraną częścią „przed pierwszą kropką”${cn1_subject}
  2. Dodaj kontrole ${cn1_subject}wyzwalane prefiksem CN1 w „dodatkowej części” zestawu TLS_reqreguł

Przykładowy skrypt do przetestowania

#!/bin/sh
# -C sendmail-test.cf -- use non standard cf file
# -d60.5 -- trace (access) map lookus
# -d21.12 -- trace R lines rewriting 
sendmail -C sendmail-test.cf -bt -d60.5 <<END
.D{verify}OK
.D{cn_subject}mail31.messagelabs.com
.D{server_name}mail31.messagelabs.com
tls_rcpt [email protected]
END
AnFi
źródło
Zaakceptowałem to, chociaż jeszcze tego nie przetestowałem; dokładnie to, co uważałem, musi być możliwe, ale nie udało mi się dowiedzieć, jak to zrobić.
Prawo 29
1

To nie jest dokładnie odpowiedź na postawione pytanie, ale wydaje mi się, że robisz wszystko na poważnie.

Konfiguracja Sendmail została napisana w taki sposób, że priorytetem jest łatwość i wydajność oprogramowania analizującego tę konfigurację, a nie łatwość konfiguracji i konserwacji przez ludzi. W ostatnich dziesięcioleciach po prostu nie było dobrego powodu, aby to zrobić.

Sendmail był okropnie tajemną reliktem 15 lat temu. Niektóre dystrybucje linuksa nadal domyślnie to zapewniają, i to jest w porządku, jeśli domyślna konfiguracja działa dla Ciebie, ale gdy tylko znajdziesz coś, co zajmuje więcej niż kilka minut, najlepiej wyrzucić sendmaila i zainstalować nowoczesny MTA .

Jakieś 15 lat temu qmail mógł nadal być rozsądnym zamiennikiem, ale przez prawie tak długi czas uważałem postfiks za lepszy wybór. Dokumentacja ze strony postfix.org jest dobra, gdy znajdziesz potrzebny bit. W twoim przypadku będziesz potrzebować http://www.postfix.org/TLS_README.html dla tego problemu.

Zdaję sobie sprawę, że najprawdopodobniej spędziłeś już trochę czasu na rozwiązywaniu kilku problemów z sendmailem, ale zamiast tracić więcej czasu w tej dziurze, zmieniaj przy najbliższej okazji. Jeśli kiedykolwiek spojrzysz za siebie, skulisz się.

Mc0e
źródło
Właściwie administruję Postfiksem dłużej niż administracją Sendmail, z powodów $, i dzisiaj mam około 16 podstawowych serwerów Sendmail w pasywnie dostosowanym środowisku, które nie jest takie łatwe do zmiany. Uaktualnienie do ostatniej wersji to kwestia minut, ale zmiana to inna sprawa. Jednak masz rację, że użycie postfiksu „smtp_tls_policy_maps” zawierającego „przykład.com bezpieczne dopasowanie = .messagelabs.com” wydaje się zapewniać bezpieczeństwo, którego szukam. Ten przypadek użycia może faktycznie dać mi powód, dla którego muszę poświęcić czas niezbędny na zmianę.
Prawo 29