Ja, so soll es sein.
und trotzdem kommt weiterhin die Fehlermeldung
Ja, so soll es sein.
und trotzdem kommt weiterhin die Fehlermeldung
Raspi Runterfahren - Passwort Blödsinn? Schau mal ob du hier fündig wirst!
Oh shit...... braucht man dafür einen Client? Ich hab die Seite einfach mit FF geöffnet... und ohne Paketfilter gehts ja.
Ja, weil mit dem FF (Browser) die Ports 80 oder 443 benutzt werden. IRC-Client braucht man nicht zwingend, wenn man mit dem Browser zufrieden ist. Der IRC-Client wird die klassischen IRC-Ports benutzen. BTW: Du warst ja vorhin schon im Channel.
80 und 443 sind offen... und es macht keinen Unterschied, ob ich die 666* Ports öffne oder nicht ... sobald ich den Paketfilter aktiviere, kommt diese Socket-Fehlermeldung bei der Anmeldung und die Anmeldung failed. Flush ich den Paketfilter, dann gehts. Das ist merkwürdig...
Flush ich den Paketfilter, dann gehts. Das ist merkwürdig...
Evtl. liegt es an der Position, an der Du in der OUTPUT chain, die entsprechende iptables-Regel einfügst.
Versuch mit:
EDIT:
Hast Du in der INPUT chain, die RELATED/ESTABLISHED-Verbindungen evtl. auch blockiert?
Hast Du in der INPUT chain, die RELATED/ESTABLISHED-Verbindungen evtl. auch blockiert?
Das ist die große Frage.... ich habe das mittlerweile auch festgestellt, dass anscheinend related Ports geöffnet werden. Und wenn das im übertragenen Sinne auch so sein muss, wie das früher bei FTP war, dass Ports >1024 mit NEW accept sein müssen, dann funktioniert das bei mir natürlich nicht....
Speziell für FTP ist das bei mir heute über das Application-Layer-Gateway geregelt, weswegen diese Regel nicht enthalten ist... ich probiere das mal
oh man, was ist denn hier los...
Ich kriege wieder mecker, weil das hier so ausschweifend ist
Will denn nicht mal ein "Alter Hase" einen Speziellen "Labereckentread" aufmachen?
Das Thema hier ist doch schon seid #75 als "erledigt" gekennzeichnet
Dukriegs kein Mecker und wens erledigt ist können wirs auch nicht mehr kaputt machen... *lol*
rpi444, das war die Ursache, related Ports... also kann ich das mit meinem Paketfilter nicht nutzen, weil ich das Öffnen der unprivilegierten Ports >1024 ausschließe. Sachen gibts....
Und wenn das im übertragenen Sinne auch so sein muss, wie das früher bei FTP war, dass Ports >1024 mit NEW accept sein müssen, dann funktioniert das bei mir natürlich nicht....
Nein, so wie bei FTP muss das nicht sein. Die Verbindungen werden nur vom Client initiiert und vom Server kommt keine NEW-Verbindung.
Nein, so wie bei FTP muss das nicht sein. Die Verbindungen werden nur vom Client initiiert und vom Server kommt keine NEW-Verbindung.
Merkwürdig.... related und established ist IN und OUT und FORW erlaubt. Damit funktioniert es sofort:
iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m conntrack --ctstate NEW -j ACCEPT
Damit funktioniert es sofort:
iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m conntrack --ctstate NEW -j ACCEPT
BTW: Wenn Du die default policy einer chain auf DROP hast, dann musst man beachten, an welcher Stelle (Position) in der chain, eine mit "-A" hinten angestellte (als letzte Regel hinzugefügt) Regel wirksam werden kann. Evtl. trifft eine vorherige Regel in der chain zu, so dass die gerade hinzugefügte niemals wirksam werden kann.
Siehe z. B. ob die counter der Regel noch "0" sind, mit:
Ich habe imho sehr "harte", aber ich denke, auch sehr unkomplizierte Regeln, völlig ohne Schnörkel... knallhart alles fliegt raus... *fg*.. meine Regeln zielen mehr auf die Kontrolle des Clients ab, und weniger auf Attacken von außen... was Aufgabe des Routers ist... entsprechend meiner Meinung, dass die Kompromittierung immer von innen heraus erfolgt oder ermöglicht wird.
Policy DROP
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m pkttype --pkt-type multicast -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 631 -j ACCEPT
iptables -A OUTPUT -p tcp --dport usw -j ACCEPT
iptables -A OUTPUT -j REJECT --reject-with icmp-admin-prohibited
Alles anzeigen
Da sind nur ne Handvoll expliziter Ports als einzige Ausnahmen erlaubt. Der Policy-DROP sollte eigentlich wg. dem letzten REJECT gar nicht greifen. Alles, was nicht related oder established ist, und auchg nicht als Port erlaubt ist, fliegt raus. Mit anderen Worten, es ist alles verboten, was nicht ausdrücklich erlaubt ist. Ich prüfe nicht mal auf NEW ab, ich verbiete einfach alles... und bei den Ports, die ich erlaube, ist es mir egal, ob NEW oder nicht NEW.
Die INPUT-Rules sind prinzipiell genauso aufgebaut, aber noch weniger geöffnete Ports.... alles ist verboten... nur sehr wenige Ports sind erlaubt.... ebenfalls völlig schnörkellos.
Ich denke, dass hier jetzt schluss ist. Das Ursprungsproblem wurde behoben. Für alles weitere bitte einen eigenen Thread starten
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!