Pornim de la următoarea problema:
Pentru a putea totuși sa folosim aceasta funcționalitate trebuie sa facem un mic hack și sa instalam acest modul în momentul în care instanta pornește. Primul pas este sa ne definim task-ul în *.csdef.
Atributul TaskType specifica modul în care as fie rulat acest task:
Din cauza ca instalam un nou modul de IIS, inițializarea rolului s-ar putea sa dureze mai mult (~5 minute în plus în cazul unei instante de tip small).
2. Următoarea soluție pe care am găsito este sa implementam interfața IHttpModule și sa ne definim un modul http propriu. In momentul în care acesta se inițializează ar trebuii sa citească lista de IP-uri restricționate dintr-o anumita locație, iar apoi la fiecare acces, în funcție de IP-ul clientului sa nu permită accesul la aplicația pentru anumite IP-uri.
Daca in prima varianta partea de filtrare o face în totalitate IIS-ul, în a doua varianta acest lucru o sa îl facă codul nostru. Ma aștept ca în viitor sa apară aceasta funcționalitate și în Azure, din aceasta cauza recomand prima varianta.
- Avem un site în cloud. Dorim sa restricționam accesul pe baza de IP. Vrem sa excludem o anumita clasa de IP-uri.
- IPSecurity
- IHttpModule
<location path="CarWebSite">
<system.webServer>
<security>
<ipSecurity>
<add ipAddress="123.456.0.0" subnetMask="255.255.0.0" allowed="false" />
</ipSecurity>
</security>
</system.webServer>
</location>
Mai sus am restrictionat accesul la IP-urile 123.254.0.1 pana la 123.254.255.255 pentru path-ul CarWebSite. Daca am fi pe un Windows Server 2003 acesta setare ar functiona fara nici o problema. In schimb pe Windows Azure o sa avem o mica surpriza. Din cauza ca pe IIS din cloud modulul pentru IP Security nu este (încă) instalat.Pentru a putea totuși sa folosim aceasta funcționalitate trebuie sa facem un mic hack și sa instalam acest modul în momentul în care instanta pornește. Primul pas este sa ne definim task-ul în *.csdef.
<Startup>
<Task commandLine="Startup.cmd" taskType="simple" executionContext="elevated" />
</Startup>
In momentul in care instanta porneste, cmd cu numele specificat o sa ruleze intr-un context elevat (cu drepturi de administrator).Atributul TaskType specifica modul în care as fie rulat acest task:
- Simple - sistemul așteaptă comanda sa se termine de executat, înainte ca un alt task sa fie lansat;
- Background - sistemul nu așteaptă ca cmd-ul sa se termine de executat și trece la următoarea comanda;
- Foreground - la fel ca și Background, doar ca instanta nu se va restarta pana cînd comanda nu se termina de executat;
%windir%\System32\ServerManagerCmd.exe -install Web-IP-Security
%windir%\system32\inetsrv\AppCmd.exe unlock config -section:system.webServer/security/ipSecurity
Acest fisier trebuie sa fie in root-ul proiectului si sa aibe setat flag-ul Content setat cu valoarea Copy Always. Dupa ce o sa facem deploy la solutie, filtrarea după ip-uri ar trebui sa functioneze.Din cauza ca instalam un nou modul de IIS, inițializarea rolului s-ar putea sa dureze mai mult (~5 minute în plus în cazul unei instante de tip small).
2. Următoarea soluție pe care am găsito este sa implementam interfața IHttpModule și sa ne definim un modul http propriu. In momentul în care acesta se inițializează ar trebuii sa citească lista de IP-uri restricționate dintr-o anumita locație, iar apoi la fiecare acces, în funcție de IP-ul clientului sa nu permită accesul la aplicația pentru anumite IP-uri.
public class IPBlockHttpModule : IHttpModule
{
private void HandleBeginRequest( object sender, EventArgs evargs )
{
if (!sender is HttpApplication)
{
return;
}
HttpApplication app = (HttpApplication)sender;
string IPAddress = app.Context.Request.ServerVariables["REMOTE_ADDR"];
if (string.IsNullOrEmpty(IPAddress))
{
return;
}
if (IsBlockedIP(IPAddress))
{
app.Context.Response.StatusCode = 404;
app.Context.Response.SuppressContent = true;
app.Context.Response.End();
return;
}
}
}
In momentul în care se face un request verificam dacă ip-ul clientului este are drepturi sa acceseze situl. In cazul în care acesta nu are drepturi returnam eroarea 404. Metoda IsBlockedIP verifica dacă IP-ul clientului are drepturi sa acceseze situl nostru.Daca in prima varianta partea de filtrare o face în totalitate IIS-ul, în a doua varianta acest lucru o sa îl facă codul nostru. Ma aștept ca în viitor sa apară aceasta funcționalitate și în Azure, din aceasta cauza recomand prima varianta.
Nu ar merge sa definesti un rule nou in firewall-ul de pe guest machine, cu un startup task care sa ruleze ceva gen:
ReplyDeletenetsh advfirewall firewall add rule ...
?
Ba da, cred ca s-ar putea folosi fără probleme. Regula care ar trebui sa fie de forma:
ReplyDeletenetsh advfirewall firewall add rule name=”Regula1” dir=in action=allow enable=yes remoteip=123.123.0.1,134.123.0.0/16,LocalSubnet profile=domain