=== eTeddy1 is now known as eTeddy [17:41] hi [17:55] Hallo? [18:00] guten Abend [18:00] !frag [18:00] Du brauchst nicht fragen, ob Du fragen darfst oder ob sich jemand auskennt. Das ist zwar höflich, würde aber den Channel sehr zuspammen, wenn dies jeder täte. Stell besser einfach Deine Frage – wenn jemand die Antwort kennt, wird er sie Dir nennen. [18:00] habt ihr das 1:1 aus dem Englischen übersetzt? ;) [18:00] im englischen Channel ist es !ask mit dem selben Text :) [18:01] *seufz* [18:01] ist das jetzt deine frage? [18:01] ask ist auch der selbe text ;) [18:01] nein, ich habe ein Problem mit ufw / iptables [18:01] Meine rules sagen ganz klar: _nur_ https und ssh zulassen [18:01] dennoch liefert apache auf port 80 eine default page [18:02] "nmap" zeigt: port 22 und port 80 sind offen [18:02] alles andere ist zu (also auch 443 für https ist zu) [18:02] ufw status => https://dpaste.de/9m6i/raw [18:02] Title: 9m6i (at dpaste.de) [18:02] ufw status numbered => https://dpaste.de/8Lvz/raw [18:02] Title: 8Lvz (at dpaste.de) [18:03] für "iptables -L" habe ich auch ein paste vorbereitet [18:03] aber das muss ich nochmals checken ob da wirklich alle IP's unkenntlich gemacht wurden [18:03] aha :> [18:04] iptables -L => https://dpaste.de/Z6sC/raw [18:04] Title: Z6sC (at dpaste.de) [18:04] alle *************** sind IP-Adressen [18:04] ufw habe ich neu gestartet [18:05] wie ist eigentlich die Etikette in deutschsprachigen Channels auf IRC? Wird geduzt oder gesiezt? [18:06] du [18:06] ok [18:07] Zeile 10 [18:07] sdx23, welche der 3 pastes? [18:07] iptables? [18:08] Zeile 10 ist eine Leerzeile [18:08] ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW,ESTABLISHED [18:09] sdx23, warum ist das da? [18:09] sollte ufw sich nicht um alles kümmern? [18:09] Rojola: das solltest eher du mir sagen ;) [18:10] der Grund weshalb ich mich für ufw entschied ist, dass es einfach ist [18:10] iptables ist superkompliziert finde ich, und ich hätte die von Dir zitierte Zeile nicht mal als Problem erkannt [18:11] ich würde gerne einen Lösungsweg erlernen, den ich einfach in Zukunft reproduzieren kann. [18:11] Dahingehend frage ich mich, ob ich es rein mit ufw lösen kann? [18:12] sudo ufw deny 80/tcp [18:12] ThreeM, gut, aber dann ist port 443 immer noch nicht offen [18:12] https://dpaste.de/9m6i/raw [18:12] Title: 9m6i (at dpaste.de) [18:12] vorher ein ufw default deny um alles dich zu machen [18:12] https://dpaste.de/8Lvz/raw [18:12] Title: 8Lvz (at dpaste.de) [18:12] eigentlich sollte https akzeptiert werden [18:12] dann ufw allow 443/tcp [18:12] ThreeM, können wir es zusammen machen? [18:13] bitte warte kurz [18:13] ich logge mich ein [18:13] muss der windows admin wieder hier die linux fahne hochhalten... [18:15] # ufw default deny [18:15] Default incoming policy changed to 'deny' [18:15] (be sure to update your rules accordingly) [18:16] welche rules soll ich nun updaten? [18:21] das ufw deny 80/tcp bringt halt nichts, weil ufw nicht das Problem ist. Das Problem ist, dass die INPUT chain verbastelt ist. Das ist mit iptables zu lösen. [18:22] !iptables [18:22] Informationen zu iptables finden sich im Wiki unter http://wiki.ubuntuusers.de/iptables [18:22] Danke sdx23 [18:23] ein Grundverständnis davon schadet nicht. Konkret musst du Teile der INPUT Chain löschen. Du könntest auch INPUT flushen, dann musst du aber die ufw-Regeln wieder hinzufügen (nicht in ufw, sondern die Zeilen ab 12. [18:23] wieso passierte das denn überhaupt?! [18:24] wofür gibt es ufw wenns nicht geht? [18:24] sdx23, ein laden der default deny ändert die input chain nicht? [18:25] weil du oder sonstjemand da Regeln in die Input chain eingefügt hat. Da kann ufw und ubuntu nix für. [18:25] das system wurde heute neu aufgesetzt [18:25] ThreeM: ufw murkst in seinen eigenen Chains rum. Wenn in INPUT davor anderes steht, und das greift, ist das halt so. [18:25] was genau heisst "neu aufgesetzt"? [18:26] sdx23, ein vserver wo ich heute neu das OS gewählt habe und "install" geklickt habe [18:26] Rojola: dann ist "sonstjemand" aus meinem Satz oben, dein VPS-Anbieter. [18:26] nicht nett von denen [18:27] ich habe in der zwischenzeit mal folgendes gemacht: [18:27] ufw default deny && systemctl restart ufw [18:28] danach "nmap " von meinem computer aus [18:28] und obzwar der "default deny" regel ist immer noch port 80 und 22 offen [18:28] wie gesagt, kein ufw Problem. Lösche die Regeln in Zeile 10 und 11. [18:28] dazu "numbered" output von iptables verwenden [18:29] sdx23, wenn ufw ohnedies nicht geht bei mir, soll ich es löschen? [18:29] einfach um eine Interferenz zu vermeiden? [18:30] nein, es reicht die INPUT Chain zu bereinigen [18:30] sdx23, kannst du mir bitte sagen wie genau? [18:31] gibt es einen Befehl der alles löst? [18:31] iptables -D INPUT 6 # wenn ich mich nicht verzählt habe. [18:31] wie bekomme ich denn den numbered output von iptables? [18:31] und wahrscheinlich noch ein zweites Mal, aber ich würde gerne "sudo iptables --line-numbers -L" sehen, um sicher zu sein [18:32] ufw hat ja sowas [18:32] 6 ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW,ESTABLISHED [18:32] das ist zeile 6 [18:33] das ist deckungsgleich mit der von Dir beanstandeten Zeile, oder? [18:34] Ja. Nach dem "sudo iptables -D INPUT 6" sollte die weg sein. [18:35] Danke! [18:35] getan [18:35] Dann hast du noch die REJECT Regel, die verhindert dass dein https durchgeht [18:35] wie bekommst du die dann weg? [18:35] indem ich zwei sachen erlaube [18:35] glaube ich? [18:35] ufw allow https [18:35] ufw allow ssh [18:36] neinnein, die REJECT Regel in INPUT die jetzt in Zeile 6 steht [18:36] (tut sie?) [18:36] weiß ich nicht?! [18:36] ja, schau bitte nach. [18:36] Und wenn ja, dann: Genauso. [18:37] iptables --line-numbers -L ? [18:37] ja [18:37] 6 REJECT all -- anywhere anywhere reject-with icmp-host-prohibited [18:37] "-L" listet nur auf, da geht nichts kaputt. [18:38] Mit noch einem "sudo iptables -D INPUT 6" ist die weg. [18:38] Du hast dann noch eine ssh Regel (Nr. 5), die ansich nicht stört, aber halt doppelt zu der in ufw ist. [18:39] in 5 das: [18:39] 5 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh [18:40] sdx23, https://dpaste.de/fGcT/raw [18:40] Title: fGcT (at dpaste.de) [18:40] da ist immer noch viel ACCEPT drin [18:41] Ja. Aber wie gesagt, stört nicht. Allerdings: Alles was du eben getan hast, ist nicht permanent; sondern müsstest du nach einem Neustart wieder tun, wenn das Firewall-Skript von deinem VPS Anbieter die Regeln wieder erstellt hat. Um das nicht erneut tun zu müssen, müsstest du ebendieses Skript vom Starten abhalten. Da kann dir sicher der Support deines VPS Anbieters helfen. [18:41] Ehm, das stört nicht bezieht sich auf das ssh. Die anderen ACCEPTs muss man sich überlegen, ob sinnig. [18:42] kann ich die regeln nicht einfach in einer startup-script irgendwo reinpacken? [18:42] weil der support meines ISP's wird wenig helfen dabei [18:43] das ist ein lokaler Anbieter und... [18:45] naja, man kann wenig zahlen und schlechten Support haben - wenn man sich selbst genug auskennt. Wenn man keine Ahnung hat und auch keine Lust, sich das Zeug beizubringen, empfiehlt sich managed hosting zu nehmen. [18:45] sdx23, die Seite die gehostet werden soll verstößt leider gegen das Obscenity-law der USA [18:45] aus dem Grund ist die Auswahl eingeschränkt [18:46] nichtmal die großen deutschen Anbieter erlauben viele der "adult" sites [18:46] vermutlich habe ich Anbieter übersehen. [18:46] Aber meine Recherche half nicht viel so weit [18:48] kk, EOS von mir. [18:48] EOS = end of service? [18:51] Danke für Deine Hilfe soweit, sdx23