poort 7080 en 7081
In Fail2Ban worden in 2 zogenaamde 'jails' de http (80) en https (443) poorten geblockt, maar daarnaast ook de poorten 7080 en 7081. Nu vraag ik mij af of die 2 laatste poorten eigenlijk ooit wel gebruikt worden, of dat ik ze kan weghalen uit de configuratie-settings.
Ik heb gelezen dat poort 7080 en 7081 door nginx gebruikt worden, maar ik weet het niet zeker. Ik weet ook niet of het dan enkel gaat om intern verkeer (op de server zelf), of ook om inkomend verkeer van buiten de server.
Ik heb mijn policy zo ingesteld dat poorten voor inkomend verkeer expliciet moeten worden geaccepteerd. Poort 7080 en 7081 heb ik niet geaccepteerd en die staan dus sowieso dicht, dus heeft het (lijkt me) weinig zin om die poorten in een jail op te nemen. Maar ik vraag me dus af of als ik nginx ooit zou gaan gebruiken, ik deze 2 poorten dan wél moet openzetten voor inkomend verkeer van buitenaf.
Weet iemand dit?
Toevoeging op 14/05/2016 22:49:50:
Uiteraard weer gewoon te controleren met netstat of telnet.
Ik heb de poorten nu dicht staan en alles werkt, maar als ik nu nginx ga gebruiken, moet ik die poorten dan wel openzetten, of dan ook niet?
Als je besluit dat je nginx wil gebruiken en niet apache, zal apache worden geconfigureerd om te gaan luisteren op poorten 7080 en 7081, in plaats van de gebruikelijke 80 en 443. Nginx zal requests doorzetten naar deze poorten.
Zie het volgende KB artikel voor wijzigen en uiteraard wat meer info:
https://kb.plesk.com/en/114249
Mijn advies zou in deze zijn om de configuratie zodanig te wijzigen dat je regels krijgt als Listen 127.0.0.1:7080 en Listen 127.0.0.1:7081. Of gewoon DROPpen met iptables, kan ook.
Gewijzigd op 14/05/2016 23:05:08 door Ben van Velzen
Oké, voor mijn begrip. Dit gaat dan toch om localhost? Die poorten staan ook in dit geval voor de buitenwereld toch compleet dicht?
Maar heb jij dan eigenlijk een idee waarom die 'jail' van Fail2Ban ook poort 7080 en 7081 blokkeert als die voor de buitenwereld toch nooit openstaan? Wat zou daar de reden dan van kunnen zijn?
Ik weet niet exact hoe de config van apache er uit zal zien, maar mogelijk is het gewoon Listen 7080 etc. Ik zie ook als ik er naar zoek berichten dat websites wel werken via 7080 maar niet 80 als nginx gestopt is. Dus het is wel iets om in te duiken denk ik. Al zal het geen kwaad kunnen dat websites ook daarlangs bereikbaar zijn voelt het niet netjes.
Oké, nou vooralsnog zal ik ze maar gewoon dicht laten staan (of beter gezegd 'niet open zetten'). Ik hanteer de policy dat al het inkomend verkeer standaard geblockt wordt en dat ik expliciet moet instellen welke poorten benaderd kunnen worden van buitenaf. De standaard instelling werkt overigens anders, namelijk dat een aantal poorten geblockt wordt en dat de rest van het inkomende verkeer wordt toegestaan. Dat lijkt mij minder veilig.
Of nog gebruikelijker: standaard policy ACCEPT, met als laatste regel een DROP. Dit om te voorkomen dat wanneer je iptables config ongeldig is, je jezelf niet buitensluit.
Toch doet Plesk het standaard precies andersom :-s
Maar Plesk is Plesk, en Plesk zou Plesk niet zijn zonder achterlij ^H^H^H^H^H^H^H^H^H^H eigenaardigheden. Zie alleen al wat je in dit topic aanhaalt: het effect van Apache achter Nginx.
tja ... pretty weird :D
Ik heb zelf een aantal servers die op cPanel draaien. Hierin worden zaken in de basis geconfigureerd, en mag je zaken als je firewall etc zelf doen. Het liefst zou ik helemaal geen panel gebruiken, maar ja, klanten. Op eigen servers doe ik gewoon alles zelf, en niet elke server is ook een webserver. Denk ook aan data processing/mining, telefonie etc.
Ik heb vroeger ook met cPanel gewerkt, maar toch vind ik Plesk fijner. Vooral de veel strakkere userinterface van Plesk bevalt mij wel, en in cPanel waren (destijds) veel dingen net niet of een beetje teveel houtje touwtje. Plesk heeft ook z'n eigenaardigheden, maar ik heb niet de expertise om een server zonder panel te runnen. Ik zou het wel kunnen leren, maar ik vind zo'n panel dan toch wat makkelijker werken.
Wat je zou kunnen doen is een experimentele server opzetten, bijvoorbeeld in Virtualbox oid, of mogelijk een Raspberry PI, wat weer met zijn eigen eigenaardigheden komt: het schrijven van een SD kaart zorgt al heel snel voor verstoringen elders op de kaart; om die reden bouw ik daar vaak servers op die voor het overgrote deel readonly zijn, en het schrijfverkeer richting RAM wordt gestuurd. Opzich ook een leuke casus om mee te werken, ook als experiment. Denk hierbij aan het gebruik van unionfs of aufs. Ik heb hier ooit een thinclient server mee gebouwd: de basis was een nbd image die geboot kon worden, en X werd gewoon doorgegeven op remote poorten, en benaderd via de SCREEN variabele. De mogelijkheden voor experimenteren zijn eindeloos.
Maar ik ben niet zoals jij een systeembeheerder ... voor mij is het voldoende als ik een goede webserver kan beheren. Dat vind ik al heel wat als dat allemaal lukt :-) Maar het gaat steeds beter en ik leer steeds kleine dingetjes bij. Da's wel geinig. Het laat je wel anders denken over al die websites overal ter wereld. Meestal zie je alleen de voorkant, maar eigenlijk gaat er nog een hele wereld achter schuil :)
Dat sowieso. Maar ik ben ooit als programmeur begonnen, in een ver grijs verleden met BASIC en assembler. Naarmate ik meer dingen uit de grond stampte ging ik me meer verdiepen in de wereld achter de voorkant, en die vind ik minstens net zo interessant als de website an sich. Komt bij dat er niet veel beheerders zijn die verder komen dan point and click, ik maak er voor mezelf altijd een uitdaging van om net dat stapje extra te kunnen zetten.
Gewijzigd op 15/05/2016 01:58:07 door Ozzie PHP
Haha, een erg bekende situatie. Op die manier ben ik ook ooit begonnen. Mijn hart is verdeeld tussen voor en achterkant. Er is van mijn kant bijvoorbeeld ook een hoop kennis over de interne werking van databases aanwezig, PHP ken ik ook erg goed; ik werk er sinds eind jaren '90 mee. Maar zaken als bijvoorbeeld de x86 architectuur etc blijven ergh interessant. Ik schrijf x86 cpu's in verilog als ik me verveel. Daar ben je snel een paar maanden mee bezig. Interessant is het zeker, en het geeft een beloning als je er werkelijk Windows of Linux op kan draaien. Ook met systeembeheer: het begint met interesse over de werking, daarna volgt de rest vanzelf.
Dat geldt eigenlijk voor alles. Mijn passie komt voort uit 'het grafische' en het willen communiceren met een grote doelgroep. En dan kan je in het maken van een website goed je ei kwijt. Bij jou ligt zo te horen de uitdaging weer echt in het technische aspect. En zo hebben we allemaal onze sterke kanten en interesses.
Nog een kleine anekdote dan ... ik kan me herinneren dat ik eens een boek heb gekocht met daarin machinetaal. Die machinetaal moest ik dan invoeren op de C64 en aan het eind van de rit had ik zowaar een grafische editor waarmee je sprites kon maken :-) Maar je moet je dus voorstellen dat ik vele bladzijdes moest overtypen (ja echt) met alleen maar machinetaal. Vele bladzijdes gevuld met regels die er (denk ik ... lang geleden) ongeveer zo uitzagen als dit:
Quote:
FFAA 24bW q8HG aava 90FD G0PP 391B vn44 HCCI 31jT
En geloof het of niet ... maar na dagen typen, werkt het nog ook!
Heel bekend inderdaad, en als je ook maar 1 foutje maakte.. au!
Ja, inderdaad au ... achteraf gezien kan ik me ook totaal niet voorstellen dat het gewoon werkte. Het is zo lang geleden dat ik echt niet meer exact weet hoeveel bladzijdes het waren, maar het zouden er makkelijk 30 geweest kunnen zijn. Hoe heb ik dat in godsnaam foutloos kunnen overtypen :-s Huh???