[Wheezy] lost connection after CONNECT from unknown[unknown]

#1
Hi,

folgende Meldung erscheint alle 5 Minuten in der mail.log:
Apr 19 17:55:07 server postfix/smtpd[24553]: connect from unknown[unknown]
Apr 19 17:55:07 server postfix/smtpd[24553]: lost connection after CONNECT from unknown[unknown]
Apr 19 17:55:07 server postfix/smtpd[24553]: disconnect from unknown[unknown]
Apr 19 17:58:28 server postfix/anvil[24555]: statistics: max connection rate 1/60s for (smtp:unknown) at Apr 19 17:55:07
Apr 19 17:58:28 server postfix/anvil[24555]: statistics: max connection count 1 for (smtp:unknown) at Apr 19 17:55:07
Apr 19 17:58:28 server postfix/anvil[24555]: statistics: max cache size 1 at Apr 19 17:55:07
Kurz zur Anmerkung, es handelt sich um einen kleinen VPS von OVH ohne ISPConfig.

Als Hostname/Mailname wird server.example.com genutzt.

postconf -nf
access_map_reject_code = 554
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_mydomain = no
biff = no
body_checks = regexp:/etc/postfix/body_checks
bounce_queue_lifetime = 3d
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
delay_warning_time = 2d
header_checks = regexp:/etc/postfix/header_checks
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
invalid_hostname_reject_code = 554
mailbox_size_limit = 0
maps_rbl_reject_code = 554
maximal_queue_lifetime = 3d
message_size_limit = 104857600
mime_header_checks = regexp:/etc/postfix/mime_header_checks
multi_recipient_bounce_reject_code = 554
mydestination = $myhostname, localhost.localdomain, localhost
myhostname = server.example.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
nested_header_checks = regexp:/etc/postfix/nested_header_checks
non_fqdn_reject_code = 554
plaintext_reject_code = 554
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
reject_code = 554
relay_domains_reject_code = 554
relayhost =
smtp_tls_CAfile = /etc/ssl/private/ca-startssl-class1.pem
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_restrictions = permit_mynetworks, reject_unknown_client,
reject_invalid_hostname, reject_rbl_client zen.spamhaus.org, permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
reject_non_fqdn_hostname, reject_invalid_hostname, reject_rhsbl_client
rhsbl.sorbs.net, reject_rhsbl_sender rhsbl.sorbs.net, reject_rbl_client
opm.blitzed.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client
relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client
sbl.spamhaus.org, reject_rbl_client unconfirmed.dsbl.org, reject_rbl_client
list.dsbl.org, reject_rbl_client dynablock.njabl.org, reject_rbl_client
dialup.blacklist.jippg.org, reject_rbl_client opm.blitzed.org,
reject_rbl_client cbl.abuseat.org, reject_rbl_client multihop.dsbl.org,
reject_rbl_client dialup.rbl.kropka.net, reject_unauth_pipelining
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks,
reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, reject_unauth_pipelining,
reject_unauth_destination, reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client relays.ordb.org, reject_rbl_client opm.blitzed.org,
reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.easynet.nl, reject_rbl_client
unconfirmed.dsbl.org, reject_rbl_client dynablock.njabl.org,
reject_rbl_client dialup.blacklist.jippg.org, reject_rbl_client
cbl.abuseat.org, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination, reject_rhsbl_client rhsbl.sorbs.net,
reject_rhsbl_sender rhsbl.sorbs.net, reject_rbl_client relays.ordb.org,
reject_rbl_client list.dsbl.org, reject_rbl_client sbl.spamhaus.org,
reject_rbl_client unconfirmed.dsbl.org, reject_rbl_client list.dsbl.org,
reject_rbl_client dynablock.njabl.org, reject_rbl_client
dialup.blacklist.jippg.org, reject_rbl_client multihop.dsbl.org,
reject_rbl_client dialup.rbl.kropka.net, reject_rbl_client opm.blitzed.org,
reject_rbl_client cbl.abuseat.org, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
reject_unauth_pipelining
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 450
unknown_hostname_reject_code = 450
unknown_local_recipient_reject_code = 554
unknown_relay_recipient_reject_code = 554
unknown_virtual_alias_reject_code = 554
unknown_virtual_mailbox_reject_code = 554
unverified_recipient_reject_code = 554
unverified_sender_reject_code = 554
postconf -Mf
smtp inet n - - - - smtpd
submission inet n - - - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps inet n - - - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
pickup fifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
relay unix - - - - - smtp
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
($recipient)
hostname
server

hostname -f
server.example.com

cat /etc/mailname
server.example.com

Kann mir dabei jemand weiterhelfen?
 

nowayback

Well-Known Member
#2
hast du möglicherweise ein dns problem? connect from unknown kann mehrere ursachen haben. die warscheinlichste ist meiner erfahrung nach, das es ein problem mit dem dns server gibt. jedoch sollte dann hinter unknown noch die ip in eckigen klammern stehen. die lösung dazu wäre dann einfach gültige dns server einzutragen; entweder in die /etc/network/interfaces oder/und die /etc/resolv.conf
und um postfix da gar nicht in schwulitäten zu bringen reject_unknown_client
 
#3
Ich nutze unter anderem die Nameserver von Google, aber wie du schon sagtest sollte in der Regel dann die IP drin stehen, dies ist jedoch nicht der Fall. Was mich einfach wundert ist, dass die "Abfrage" alle 5 Minuten ist. Ich habe zuerst an das Monitoring von OVH gedacht, aber das weist sich korrekt aus:
Apr 19 21:00:12 bonjour postfix/smtpd[25432]: connect from 250.ip-37-187-37.eu[37.187.37.250]
Apr 19 21:00:12 bonjour postfix/smtpd[25432]: lost connection after CONNECT from 250.ip-37-187-37.eu[37.187.37.250]
Apr 19 21:00:12 bonjour postfix/smtpd[25432]: disconnect from 250.ip-37-187-37.eu[37.187.37.250]
 

nowayback

Well-Known Member
#4
das sieht nach einem monitoring aus. da wird eine verbindung hergestellt auf den port und bevor postfix es verarbeiten kann, auch wieder beendet. es gibt keinen fehlerhaften login oder sowas.
wenn du die dns server von google verwendest, sollte es generell kein problem geben. Was mich halt stört, ist der punkt das es keine ip dahinter gibt. was sagt denn rkhunter?
 

nowayback

Well-Known Member
#6
hmmm... wenn rkhunter jetzt wenig hilfreich ist:
ich hatte auch mal nen fall, da hatte nen kunde nen vserver und hatte zu wenig ram für amavis, postfix und co. und der lief in den gleichen fehler.

zur sicherheit: ein fehlerhafter reverse dns eintrag hatte bei einem anderen fall den gleichen fehler erzeugt, jedoch nur weil die leistungsgrenzen erreicht waren. D.h. hätte er mehr Ram gehabt, wäre der nicht ins Gewicht gefallen.
 
#7
Es ist ein sehr kleiner VPS mit 1GB RAM, dieser ist gerade mal nur zu 10% ausgelastet. Ein Problem wegen Performance ist also ausgeschlossen. Reverse-Lookup funktioniert auch prima und tut was es soll.

Nochmal zur Ergänzung die /etc/hosts
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.0.1 localhost.localdomain localhost
::1 ip6-localhost ip6-loopback

1.2.3.4 server.example.com server
"1.2.3.4" steht dabei natürlich für meine IP ;)

Die Datei ist übrigens genau so auch unter /var/spool/postfix/etc/host vorhanden.
 

nowayback

Well-Known Member
#8
1gb kann zuwenig sein - je nach anforderung...

deine hosts sieht nicht ganz schlecht aus, jedoch hat die praxis bei mir gezeigt, dass es sinn macht erst alle ipv6 und dann alle ipv4 einträge zu setzen. Gerade postfix ist da sehr eigen und produziert sonst gerne fehler wie hostname xxx does not resolve to address y.y.y.y
aber das hat mit deinem fehler selbst nichts zutun...

wenn all das funktioniert und passt was ich bisher geschrieben habe, dann hab ich keine idee mehr, woran es hängen sollte - wobei ich auch nicht wirklich einen sinn darin sehe verbindungen von unknown zu akzeptieren ;)
 
#9
Habe ich jetzt gerade umgestellt, danke für den Tipp! ;)

Nun, um beispielsweise solche Szenarien zu analysieren und, weil es immer mal vorkommen kann dass die DNS Einstellungen der einliefernden Mailserver haken.

Zusätzlich gerade nochmal den OVH Support angeschrieben, ich gehe wirklich stark davon aus, dass es vielleicht irgendwas auf deren Seite ist. Denn sowohl Hostname noch IP sind anderen bekannt außer mir. Wie gesagt, VPS ist frisch aufgesetzt - allerdings weiß ich auch nicht, wann die mir zugewiesene IP zuletzt benutzt wurde.
 

nowayback

Well-Known Member
#10
die dns einstellungen des senders spielen keine rolle... wenn der sender sich mit x.y.endung[1.2.3.4] meldet und x.y.endung auf eine andere als 1.2.3.4 zeigt, würde postfix ne andere fehlermeldung erzeugen.

deine unknown einträge deuten halt am ehesten auf deine fehlerhaften dns einstellungen hin... evtl. zahlendreher oder sowas (8.8.8.8 und 8.8.4.4 sind die ipv4 dns server, 2001:4860:4860::8888 und 2001:4860:4860::8844 sind die ipv6 ns)
 

nowayback

Well-Known Member
#12
wenn du ipv4 und ipv6 für postfix akzeptierst, brauchst du auch ipv6 dns server ;)

ich denke mal hier liegt evtl. auch einer der möglichen fehler... die von mir geposteten ipv6 server sind die von google. füg sie einfach mal hinzu

Code:
nameserver localhost
nameserver 8.8.4.4
nameserver 8.8.8.8
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844
*** edit ***
du wirst sehen das auch mehr wie 3 dns server abgefragt werden können, denn es ist protokoll basierend ;)

ich verabschiede mich nun in die osterfeiertage... mein kind hatte gestern geburtstag und ist 1 jahr geworden ;) - ich hab ne 12h schicht hinter mir - und langsam sind meine grenzen erreicht...

wenn wirklich alles läuft wie du es beschrieben hast können wir gerne kommende woche weiter ins detail gehen... wir werden den fehler dann auch finden -vvv sei dank ;) für jetzt und heute (und morgen) klink ich mich jedoch aus... wäre gut wenn du dann alle entsprechenden configs nachlieferst (postfix, dns, rdns, hostname (erklärung warum hostname != hostname -f) etc.) gerne auch per pm - da du kein ispconfig einsetzt - sonst wenn du ispconfig nutzt wende dich bitte an till (info@projektfarm.de) für support (aber nicht gratis =)).
 
Zuletzt bearbeitet:
#13
Habe deinen Input mal so übernommen, leider führte dies auch nicht zum Erfolg.

Alles klar, vielleicht hat auch wer anders noch einen Tipp. Dir besten Dank für deine Mithilfe und die Denkanstöße, hab eine schöne Zeit mit der Familie! :)
 
#14
Das Thema hat sich erledigt und kann geschlossen werden.

Ich habe den VPS einfach noch einmal neu aufgesetzt und jetzt scheint das Problem nicht mehr zu bestehen. Ich habe sicherlich einfach irgendwo eine falsche Einstellung vorgenommen, die diesen Fehler provoziert hat.
 

Werbung