deshalb ist es imho besser keinen domainprovider haben zu müssen. die sind nur durchlauferhitzer und das meist schlecht!
Beiträge von hoedlmoser
-
-
reden wir vom registrar der etwas verbockt hat oder vom dns betreiber?
aber redundanz in diesem bereich tut hier mehr als gut, mein registrar ist 1nwx, dns betreib ich selber bei h3tzn3er und n3tcup.
klar, der registrar ist immer spof, andererseits stellt der nur services zur änderung der ns einträge selbst.
auch bei einem webhosting würde ich mindestens einen anderen registrar empfehlen!
-
warum sollte man als spam erkannte mails als spam melden wollen?
wenn dann false negatives, die verschiebt man wie gewohnt in den spam folder und für solche aktionen hat zb dovecot einen hook. auf meinem mta zb wird dann diese mail an den bayes filter verfüttert.
-
Die Korrektur bestand dann darin, die IPv4-Adresse ebenfalls statisch einzutragen und DHCP komplett abzuschalten. Zusätzlich musste ich auch einen DNS-Server manuell eintragen, da auch diese Information nicht mehr per DHCP zugewiesen wurde.
und das ist auch die lösung! man will auf einem server konfigurierte IP adressen haben! es gibt hier in diesem umfeld genau keinen einzigen grund im normalen betrieb DHCP verwenden zu wollen!
-
ein paar Feature ausgehende Verbindung benötigen
Du hast nur TCP und UDP nach aussen erlaubt, ICMP nicht. sprich, mindestens ping wird nicht funktionieren.
-
Ich teste das ganze am Wochenende.
sieht gut aus. die "alles offen" ausgehend brauchst imho nicht, solange Du keine ausgehende regel hast sollte die dazugehörige implizite regele eh auf accept stehen. bin schon neugierig auf Deine erfahrungen mit diesem regelwerk.
wireguard benutzt ephemeral ports.
-
Ss -ulpn
sieht gut aus, das pärchen auf diesen high ports habe ich auch. bei mir noch zusätzlich ein unbound.
Coderoot@guru:~# ss -ulpen Failed to open cgroup2 by ID Failed to open cgroup2 by ID State Recv-Q Send-Q Local Address:Port Peer Address:Port Process UNCONN 0 0 0.0.0.0:44746 0.0.0.0:* ino:15258 sk:1 cgroup:unreachable:ccd <-> UNCONN 0 0 [::]:44746 [::]:* ino:15259 sk:2 cgroup:unreachable:ccd v6only:1 <-> UNCONN 0 0 [::1]:53 [::]:* users:(("unbound",pid=951,fd=3)) ino:15195 sk:3 cgroup:/system.slice/unbound.service v6only:1 <-> root@guru:~# -
aber im speziellen für mailcow (und auch sonst was man so in container laufen hat) und allgemein würde ich persönlich folgendes setup empfehlen:
alles was man nicht exponieren will bindet man auf localhost. sieht in der mailcow.conf dann zb so aus:
CodeHTTP_BIND=127.0.0.1 HTTPS_BIND=127.0.0.1 POP_PORT=127.0.0.1:110 POPS_PORT=127.0.0.1:995 DOVEADM_PORT=127.0.0.1:19991 SQL_PORT=127.0.0.1:13306 REDIS_PORT=127.0.0.1:7654oder für eine nextcloud-aio in der compose.yaml:
Codeports: - 127.0.0.1:8047:8080 environment: APACHE_IP_BINDING: 127.0.0.1oder für einen lokalen unbound als resolver in unbound.conf.d/local.conf
Codeserver: interface: ::1das ist bei docker sowieso von nöten wenn man zb als firewall ufw verwenden will, denn das docker gedöns greift schon in der nat table und somit vor ufw.
denn prinzipiell gilt: mach dein system so sicher, daß es keiner firewall bedarf.
und fürn lokalen rest dann halt zb die eben erwähnte ufw (ich hab hier am host einen nginx für tls-offloading laufen).
Coderoot@guru:~# ufw status Status: active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere(IPv6 sieht genauso aus)
-
ganz genau, es ging um UDP, denn bei TCP muß man dank state-full firewall ja nicht die ports >= 1024 aufmachen.
und bitte entweder mit sudo oder mit dem parameter -e damit man auch gleich die prozesse sieht die da lauschen.
-
are you the owner of the domain? or is this general-use domain by your provider?
-
deprecated
hast Du gerade "alt" zu mir gesagt?
-
Meinen Respekt
der gelernte ost-österreicher schaut gerne beim sterben zu, nicht umsonst wird Wien auch als morbide bezeichnet.
-
Also wegen einer geringfügigen Überschreitung der Speicherkapazität wirst du nicht sofort gesperrt.
https://helpcenter.netcup.com/de/wiki/webhos…erre-informiert ist da imho sehr eindeutig.
ZitatUnser System informiert dich per E-Mail über den Speicherplatzverbrauch:
* Sobald du 80 % deines Speicherplatzes erreicht hast, erhältst du eine Warnung an dir von dir hinterlegte E-Mail-Adresse.
* Wenn du das Limit überschreitest, wird dein Hosting temporär gesperrt. Auch darüber wirst du per E-Mail in Form eines Abuse-Hinweises informiert.
Warn-Mails nicht noch hättest empfangen können
er dürfte eh eine andere emailadresse bei den kundendaten angegeben haben, er hat sich zumindest ins CCP einloggen können mit email-authentifizierung.
aber von "Ich rate von netcup ab." bis zu "ich hab mir mein webhosting selbst voll gemacht" hats mit viel mimimi genau 2,5 tage gedauert, unter völliger ignoranz wie abusehinweise oder dem HelpCenter, totaler verschiebung der begrifflichkeiten wie ticket vs abusehinweis und fehlender transparenz der fehlermeldungen (gekillt, geht gar nichts mehr, offline, doof, keine ahnung, alles geschrieben, alles gesperrt, ...)
man kann sich auch schöner ins knie schießen. aber danke fürs zuschauen.
-
fürn unbound brauchst keine TCP rule, TCP ist ja eh state-full.
aber mit der Unbound UDP rule besteht halt das problem, wie ich weiter oben schon mal erwähnt habe, daß ich alle Deine UDP services mit port >= 1204 nutzen kann (wenn ich den src port 53 benutze). also sehr suboptimal!
bevor aber panik ausbricht, schau mal was da bei Dir an UDP ports überhaupt so offen ist.
Codenetstat -ulpn -
Was soll ich sonst schreiben?
genau das:
Sperre gibt es wegen geringfügiger Überschreitung der Speicherkapazität.
Du hast also beide hinweise laut https://helpcenter.netcup.com/de/wiki/webhosting/quota-sperre/ nicht bekommen? aber die email-authentifizierung im CCP funktioniert?
Abuseeintrag
aja, Du hast also gehandelt so wie hier https://helpcenter.netcup.com/de/wiki/general/abuse-hinweise beschrieben?
und wir alle dachten Du hast ein ticket aufgemacht. zumindest lese ich hier das erste mal, daß es eh einen abusehinweis gab.
aber scheint sich ja nun alles in wohlgefallen aufzulösen, wenn man auch nicht versteht sich korrekt auszudrücken.
-
unbound
oida.
kinder, vergessts das mit einer state-less firewall. investierts eure zeit lieber in eine lokale state-full firewall und verwendets die von netcup nur um die phösen burschen wegzublocken.
ZitatBy default only ports above 1024 that have not been assigned by IANA are used.
also nix mit standard ephemeral port range.
richtung: INcoming/INgress
proto: UDP
source port: 53
destination port: 1024 - 65535
hihi, steht aber eh auch in dem von Dir genannten link https://docs.mailcow.email/de/getstarted/prerequisite-system/ unter 'Wichtig für H3tzn3r Firewalls'
-
Da komme ich auch nicht an den Webspace.
mein auto verliert gleich hinten öl.
wann man mich wieder ranlässt
Du hast also nicht hinterfragt warum es zeitnah keine reaktion auf Dein ticket gab? ihr habt also nicht abgeklärt warum es zu dieser sperre kam (disk quota überschritten, prozess der zu viel cpu konsumiert, ...) und was die nächsten schritte sein müssen? es wäre nett das forum hier teilhaben zu lassen, damit auch andere von Deinen erfahrungen einen nutzen ziehen können. ausserdem wäre es fair gegenüber den helfern hier entsprechend rückmeldung zu geben.
Das hatte der Mitarbeiter, dem ich das auch sagte, auch so gesehen.
der ist darauf trainiert den anruf nicht eskalieren zu lassen.
Wenn etwas unterirdisch (im Sinne von miserabel) ist, muss man es auch ansprechen dürfen.
jup, Dein auftreten hier auf jeden fall.
Es ist ja keine Beleidigung.
-
Sieht das jetzt besser aus?
Du wirst noch eingehend dst TCP 80 und 443 für http/s öffnen wollen.
die idee bei ausgehend TCP auf any zu setzen ist nicht schlecht, bewahrt Dich aber nicht davor, daß Deine UDP regeln falsch sind. das mit source und destination port ist keine oder-relation. und nein, weder rspamd noch dns (in ausnahmefällen) kommunizieren mit dem selben src und dst port.
bitte, vergiss das mit den outgoing regeln.
es ist da schon kompliziert genug die inbound für Deine UDP clients richtig zu machen, die müssen für DNS wie folgt aussehen:
richtung: INcoming/INgress
proto: UDP
source port: 53
destination port: 32768 - 60999 (Linux ephemeral port range)
vor allem fürn unbound, der ja alle DNS server da draussen im netz abfragt.
fürn rspamd könnte man es noch auf die source IP eingrenzen, hat aber den nachteil, wenn die mal die IP von zb fuzzy.mailcow.email ändern mußt das manuell in der firewall nachziehen, also auch hier genau das selbe wie beim DNS.
richtung: INcoming/INgress
proto: UDP
source port: 11445, 11335
destination port: 32768 - 60999 (Linux ephemeral port range)
-
Wie gesagt, alles gesperrt.
jo, schatzerl, eh. mein mechaniker freut sich auch, wenn ich ihm bei ölverlust am auto es mit folgenden worten verorte: vorne.
Was ist WCP?
das Webhosting Control Panel. https://helpcenter.netcup.com/de/wiki/webhosting/interface/
unterirdisch
fangst schon wieder an? ich hatte das gefühl wir sind hier auf einem guten und konstruktiven weg.
Phishinghinweise, auch in englisch, obwohl als Kommunikationssprache deutsch gewählt
jo mei, hat halt einer in der IVR keine lust gehabt zwei files einzuspielen. so what.
jetzt schon eine Stunde
da sind jetzt alle in der schlange die bisher nur gestänkert haben und ihr problem doch noch vorm wochenende gelöst haben wollen. aber keine angst, Du kommst sicher dran, die sind heute noch bis 17:00 da.
-
bei UDP müssen wir hier bei der netcup firewall, da state-less, auch die rückrichtung der packerle betrachten.
Code
Alles anzeigenyour host | | remote host client |-->> outgoing/egress >>---| server scr port e | | dst port x your host | | remote host client |--<< incoming/ingress <<--| server dst port e | | src port x your host | | remote host server |--<< incoming/ingress <<--| client dst port y | | src port e your host | | remote host server |-->> outgoing/egress >>---| client src port y | | dst port ezur erinnerung, clients verwenden auch bei UDP fast immer einen ephemeral port, der server port hingegen ist fix und vom service abhängig (zb 53 für DNS oder 123 für NTP).
und auch hier nochmal der hinweis, outgoing rules definieren zu wollen grenzt an masochismus, bei state-less noch viel mehr, da spürt man die schmerzen schon alleine durchs lesen.
beispiel:
spezifischer remote NTP-server
regel 1
richtung: outgoing/egress
proto: UDP
destination IP: 178.251.64.52 (time.nobody.at)
destination port: 123
regel 2 für die antwort
richtung: INcoming/INgress
proto: UDP
source IP: 178.251.64.52 (time.nobody.at)
source port: 123
destination port: 32768 - 60999 (Linux ephemeral port range)
will man alle NTP-server da draussen ansprechen, weil man zb einen pool wie pool.ntp.org abfrägt, sind einfach die IPs wegzulassen.
lokaler NTP-server
regel 1
richtung: INcoming/ingress
proto: UDP
destination port: 123
regel 2 für die antwort
richtung: outgoing/egress
proto: UDP
source port: 123
hier ist eine einschränkung auf die ephemeral ports nicht möglich, da der range je nach client implementierung anders ist, vergleiche dazu https://en.wikipedia.org/wiki/Ephemeral_port#Range
das beispiel ist 1:1 für DNS anzuwenden.
Deine UDP regeln mußt Du also unbedingt überarbeiten.
aja, ICMP würde ich nicht einschränken. ja, ping verwendet ICMP, aber ICMP wird auch für ganz viele andere, essentielle dinge verwendet, vor allem bei IPv6.
