Címlap » Fórum » Linux » Linux-kezdő

nginx location regex

 ( maszili | 2017. december 29., péntek - 9:17 )

Ü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?

location ~* ( ... |registration) { ... }

vagy

location ~* ( ... |.*registration.*) { ... }

A válaszokat előre is köszönöm.

‹ Fedora 27 - lock után login csonttá fagy (wayland) Shibboleth 2 két idp konfigurálása ›
 »
  • A hozzászóláshoz belépés szükséges
  • 2256 olvasás

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.
( gabrielakos (veterán) | 2017. december 29., péntek - 9:22 )

Az már query paraméter (GET request).

--
Gábriel Ákos

( maszili | 2017. december 29., péntek - 9:29 )

Igaz, akkor sajnos nem lesz jó ahogy elterveztem.

Köszönöm a segítséget.

( maszili | 2018. április 16., hétfő - 10:26 )

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.

( blr (veterán) | 2018. április 16., hétfő - 10:50 )

Deny helyett: return 403

( maszili | 2018. április 16., hétfő - 11:20 )

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?

( uzsolt (veterán) | 2018. április 16., hétfő - 11:40 )

Akkor most egy server blokkban a server_name-nél több név van felsorolva és ez alapján akarsz bontani?

( maszili | 2018. április 16., hétfő - 11:47 )

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.

( uzsolt (veterán) | 2018. április 16., hétfő - 12:05 )

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.

( maszili | 2018. április 16., hétfő - 12:33 )

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.

( uzsolt (veterán) | 2018. április 16., hétfő - 14:19 )

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/bar esetén a location a /foo/bar-t fogja vizsgálni.
Azaz neked kellhet a www.example.com is (server_name) a tiltáshoz?
Vagy esetleg a www.example.com/foo/bar?variable=value-ből a variable=value kell?

( maszili | 2018. április 16., hétfő - 14:32 )

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.

( blr (veterán) | 2018. április 16., hétfő - 15:00 )

https://serverfault.com/questions/811912/can-nginx-location-blocks-match-a-url-query-string

( uzsolt (veterán) | 2018. április 16., hétfő - 15:01 )

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?

( maszili | 2018. április 16., hétfő - 15:26 )

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.

( uzsolt (veterán) | 2018. április 16., hétfő - 15:27 )

Hát, ha nagyon így kell, akkor első blikkre Elbandi megoldása jó lehet (ami ugyanaz, mint blr megoldása).

( Elbandi (veterán) | 2018. április 16., hétfő - 14:26 )

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!

( maszili | 2018. április 16., hétfő - 15:36 )

Ronda megoldás de működni látszik.

Köszönöm a segítséget.

( bAndie9100 | 2018. április 18., szerda - 14:46 )

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 valami map.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( Elbandi (veterán) | 2018. április 18., szerda - 18:39 )

miert artalmas az error_page?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( bAndie9100 | 2018. április 23., hétfő - 8:42 )

mert a hibaoldalakhoz találták ki. lehet h egy bizonyos nginx verziónál ki lehet úgy sakkozni a konfigot h ne legyen váraltan mellékhatása, de mivel homlokegyenest nem arra használod amire való, lehet h egy igazi 404-es hibára valami tök más oldalt szolgál ki - jó látom h próbált nem használt hibakódokat felhasználni, de akkor is "beláthatatlan" következményei lehetnek. és aki olvassa a konfigot annak is megtévesztő.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( maszili | 2018. április 19., csütörtök - 6:15 )

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.

( golgota | 2018. április 19., csütörtök - 10:48 )

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

( maszili | 2018. április 19., csütörtök - 11:13 )

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.

( bAndie9100 | 2018. április 23., hétfő - 8:43 )

az if tud regexpet is

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( maszili | 2018. április 23., hétfő - 9:08 )

Tudom.

( bAndie9100 | 2018. április 24., kedd - 16:21 )

azért mondom merthogy nem kell ezres nagyságrendű if block ha regexppel adod meg az ip range-eket.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( maszili | 2018. április 24., kedd - 19:08 )

Segíts kérlek. Milyen regex illeszkedik pl. az összes magyar és német ip címre külön-külön?

( golgota | 2018. április 24., kedd - 19:37 )

nginx geoip module

geoip_country /usr/share/GeoIP/GeoIP.dat;
map $geoip_country_code $allowed_country {
default no;
HU yes;
DE yes;

blahblahblah

( maszili | 2018. április 24., kedd - 20:39 )

Sajnos nincs geoip modul...

nginx version: nginx/1.13.6
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) 
built with OpenSSL 1.0.2k-fips  26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --with-http_ssl_module
--with-http_ssl_module --with-http_v2_module --with-http_realip_module
--with-http_flv_module --with-http_mp4_module --with-ipv6 --with-http_stub_status_module

( golgota | 2018. április 25., szerda - 10:45 )

rebuild ezzel az opcioval?

Tudom, hogy utana neked kell majd a package-t mainten-elni, de lehet megerne. Nem tudom, hogy ez egy deb vagy rpm alapu distro e, de mindegyiknek pikk-pakk megoldhato a spec atirasa. Utana mar csak egy repo-t kell generalni.

A kerdes, hogy problema orientalt vagy e (midnenaron megoldani valami bonyolult modon), vagy problema megoldo:
* geoip modul (rpm/deb + valamilyen artifactory/repository)
* CDN (by bAndie9100)

Lehet valaki feldob egy harmadik megoldast is. :D

( maszili | 2018. április 25., szerda - 11:26 )

Ez az nginx egy zárt kereskedelmi termék (nem oprendszer szinten csomagból telepített) része így nem lehet belebabrálni pl. támogatás vesztés és egyéb kellemetlenségek nélkül.

( bAndie9100 | 2018. április 25., szerda - 11:38 )

ok. ebbe az nginx telepítésbe csak config szinten nyúlhatsz bele.

mi lenne ha áttennéd egy másik portra és bekonfigolnál reverse proxy-zásra egy másik nginx-et, egy akármilyet, ami az eredeti porton hallgat.
a reverse proxy-n szűröd a dolgokat, esetleg plusz request header-eket teszel rá és proxy_pass-szal átdobod a zárt nginx-nek amiket ki akarsz szolgálni.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( bAndie9100 | 2018. április 25., szerda - 8:22 )

- végy egy CIDR listát
- /8, /16, /24 -ből lesz ^aa\., ^aa\.bb\., ^aa\.bb\.cc\.
- a (k*8)+n maszkok esetén is meg lehet konstruálni egy-egy regexpet, ami lefedi

vagy tedd a site-ot CDN mögé, az berakja header-be hogy milyen országból jön a látogató, pl Cloudflare-nél CF-IPCountry: HU

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( maszili | 2018. április 25., szerda - 8:58 )

A német ip CIDR lista ~47765 elemű. Azt gyanítom, hogy ettől nem lesz kevesebb (csak inkább több) a regex megoldás.

A CDN nem kivitelezhető.

( bAndie9100 | 2018. április 25., szerda - 10:05 )

oké, ilyen range-ek legrosszabb esetben ugyanannyi regexp-es if-et adnak, mint amennyi range-ed van.

de én először arra reagáltam, hogy nem kell egy adott range minden egyes ip-jét egyenlőséggel vizsgálni, hanem egy range-ből generálható regexp (ld. https://gist.github.com/bAndie91/e566fcdf3e364716ff9bfb2927bc365f ).

aztán a range-nyi if-et le lehet redukálni egy okos algoritmussal, ami mergeli a mergelhetőt, pl. 1.2.3.0/14, 1.2.4.0/24 => első körben két regexp lesz, merge után meg egy: ^1\.2\.[34]\.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

( gedez | 2018. április 18., szerda - 18:43 )

pl.:
if ($request_uri = "/index.php?option=com_users&view=registration") {
return 403;
}

( maszili | 2018. április 19., csütörtök - 6:19 )

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.