Felhő kategória bejegyzései

IP szűrés Amazonban futó IIS-en

Az Amazon EC2 felhőjében nagyon egyszerűen hozhatunk létre terheléselosztott webszolgáltatásokat: csak felkattintunk két virtuális gépet, bekötjük őket a terheléselosztó mögé és már pöfögnek is vidáman. A sötét felhők akkor kezdenek gyülekezni az ember feje felett, amikor kiderül, hogy az IIS-ben beállított IP szűrés nem működik és a weboldalunkat bárki elérheti.

A gondot az okozza, hogy a virtuális gépeken futó IIS a terheléselosztót látja kliensként, nem pedig az eredeti böngészőt. (Annak az IP címére tökéletesen menne az IP szűrés, de arra pont nincs szükségünk.) Aki nem hiszi, nézzen utána az IIS naplófájljaiban.

Szerencsére az Amazon terheléselosztója támogatja a Proxy protokollt, aminek a lényege, hogy a valódi kliens IP címe az X-Forwarded-For HTTP fejléc mezőben továbbításra kerül. Az IIS alapból nem naplózza ennek a fejlécnek az értékét, de könnyen megkérhetjük rá:

iis-proxy-logging

További jó hír, hogy az IIS-t rávehetjük arra, hogy az X-Forwarded-For mező alapján végezzen IP szűrést. Ezt IIS 7 esetén a Dynamic IP Restriction modullal tudjuk megtenni, IIS 8-tól kezdve pedig az IP Address and Domain Restrictions modul része lett ez a funkció. Telepítés után nincs bekapcsolva, de egy kattintással aktiválhatjuk:

iis-proxy-mode

 

Technorati-címkék: ,,

Árulkodó HTTP fejlécek eltávolítása

Ha megnézzük egy ASP.NET alkalmazásunk hálózati forgalmát, akkor könnyen felfedezhetjük az alábbi fejléceket a HTTP válaszban:

Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 5.0

Ezek a fejléc mezők egyáltalán nem befolyásolják az alkalmazás működését, az egyetlen céljuk, hogy a Bing bot több információt nyerjen a webhelyről.

Sajnos azonban ezek a fejlécek a támadók dolgát jelentősen megkönnyítik, hiszen ha pontosan ismert a platform és a verziószám, akkor már elég csak azokkal az támadásokkal próbálkozni, amik ebben a környezetben működnek. Éppen ezért biztonsági okokból célszerű megváltoztatni az alapbeállításokat és eltávolítani ezeket a fejléceket.

 

Server

A Server fejléc “sugárzása” bele van drótozva az IIS-be, én nem tudok olyan kapcsolóról, amivel kényelmesen kikapcsolható lenne. Lehet használni az UrlScant, bár az az eszköz utoljára 2008-ban frissült. Ha ASP.NET alkalmazásunk van, akkor a global.asax-ban leszedhetjük ezt a fejléc mezőt, mielőtt a HTTP válasz kimenne a szerverről:

protected void Application_PreSendRequestHeaders()
{
  this.Response.Headers.Remove( "Server" ); }

 

X-Powered-By

Az X-Powered-By fejlécet az IIS pakolja rá a HTTP válaszokra, így akár szerver szinten megszabadulhatunk tőle az IIS Managerben:

header-x-powered-by

 

Vagy akár web.configban is:

<system.webServer>
   <httpProtocol>
     <customHeaders>
       <remove name="X-Powered-By" />
     </customHeaders>
   </httpProtocol>
</system.webServer>

 

X-AspNet-Version

Az X-AspNet-Version fejlécet viszonylag egyszerű kikapcsolni a web.configban:

<httpRuntime enableVersionHeader="false" />

 

X-AspNetMvc-Version

Az X-AspNet-Version fejlécet az alkalmazásunk indulásakor kapcsolhatjuk ki:

protected void Application_Start()
{
MvcHandler.DisableMvcResponseHeader = true; }

 

Ha mindezeket a beállításokat egyszerűbben szeretnénk elvégezni, akkor támaszkodhatunk a CodePlexen ingyenesen elérhető NWebsec projektre, amely a konfiguráció szigorításán kívül további lehetőségeket nyújt MVC-s és Azure-os projektek számára, illetve a session kezelés biztonságosabbá tételére. Ezek a funkciók egymástól függetlenül, önállóan is elérhetők NuGet csomagok formájában.

 

Technorati-címkék: ,,

Azure sebesség teszt

Ha aszerint akarod eldönteni, hogy melyik Windows Azure adatközpontban legyen az alkalmazásod, hogy melyik a leggyorsabb, akkor a Windows Azure Speed Test oldal segítségével összemérheted őket:

http://azurespeedtest.azurewebsites.net/

 

Köszönet a linkért Gál Tamásnak.

 

Technorati-címkék: ,

Visual Studio változatok

A héten megjelent Visual Studio Online (korábbi nevén Team Foundation Service) tovább bővítette a Visual Studio változatok korábban sem éppen átlátható kínálatát. Már ennyi féle van (nem beszélve az Express termékekről):

Összehasonlító táblázatok:

A licenceléssel kapcsolatos leggyakoribb kérdéseket a 34 oldalas Visual Studio and MSDN Licensing White Paper foglalja össze, ez is frissült most novemberben.

 

Technorati-címkék: ,,

Több website-ot tartalmazó solution publikálása Azure-ra

Az Azure Websites egyik kiváló szolgáltatása, hogy közvetlenül hozzá lehet kapcsolni forráskód kezelő rendszerhez, így amikor a forráskód frissül, az automatikusan azonnal kikerülhet a felhőbe.

Ezt pofonegyszerű összevarázsolni, csak indítsuk el a New –> Compute –> Web Site –> Custom create varázslót:

multisite-new

Az első lépésben adjunk nevet a webhelynek, és pipáljuk be a Publish from source control jelölőnégyzetet:

multisite-name

Ennek hatására megjelenik a varázsló második lépése, ahol kiválaszthatjuk a forráskódkezelő rendszerünket, például GitHubot:

multisite-where

GitHub esetén egy OAuthos authentikáció következik, majd meg kell adnunk, hogy melyik repository-nak melyik ágát (már nem csak mastert lehet!) kívánjuk erre a webhelyre publikálni:

multisite-repo

A pipára kattintva meg is történik a varázslat, pár másodperc alatt létrejön a webhelyünk és már települ is rá az alkalmazás.

De mi van akkor, ha a forráskód olyan Visual Studio solutiont tartalmaz, amiben több webes projekt vagy több website van, melyik fog települni? Az első.

Azonban mi nem mindig ezt szeretnénk.

Ha az Azure website-ra mindig a solution egyik projektjét kívánjuk telepíteni, akkor létrehozhatunk a repo gyökerében egy .deployment nevű INI fájlt, amiben megadhatjuk a telepítendő projektet:

[config]
project = MySolution/MyWebProject.csproj

Előfordulhat azonban, hogy több Azure website-unk van, és az egyikre a solution egyik webes projektjét, a másikra a másik webes projektjét kívánjuk telepíteni. Ebben az esetben a beállítást nem drótozhatjuk bele a forráskódba, hanem a felhőben kell trükköznünk. Látogassunk el a CONFIGURE oldalon belül az app settings szekcióba, ahol vegyünk fel egy új beállítást Project néven:

multisite-appsettings

Az értékként adjuk meg a .csproj fájlra vagy az ASP.NET website mappájára mutató repo-gyökér relatív elérési utat.

Mentés után a következő deploymentnél már ennek figyelembe vételével fog történni a telepítés.

 

Technorati-címkék: ,,,

Szerepelsz a Google reklámjaiban

Szeretnél híres lenni? A Google azzá tesz! A cég egy általa “minor update”-nek titulált frissítésben november 11-től bevezeti, hogy a felhasználók személyes adatait megjelenítheti a Google oldalakon feltűnő reklámok mellett.

Ha ezt nem szeretnéd, itt tilthatod le: Megosztott ajánlások

 

Technorati-címkék: ,,

Azure AD számokban

Néhány érdekes szám az Azure AD-ról:

  • Több, mint 430 milliárd authentikáció, június óta 43%-os emelkedés.
  • 10 milliárd authentikáció/hét.
  • 1.4 millió vállalat, iskola, kormányhivatal és non-profit szervezet használja az Azure AD-t és ez a szám július óta duplázódott.
  • 240 millió felhasználói fiók
  • 127 országban
  • 14 adatközpontban

Forrás: http://blogs.technet.com/b/ad/archive/2013/10/04/an-update-on-dates-pricing-and-sharing-some-cool-data.aspx

Szerintem a legérdekesebb az, hogy a Microsoft felhőszolgáltatásai milyen rohamtempóban fejlődnek, főleg mióta ScottGu vezeti a csapatot.

 

Technorati-címkék: