Da ich für KVM den Server eh neu aufsetzen muss und dieses nette Tutorial gefunden habe wollte ich nginx testen. Meine Seite, die vorher unter Apache2 lief, produzierte bei Aufruf einer Unterseite die Fehlermeldung:
502 Bad Gateway
im errorlog stand:
[error] 1067#0: *28 upstream sent too big header while reading response header from upstream, client:
als Lösung habe ich mit Google gefunden:
die Datei
/etc/nginx/nginx.conf
mit diesen zwei Zeilen ergänzen
http {
...
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
...
}
Die Seite funktioniert jetzt, ich würde nur gerne Wissen ob das eine sinnvolle Lösung ist oder ob man besser etwas anders konfiguriert.
Alles anzeigen
Die Lösung ist schonmal korrekt, nur würde ich mich eher fragen wieso so ein großer Header übermittelt wird? Nginx meldet den Error ja nicht ohne Grund, das dient mehr oder weniger der Sicherheit.
Aber ja, es ist der einzige Lösungsweg (außer du veränderst die Größe des übermittelten Headers)
so ich hab jetzt nochmal alles nachgesehen und komm nicht weiter 
es wäre ja auchj seltsam wenn ich 7 mal den selben Fehler beim Kopieren der config gemacht hätte.
Denn so oft hab ich das tut schon durchgearbeitet.
sobald beid configs den selben listen eintrag haben klappts nicht mehr.
dabei ist es egal ob mit IP oder nur Listen 80;
sind die Einträge identisch klappts nicht mit dem restart.
sind die Einträge ungleich
listen IP: Port;
und listen *:80; z.B.
ist nur die Seite mit IP: Port erreichbar egal ob sub oder hauptdomain
Alles anzeigen
Puh mein lieber Michi, bei dir bin ich wirklich überfragt. Ich wünschte ich hätte die Zeit, um mal zu versuchen diesen Fehler nachzustellen. Wie gesagt, ich könnte bei mir jetzt noch 10000 Domains aufschalten, wenn es denn die Kapazitäten erlauben würden, und es wäre kein Problem die alle einzeln laufen zu lassen. Wenn es bis zum Wochenende nicht geht, bin ich gerne bereit mal per Teamviewer drüber zu schauen oder ggf. die Installation mit dir durchzugehen. Denn irgendwo muss der Wurm ja versteckt sein, möglich ist es definitiv.
Hi definitiv,
erst einmal ein großes Danke für deinen Leitfaden 
Dieser hat mir sehr geholfen, auch wenn ich was das Thema Linux betrifft nicht unbedingt auf den Kopf gefallen bin. Vor kurzem überprüfte ich meinen auth.log und stellte fest, dass auf meinem Server gerne Wörterbuchattacken auf den ssh-Port gefahren werden. Diese Angriffe werden leider nicht von fail2ban abgefangen. Da ich leider keinen gültigen Regex-Ausdruck hinbekomme wollte ich dich fragen, ob du dich auf dem Gebiet auskennst.Hier mal ein Auszug aus dem Log:
Apr 8 18:25:07 sshd[5595]: input_userauth_request: invalid user root [preauth]Apr 8 18:25:07 sshd[5595]: Received disconnect from **: 11: Bye Bye [preauth]Apr 8 18:25:10 sshd[5597]: User root not allowed because account is lockedApr 8 18:25:10 sshd[5597]: input_userauth_request: invalid user root [preauth]Apr 8 18:25:11 sshd[5597]: Received disconnect from ***: 11: Bye Bye [preauth]Apr 8 18:25:15 sshd[5599]: Invalid user oracle from ***Apr 8 18:25:15 sshd[5599]: input_userauth_request: invalid user oracle [preauth]Apr 8 18:25:15 sshd[5599]: Received disconnect from ***: 11: Bye Bye [preauth]Apr 8 18:25:18 sshd[5601]: Invalid user oracle from ***
MfG
fkrone
Hast du mal dürber nachgedacht, den Port zu ändern? Wenn die auf einen geschlossenen Port 22 schießen, dann kann dir das ja egal sein
Es gibt mehrere Denkansätze/Lösungswege:
Mit Iptables:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 5 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Die geblockten IPs findest du dann pro Rulename (also --set --name SSH) hier: /proc/net/ipt_recent/
Oder aber du definierst einen gültigen failregex Eintrag. Da du ja wie ich sehe den User root gesperrt hast, kannst du folgendes eintragen:
^%(__prefix_line)s.+Name: root \[preauth\]\s*$
Alles was nur annährend root heißt, wird geloggt und nach der von dir definierten Anzahl an Fehlversuchen gebannt.
Oder aber du nimmst folgenden regex Eintrag:
^%(__prefix_line)sReceived disconnect from <HOST>: 11: Bye Bye\s*$
Das ist sogar etwas effektiver. Somit hättest du das Problem mit fail2ban auch gelöst.
Hoffe ich konnte weiterhelfen
Beste Grüße
Alex
