h3xed 0 Zgłoś post Napisano Marzec 23, 2012 Witam, Mam serwer pocztowy oparty na postfix-ie 2.x, od wczoraj występuje problem zapychania kolejki przez wysyłanie emaili z obcych domen. Wczoraj kolejkę zapchało 65k emaili wsyłanych z domeny gmail.com, dzisiaj natomiast sytuacja się powtarza z adresu info@sender.com. Co to może być ? Jakiś backdoor na serwerze ? Jak zblokować możliwość wysyłania emaili z domen które nie są dodane do postfixa, lub zblokować konkretną domene ? Z góry dziękuje za pomoc ! Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Marzec 23, 2012 Może Twój postfix jest openrelay? Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Marzec 23, 2012 Zmieniłeś configa? Z defaulta nie pozwala na open relay. mynetworks = 127.0.0.1/32 relay_domains = twoja.domena.com smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, permit Oczywiście to jest najprostsze zabezpieczenie. Warto albo nawet trzeba dodać inne restrykcje. Udostępnij ten post Link to postu Udostępnij na innych stronach
h3xed 0 Zgłoś post Napisano Marzec 23, 2012 (edytowany) Nie mam w confingu "relay_domains", za to jest relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 213.17.226.145 213.17.***.130 Oraz smtpd_recipient_restrictions = cidr:/etc/postfix/client_cidr, # reject_sender_login_mismatch permit_mynetworks, permit_sasl_authenticated, check_policy_service inet:127.0.0.1:10023, #permit reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_checks_my, check_sender_access proxy:pgsql:/etc/postfix/sender_checks_my.cf, # reject_invalid_helo_hostname warn_if_reject reject_non_fqdn_helo_hostname, warn_if_reject reject_unknown_helo_hostname, warn_if_reject reject_unknown_client, # reject_non_fqdn_sender # reject_non_fqdn_recipient reject_unauth_pipelining, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_rbl_client multi.uribl.com, reject_rbl_client dsn.rfc-ignorant.org, reject_rbl_client dul.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client combined.rbl.msrbl.net, reject_rbl_client rabl.nuclearelephant.com, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, warn_if_reject reject_rhsbl_sender dsn.rfc-ignorant.org, warn_if_reject reject_rhsbl_sender abuse.rfc-ignorant.org, warn_if_reject reject_rhsbl_sender whois.rfc-ignorant.org, warn_if_reject reject_rhsbl_sender bogusmx.rfc-ignorant.org, warn_if_reject reject_rhsbl_sender postmaster.rfc-ignorant.org, check_sender_mx_access cidr:/etc/postfix/mx_access.cidr, check_helo_mx_access cidr:/etc/postfix/mx_access.cidr, check_client_access regexp:/etc/postfix/blacklist_clients, check_sender_access regexp:/etc/postfix/blacklist_senders permit smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce, permit Dodam jeszcze, że z tego serwera korzysta ~250 domen a całością administruje poprzez postfixadmin. Edytowano Marzec 23, 2012 przez h3xed (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
h3xed 0 Zgłoś post Napisano Marzec 23, 2012 Zalazłem takie wpisy w logach serwera: Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abo.el.sex@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=2 8942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abo.osama1@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=2 8942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<aboawadh@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=289 42-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abodeograce@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id= 28942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abohra20032003@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=28942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abo.shahim@hotmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id =28942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abo_ayoub10@hotmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, i d=28942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abo_elswalf@hotmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, i d=28942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) Mar 23 09:39:09 tukan postfix/smtp[28919]: DD575107A396: to=<abo_fahd2000@hotmail.com>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=7, delay=22, delays=7.4/13/0/1, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=28942-01-7, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D48AC107A3A4) I tak tysiące lini... Sytuacje zdaje udało się uratować poprzez odpowiednią modyfikacje: smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_unknown_hostname, reject_non_fqdn_hostname permit Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Marzec 23, 2012 (edytowany) Po pierwsze to co wkleiłeś nie ma związku z tym, że ktoś przez Twój serwer wysyła maile na adres @gmail.com. Jeśli nie masz nic ustawionego w configu to korzysta z defaultowej konfiguracji, sprawdź postconf -d|grep relaydomain Z defaulta wskazuje na $mydestination. A loga co wkleiłeś to tylko pokazuje, że z 127.0.0.1:10025 (prawdopodobnie amavis - strzelam bo standardowy port) mail został zakolejkowany z powrotem do postfixa. Sprawdź całość wiadomości jak wygląda #grep DD575107A396 maillog Edytowano Marzec 23, 2012 przez Syndrom (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
h3xed 0 Zgłoś post Napisano Marzec 23, 2012 Po pierwsze to co wkleiłeś nie ma związku z tym, że ktoś przez Twój serwer wysyła maile na adres @gmail.com. Jeśli nie masz nic ustawionego w configu to korzysta z defaultowej konfiguracji, sprawdź postconf -d|grep relaydomain Z defaulta wskazuje na $mydestination. A loga co wkleiłeś to tylko pokazuje, że z 127.0.0.1:10025 (prawdopodobnie amavis - strzelam bo standardowy port) mail został zakolejkowany z powrotem do postfixa. Sprawdź całość wiadomości jak wygląda #grep DD575107A396 maillog Ale ja nie piszę, że serwer wysyła na gmail.com tylko, że z mojego serwera wchodzą emaile zawierające domenę gmail.com jako nadawce. Udostępnij ten post Link to postu Udostępnij na innych stronach
Syndrom 95 Zgłoś post Napisano Marzec 23, 2012 Wczoraj kolejkę zapchało 65k emaili wsyłanych z domeny gmail.com, dzisiaj natomiast sytuacja się powtarza z adresu info@sender.com. Wyraźnie napisałeś wysyłanych z domeny gmail.com. Dobra to nie możesz sprawdź, kto z Twojej sieci, który user to robi? Może rzeczywiście w sieci masz jakiegoś robaka, o którym user nawet nie wie. Udostępnij ten post Link to postu Udostępnij na innych stronach
