poort 7080 en 7081

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ozzie PHP

Ozzie PHP

14/05/2016 21:09:02
Quote Anchor link
Hey guys,

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?
 
PHP hulp

PHP hulp

20/04/2024 11:34:36
 
Ben van Velzen

Ben van Velzen

14/05/2016 22:46:25
Quote Anchor link
Poorten 7080/7081 zijn standaard fastcgi poorten. Wanneer je unix sockets gebruikt, PHP alleen op localhost laat luisteren voor fastcgi, of geen fastcgi inzet zijn deze poorten ongebruikt.

Toevoeging op 14/05/2016 22:49:50:

Uiteraard weer gewoon te controleren met netstat of telnet.
 
Ozzie PHP

Ozzie PHP

14/05/2016 22:49:55
Quote Anchor link
Ben, thanks (hoe weet jij dit allemaal?)

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?
 
Ben van Velzen

Ben van Velzen

14/05/2016 23:03:12
Quote Anchor link
Nee, ze hoeven niet open te zijn. Niet van buitenaf in ieder geval. Wat in het geval van de Plesk configuratie gebeurt is het volgende:
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
 
Ozzie PHP

Ozzie PHP

14/05/2016 23:09:02
Quote Anchor link
>> zal apache worden geconfigureerd om te gaan luisteren op poorten 7080 en 7081, in plaats van de gebruikelijke 80 en 443.

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?
 
Ben van Velzen

Ben van Velzen

14/05/2016 23:12:20
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

14/05/2016 23:17:18
Quote Anchor link
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.
 
Ben van Velzen

Ben van Velzen

14/05/2016 23:19:53
Quote Anchor link
Je doet het zoals gebruikelijk is.
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.
 
Ozzie PHP

Ozzie PHP

14/05/2016 23:23:39
Quote Anchor link
>> Je doet het zoals gebruikelijk is.

Toch doet Plesk het standaard precies andersom :-s
 
Ben van Velzen

Ben van Velzen

14/05/2016 23:25:58
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

14/05/2016 23:30:31
Quote Anchor link
tja ... pretty weird :D
 
Ben van Velzen

Ben van Velzen

14/05/2016 23:44:17
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

15/05/2016 00:58:40
Quote Anchor link
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.
 
Ben van Velzen

Ben van Velzen

15/05/2016 01:05:37
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

15/05/2016 01:15:13
Quote Anchor link
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 :)
 
Ben van Velzen

Ben van Velzen

15/05/2016 01:17:59
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

15/05/2016 01:43:41
Quote Anchor link
Is zeker ook wel leuk. Daarmee onderscheid je jezelf. Mijn hart ligt dan weer meer bij de voorkant, maar tegelijkertijd is het ook wel tof om iets van de achterkant te weten en een veilige omgeving te kunnen creëren waar de voorkant dan weer op kan draaien! Mijn allereerste programmeerstapjes (maar toen wist ik helemaal nog niet dat ik daar ooit later meer mee zou gaan doen) waren op een Commodore 64. Het was met name wat overtypwerk uit een boekje, en dan vloog er ineens een luchtballon over je scherm ... in pixels van 2x2 cm ;-)
Gewijzigd op 15/05/2016 01:58:07 door Ozzie PHP
 
Ben van Velzen

Ben van Velzen

15/05/2016 02:18:39
Quote Anchor link
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.
 
Ozzie PHP

Ozzie PHP

15/05/2016 02:53:27
Quote Anchor link
>> 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!
 
Ben van Velzen

Ben van Velzen

15/05/2016 11:11:32
Quote Anchor link
Heel bekend inderdaad, en als je ook maar 1 foutje maakte.. au!
 
Ozzie PHP

Ozzie PHP

15/05/2016 15:38:56
Quote Anchor link
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???
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.