ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
nginx location regexÜdv mindenkinek, Nginx beállításával kapcsolatban lenne kérdésem. Szeretném kezelni az ilyen típusú kéréseket is: 185.219.83.63 - - [29/Dec/2017:08:18:52 +0100] "POST /index.php?option=com_users&view=registration HTTP/1.1" 303 - "-" "" 185.219.83.63 - - [29/Dec/2017:08:18:53 +0100] "GET /component/users/?view=registration&layout=complete HTTP/1.1" 200 10560 "-" "" Az alábbi reguláris kifejezések nem működnek. Mit rontok el?
vagy
A válaszokat előre is köszönöm.
»
|
KeresésNavigációBelépésÁllásajánlatok
HWSWFriss blogbejegyzésekHUP napi hírlevélInformációKövess minket! |
Az már query paraméter (GET request).
--
Gábriel Ákos
Igaz, akkor sajnos nem lesz jó ahogy elterveztem.
Köszönöm a segítséget.
Ismét elővettem a témát és sajnos nem tudom, hogyan lehetne megoldani az alábbi problémát.
Szeretném az uri (regex) alapján tiltani a tartalom elérést de bizonyos ip címek/tartományok esetén továbbra is elérhetővé tenni.
- Sajnos a location nem tartalmazza a teljes url-t így ott nem működik a regex.
- Az IF direktíva (ahol vizsgálhatnám a teljes url-t) blokkja nem tartalmazhat allow/deny/try_files -t így ott nem lehet ip alapján engedélyezni vagy tiltani a tartalom kiszolgálást.
Hogyan kell/lehet ezt fajta a tartalom szűrést kulturáltan megoldani?
A válaszokat előre is köszönöm.
Deny helyett: return 403
Két feltétel egyidejű teljesülése esetén kell elutasítani a kérést.
(1) az url illeszkedik egy/több reguláris kifejezésre
(2) a látogató ip címe nem szerepel az engedélyezett ip/ip tartomány listán.
location esetén így néz ki
location ~* (regex1|regex2) { allow 1.2.3.4; allow 11.12.13.14; allow 21.22.23.24/24; ... deny all; proxy_pass http://10.10.10.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }Ez csak korlátozottan jó megoldás mert a location nem vonatkozik a teljes url-re.
Ezt a megoldást szeretném lecserélni egy olyanra ahol a teljes url vizsgálható regex-el.
Tehát IF használatával hogyan néz ki a szintaxis?
Akkor most egy
serverblokkban aserver_name-nél több név van felsorolva és ez alapján akarsz bontani?Fentebb leírtam a problémát.
A most használt de csak korlátozottan működő megoldás helyett szeretnék egy általánosabban használhatót. De sajnos nem vagyok nginx expert és nem tudom mi lenne a korrekt megoldás.
a location nem vonatkozik a teljes url-re
Ezért kérdezem, hogy jól gondolom-e, hogy szervernév alapján akarod-e több részre bontani.
Nem (vagy nem értem a kérdést), annyit szeretnék amit a példa konfig részlet csinál. Ha az url illeszkedik valamelyik reguláris kifejezésre és nincs külön engedélyezve a látogató ip címe akkor meg kell tagadni a tartalom kiszolgálását.
A példa konfig jelenleg működik de csak abban az esetben ha a szűrés (regex) a location által lefedett url részlettel egyezik.
Szerintem valahogy elbeszélünk egymás mellett, ami valószínű, hogy az én tudásom felületességén (pontatlanságán) múlik.
Szóval ezt írtad: "Ez csak korlátozottan jó megoldás mert a location nem vonatkozik a teljes url-re."
Ezért kérdezem, hogy mit akarsz még vizsgálni, ami az url-nek része, és a(z nginx-es) location-nek nem.
Pl. a
www.example.com/foo/baresetén a location a/foo/bar-t fogja vizsgálni.Azaz neked kellhet a
www.example.comis (server_name) a tiltáshoz?Vagy esetleg a
www.example.com/foo/bar?variable=value-ből avariable=valuekell?Igen, a "?variable=value" szűrésére lenne szükségem. Ezt sajnos nem fedi le a location így a jelenlegi megoldás nem működik ilyen értelemben.
https://serverfault.com/questions/811912/can-nginx-location-blocks-match-a-url-query-string
Akkor már értelek. Ebben az esetben nem lenne jobb, ha maga a php/perl/... ellenőrizne és adna vissza valamit, akár a header függvénnyel?
Még a kiszolgálók előtt el kellene végezni a szűréseket, hogy a szűrésből adódó terhelés ne jusson el a kiszolgáló szerverekig.
Hát, ha nagyon így kell, akkor első blikkre Elbandi megoldása jó lehet (ami ugyanaz, mint blr megoldása).
ezt hasznald fel (a proxy cuccot bele kell majd tenned mindket location reszbe, de ez legyen e legkisebb):
https://serverfault.com/questions/811912/can-nginx-location-blocks-match-a-url-query-string
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ronda megoldás de működni látszik.
Köszönöm a segítséget.
légyszi' az emberiség kedvéért ne error_page-dzsel bűvölj
server { location / { set $ip_permit 0; if ($remote_addr = 1.2.3.4) { set $ip_permit 1; } if ($remote_addr = 1.2.3.5) { set $ip_permit 1; } if ($remote_addr = 1.2.3.6) { set $ip_permit 1; } if ($ip_permit$args ~ ^0.*registration) { return 403; } proxy_pass ... } }a megannyi
if ($remote_addr = )helyett lehetne valamimap.~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack
miert artalmas az error_page?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
A Te megoldásoddal az a baj, hogy ip tartományok megadása esetén is sok száz if kellene, de a "$remote_addr = IP" miatt viszont sok ezer.
Egyesvel akarod beengedni az internetrol a gepeket???? Vagy honnan lenne sok ezer IP ebben az esetben?
A whitelist ertelme az lenne, hogy par IP-cimen kivul minden mast tiltasz, azaz ide csak tenyleg 10-es nagysagrendu IP kellene. De a javasolt map eseten meg szepen megadhato lenne, hogy mondjuk csak magyar IP-k, stb, stb.
Ha meg tenlyeg egyesvel akarod eldonteni egy IP-rol, hogy johet e vagy sem, akkor inkabb a tuzfalirany es a manualis vagy automatikus engedelyezes a jo megoldas. Eldobsz mindent elsore, aztan meg egyesevel engedelyezed a tobb ezer(!!!) ip cimet. :D
A szűrés célja, hogy bizonyos támadási formák ne jussanak el a kiszolgálókig. Ha megnézed a korábban mellékelt megoldást, ott látszik, hogy IP tartományokat engedélyezünk.
pl.:
if ($request_uri = "/index.php?option=com_users&view=registration") {
return 403;
}
Ebben a feltételben nincs benne az, hogy ha bizonyos ip címről érkezik a kérés akkor a request_uri egyezés ellenére mégis ki kell szolgálni a tartalmat. A megoldás bonyolultságának egyik oka pont ez.