Category Archives: Felhő

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:

Meglepő kapcsolat bontások SQL Azure-ban

Gyakran lehet találkozni azzal a ténnyel, hogy mivel az SQL Azure ugyanazt a tabular data stream (TDS) protokollt támogatja, mint a teljes SQL Server, a programozási modell teljesen azonos a két esetben. Ebből viszont – a közhiedelemmel ellentétben – nem következik az, hogy az alkalmazásunk felhőbe költöztetése mindössze annyiból áll, hogy átállítjuk a connection stringet!

Az SQL Azure ugyanis számos olyan esetben is hajlamos bontani a kapcsolatot, amihez nem vagyunk hozzászokva a saját szervereinken. Íme két példa:

  • 40197 – The service has encountered an error processing your request. Please try again.
  • 40501 – The service is currently busy. Retry the request after 10 seconds.

Ennek az alapvető okai a hibatűrésben és a rendelkezésre állásban keresendőek. Ha a kérés kiszolgálásában részt vevő valamelyik szereplő hibás lesz vagy épp frissül, akkor a felhőnek köszönhetően nem lesz tartós leállásunk, de szolgáltatás visszaállásáig (ami rövid idő) a kapcsolatokat bontani fogja a szerver. A másik ok, hogy mivel az adatbázisok osztoznak bizonyos erőforrásokon, az SQL Azure query és connection throttling szolgáltatásai biztosítják, hogy egyik ügyfél se akaszthassa le teljesen a kiszolgálást. Ha túllépjük a limitet, hibát fogunk kapni.

Mindennek az az eredménye, hogy időnként elszállnak az adatbázis lekérdezéseink, de mivel ezek okai alapvetően átmeneti jelenségek, bátran megismételhetjük a lekérdezést kicsit később. Ez sajnos nagyon kellemetlen, mert általában arra számítva írjuk meg az adatelérési rétegünket, hogy ha az adatbázis nem elérhető, akkor nagy baj van, és nem szoktunk arra számítani, hogy a hiba másodperceken belül megszűnik magától.

Magyarul: SQL Azure-on futó alkalmazások esetén gondoskodnunk kell ezeknek a hibáknak a kezeléséről, és a hiba jellegétől függően meg kell ismételnünk a lekérdezést. Ha korábban nem volt az alkalmazásunkban ilyen intelligens retry-logika, akkor a felhőbe költöztetéskor ezt bele kell tennünk.

Néhány segítség:

 

Technorati-címkék: ,,,

Virtuális gépek védelme a felhőben

Mikor a rendszereinket a felhőbe költöztetjük, annyira meg szoktunk örülni annak, hogy minden “megy magától”, hogy gyakran megfeledkezünk az alapvető biztonsági teendőkről (amiket pedig a saját gépeinken amúgy meg szoktunk tenni). Az első öröm általában akkor ér minket, amikor a varázslóval pikk-pakk létrehozunk egy új virtuális gépet az Azure-ban:

create-vm

A problémák – legalábbis részben – ebből az egyszerűségből fakadnak:

  • A rendszergazda felhasználónevet nem kell megadnunk, sőt nem is lehet (lásd fent, disabled), hiszen az minden esetben Administrator.
  • A gép IP címét nem kell megadnunk, hiszen az Azure a saját tartományából ad majd neki egyet.
  • A RDP-t nem kell beállítanunk, hiszen az minden esetben engedélyezve lesz az alapértelmezett 3389-es porton.

Sajnos ez a kényelem jelentősen megkönnyíti a támadók dolgát: csak végig kell nézniük az Azure IP tartományát és be kell próbálkozniuk a 3389-es porton az Administrator felhasználóval és valamilyen jelszóval. Ilyen RDP brute force támadásra számos eszköz létezik már, és sajnos van már hír olyan esetről is, amikor a támadók sikerrel jártak.

Amit mindenképp érdemes megtenni:

  • Az RDP ne az alapértelmezett porton fusson.
  • Célszerű beállítani, hogy milyen kliens IP címekről lehet RDP-zni a gépre.
  • A rendszergazda felhasználóneve ne az alapértelmezett legyen.
  • Az admin jelszó legyen erős.

Sandrino Di Mattia cikke részletesen leírja, hogy mindezt hogyan tehetjük meg.

 

Technorati-címkék: ,,

Windows Azure Mobile Services

A Microsoft Scott Guthrie blogján keresztül bejelentette a Windows Azure szolgáltatáscsalád legújabb tagját, a Windows Azure Mobile Servicest. Leegyszerűsítve a képletet: az új szolgáltatás segítségével a felhőben lévő SQL táblákban lévő adatainkat publikálhatjuk kliensek felé pillanatok alatt, méghozzá szerver oldali kód írása nélkül.

mobile-services-diagram

A kliens oldali kód megírásához pedig kapunk osztálykönyvtárat, így egészen minimális kódot kell írnunk, például (ScottGu posztjából kölcsönözve):

mobile-services-code

Néhány kiegészítés a cikkhez:

A bejelentés mindenhol Windows 8 kliensről szól, a fenti ábrán is ezek láthatók. Ez valójában egyelőre kizárólag WinRT alkalmazásokat jelent, mert az osztálykönyvtár erre készül.

A névben a “Mobile” szerintem nem kicsit félrevezető. Valójában bármilyen klienssel használható a szolgáltatás, alacsonyabb szinten ugyanis – egyáltalán nem meglepő módon – ODatás HTTP REST API van és JSON formátumú adatok. Hamarosan erről a REST API-ról is lesz leírás és a meghívásukat támogató osztálykönyvtár/metódusok.

Amitől talán valóban kicsit mobilos, az a push notification támogatás, amiben az az izgalmas kérdés, hogy mennyire csak WinRT és mennyire WP7.

Ha már mobil, akkor felmerül az offline elérés kérdése. Ezt jelenleg out-of-the-box nem támogatja a szolgáltatás, kézzel kell megcsinálni. Fontos, hogy a jelenleg.

Van lehetőség felhasználó azonosításra és jogosultság ellenőrzésre is, bár ezen a területen még várható fejlődés.

Lehet saját szerver oldali kódot adni a szolgáltatáshoz, pontosabban Insert, Update, Delete és Read műveletek esetén lefuthat egy általunk megadott JavaScript függvény, amit a Windows Azure Management Portalra kell bemásolnunk (ne ehhez mit szóltok?). Az adatok szerver oldali validálása is így valósítható meg.

A funkció már mindenki számára elérhető, pontosabban csak azoknak, akik engedélyezik a preview szolgáltatásokat a beállítások között. További információ a Windows Azure honlapon a mobile szekción belül a Tutorials and Resources oldalon érhető el.

 

A Windows Azure Mobile Services nyilván nagyon hasznos lesz azoknak, akik 5 perc alatt akarnak feladatlista alkalmazást készíteni Windows 8-ra. És szerintetek még mire?

 

Technorati-címkék: ,,,