Azure

Home > Resourche Group > ott belépni a saját csoportba > ott középen fent: + Create > keresősáv: Microsoft Windows 10 > Create; size: legolcsóbb; inbound ports: http, https, rdp > Create

Négy erőforrás jön létre: a virtuális gép; publikus IP cím; nsg: a Network Security Gruop; a Network Interface: az a NIC, a hálózati kártya; disk

(Szerver létrehozása hasonlósan történik, ott a Windows Server 2019 Datacenter-ből kell választani. A core szerverek GUI nélküliek, keveseb tárhelyet foglalnak, csak parancssorból irányíthatóak.)

A számítógépet két tűzfal védi. A .nsg erőforrásban (network secutity gropu) > bal oldali oszlop: inbound security rules > utána fent: + Add: kijelölni ICMP; az RDP engedélyezése a számítógép létrehozásánál alapból engedélyezve van, különben nem tudnánk elérni a gépet, a portja: 3389;

A virtuális gép belső tűzfalán is engedélyezni kell. Elindítjuk a virtuális gépet (klikk a nevére, majd start); a saját fizikai gépen elindítani a ‘távoli asztali kapcsolat’-ot IP számmal, felhasználónévvel, jelszóval. A virtuális gép ablakában: start menű > beír: firewall > inbound rules > ICMPv4 > enable rule. Innentől pingelhető a számítógép.

Kapcsolat létesítése Powershellen keresztül a fizikai gépről: először mindkét gépen a Powershell ablakban (rendszergazdai indítással) beírjuk a másig gép IP számát a következő scripttel:

$IPnumber = Read-Host -prompt "Írja be az IP számot!"
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "$IPnumber" -Force -Concatenate
Get-Item WSMan:\localhost\Client\TrustedHosts

Fogalmak: a WinRM (Windows Remote Management – Rendszerfelügyeleti webszolgáltatás egy szoilgáltatás (service), a protokollja pedig a WSMan (Web Services Management) A WSMan továbbá egy ‘meghajtó’ is a Powershellben. További meghajtók kilistázása: Get-PSDrive.

A WSMan tehát tkp. egy meghajtó a Powershellben, pl. Set-Location wsman: paranccsal be tudunk lépni. Ehhez először a services-ben el kell indítani a WinRM szolgáltatást. Powershellből a (get-service winrm).start() paranccsal. Ez egy könyvtárstrukturát tartalmaz, aminek a Get-Item WSMan:\localhost\Client\TrustedHosts fájlja tartalmazza a megbízható hostok IP számait. A távoli számítógép nsg erőforrásában engedélyezni kell az 5985-ös portot a WinRM számára, s ugyanígy a tűzfalán is. A következő scripttel tudunk belépni a fizikai gépről:

$IPnumber = Read-Host -prompt "az IP szám"
$userName = Read-Host -promt "Felhasználónév"

New-PSSession -ComputerName $IPnumber -Credential $userName
Get-Pssession | Format-Table
Write-Host "belépés a sessionba: Enter-PSSession <session numberje>"

Máshogy:

$IPnumber = Read-Host -prompt "Kérem az IP számot"
$username = Read-Host -prompt "Kérem a felhasználónevet!"
$password = Read-Host -prompt "Kérem a jelszót" -AsSecureString
$myCredential = New-Object System.Management.Automation.PSCredential ($username, $password)

New-PSSession -ComputerName $IPnumber -Credential $myCredential
Get-Pssession | Format-Table
Write-Host "belépés a sessionba: Enter-PSSession <session numberje>"

Ekkor a Powershellben ilyen prompt jelenik meg:
[a távoli gép IP száma]: PS C:\Users\felhasználónév\Documents>; kilépés az exit paranccsal.

Parancs futtatása Invoke-Command utasítással. Ez most a távoli gép biosának a gyártóját kérdezi le.

$IPnumber = Read-Host -prompt "az IP szám"
$userName = Read-Host -promt "Felhasználónév"
Invoke-Command -ComputerName $IPnumber -Credential $userName -ScriptBlock { Get-Computerinfo }

Érdekesség: Létrehoztam egy virtuális gépet Dél-Ausztráliában, majd tracert-tel ellenőriztem az oda vezető utat. Az Azure globális kábelhálózatának a térképe itt található: infrastructuremap.microsoft.com/explore. A következő állomások váltak láthatóvá a 31 ugrás során:

6 16 ms 18 ms 19 ms vodafonehungary.bud01-96cbe-1a.ntwk.msn.net [104.44.198.107] – Bp
7 17 ms 24 ms 18 ms 104.44.230.243 – ?
8 264 ms 261 ms 272 ms be-150-0.ibr03.vie.ntwk.msn.net [104.44.11.101] – Bécs
9 262 ms 262 ms 260 ms be-3-0.ibr02.mrs20.ntwk.msn.net [104.44.7.49] – Marseille
10 260 ms 265 ms 262 ms be-5-0.ibr01.zrh20.ntwk.msn.net [104.44.19.6] – Zurich
11 261 ms 261 ms 266 ms be-8-0.ibr01.gva20.ntwk.msn.net [104.44.19.35] – Geneva
12 264 ms 264 ms 265 ms be-7-0.ibr01.mrs21.ntwk.msn.net [104.44.29.68] – Marseille
13 266 ms 261 ms 268 ms be-21-0.ibr01.mrs20.ntwk.msn.net [104.44.28.163] – Marseille
14 263 ms 263 ms 263 ms be-19-0.ibr01.sin30.ntwk.msn.net [104.44.28.184] – Singapore
15 270 ms 277 ms 264 ms be-17-0.ibr01.sg3.ntwk.msn.net [104.44.28.36] – Singapore
16 262 ms 262 ms 267 ms be-12-0.ibr01.per01.ntwk.msn.net [104.44.19.137] – Perth
17 264 ms 264 ms 262 ms be-4-0.ibr01.mel01.ntwk.msn.net [104.44.19.156] – Melbourne
18 260 ms 262 ms 261 ms ae102-0.icr02.mel01.ntwk.msn.net [104.44.11.152] – Melbourne

Azaz a jel Marseilleből ment Singapore-on át az ausztál Perth-be tengeralatti kábeleken. A Melbourne utáni routerek esetében request timed out következett be.

Webszerver microsoftul: IIS

Widows Server 2019 Datacenter létrehozása (testkérdés: min. ram: 521 Byte); belépve: Servere Manager – a Microsoft GUI felülete A szerver ROLE (szerepeket) tölt be > Add roles and features > Role-based or feature-based installation. Először Web szervert telepítünk, a neve a Microsoftnál: IIS – Internet Information Services; egyéb dependency-ket is hozzá akar adni > install; weboldal megtekintése belső böngészőben: http://localhost/; az .nsg csoportban engedélyezni kell a 80 és 443 portokat. A tűzfal elvileg engedélyezi a IIS webszerver létrejöttekor. A weboldal gyökérkönyvtára: C:\inetpub\wwwroot (inetpub = ‘internet publishing’)

Active directory

Active Directory Domain Services role installálása; Server Manager > manage > add :Active Directory Domain Services; ezután kéri: ‘promote this server to a domain cotroller’ > először egy erdőt kell létrehozni, hiszen még nincs se erdő, se domain-ek; a domain név legyen két tagú, a tld ne legyen olyan végződés, ami létezik a neten: pl IslandOfPleasure.yeah; Az AD a gépek között névfeloldással működik, így automatikusan létre fog hozni egy DNS szervert is.

Két fontos GUI a start menűből: Active Directory Users and Computers, ill. Group Policy Management.

Az IslandOfPleasure.yeah domain alatt hozzunk létre három új organization unit-ot: IoPusers;IoPcomputers;IoPgroups; az IoPusers alatt hozzunk létre egy új felhasználót: Örvendező Teréz: terez.orvendezo; a logon neve ez lesz: terez.orvendezo@IslandOfPleasure.yeah; thisPc > properties > remote settings > select user > hozzáadni; továbbá: AD > Örvendező Teréz > properties > member of > hoozáadni a Domain Guests csoporthoz. Ekkor be tud lépni a távoli asztali kapcsolat protokollal.

Password Policy készítése

Strat menű > Group Policy Management > Forest > Domains > IslandOfPleasure.yeah > Group Policy Object > new > létrehoz pl. PasswordPolicy > edit > Computer configuration > Policies > Windows settings > Security Settings > Account Policies > Password Policy

A policy-k frissítése pullal történik 90-120 percenként, így a command line-ből tudjuk force-olni: gupdate /force

Ezután a Group Policy Managementben vissza kell menni a domeinhez: IslandOfPleasure.yeah, jobb egér: Link an existing GPO – ezzel hozzálinkeljük az új policy-t a domain-hez.

A Microsoft és XIII. Gergely pápa – avagy mit keres a GUID generátorban az 1582. október 4 dátum?

A GUID és az UUID

A GUID, a globálisan egyedi azonosító (Globally Unique Identifier) a microsoftos implentációja az UUID, az univerzálisan egyedi azonosító (Universally Unique Identifier) szabványára. Ez egy 16 byte hosszúságú álvéletlen szám (16 byte = 128 bit), ami 2128 variációt tesz lehetővé, ami nagyságrendileg 3.4 x 1038. Ez azért is nagy szám, mert pl. a látható univerzum átmérője 38.8 x 1026 méter, s így a fenti variációk száma tkp. egymilliárdszorosa annak, mint ahány milliméter az univerzum átmérője.

Azaz ha van sok dolgunk, s mindegyiknek akarunk adni egy egyedi azonosítót, akkor egyszerűen kap mindegyik egy ilyen álvéletlen számot. Mivel a variációk száma felfoghatatlanul nagyobb, mint a dolgok száma, így nem valószínű, hogy két dolog ugyanazt az azonosítót kapja. (Ami persze nem kizárható, de a valószínűsége gyakorlatilag 0.)

A szám generálása

A Microsoft egy 2005-ös dokumentuma szerint

4.1.4.  Timestamp
 
   The timestamp is a 60-bit value.  For UUID version 1, this is
   represented by Coordinated Universal Time (UTC) as a count of 100-
   nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of
   Gregorian reform to the Christian calendar).
 
   (...)
 
   For UUID version 3 or 5, the timestamp is a 60-bit value constructed
   from a name as described in Section 4.3.
 
   For UUID version 4, the timestamp is a randomly or pseudo-randomly
   generated 60-bit value, as described in Section 4.4.
 

Azaz az implementáció a 128 bites szám előállításához generál egy 60 bites időbélyegzőt, ami megmondja, hogy 1582 október 15. óta hányszor 100 nanoszekundum (a másodperc milliárdod része) telt el. Ez pedig annak a dátuma, amikor XIII. Gergely pápa bevezette a róla elnevezett Gergely naptárt.

Gergely pápa naptárreformja

Előzőleg a Juliánus naptárt használták, amit Julius Caesar vezetett be, ahol egy év 365 napból állt, s minden negyedik szökőévben egy szökőnapot iktatott be. Így egy év 365.25 napból áll (365 nap és 6 óra). Ugyanakkor egy év valójában 365 nap 5 óra 48 perc 46 másodpercből áll, így a különbség évente 11 perc 14 másodperc. Ennek pedig az volt a következménye, hogy amikor a szökőévben az évhez hozzátoldjuk a szökőnapot, akkor még pluszban hozzáadjuk ennek az eltérésnek a négyszeresét,  44 perc 56 másodpercet. Ez pedig 128 év alatt egy napot eredményezett, azaz 128 évente mindig egy további nappal előrébb ugrik ugyanaz a dátum. S ebből eredően XIII. Gergely korára már 10 nap volt az eltérés, így a pápa az Inter Gravissimas kezdetű bullájával rendelte el, hogy 1582 október 4.-ét október 15.-e kövesse, s a köztük lévő napok abban az évben kimaradtak a naptárból.

Azt pedig, hogy a továbbiakban a 128 évente előálló napok ne torlódjanak fel, azt Gergely pápa egy szellemes megoldással előzte meg. Mivel ez 400 évente jelentett kb. 3 napot, ezért a 400-zal nem osztható kerek évszázadok nem számítanak szökőévnek. Így pl. 1900 nem volt szökőév, 2000 viszont igen.

A timestamp a generált UUID számban

A uuidgenerator.net oldalon az 1. verziószámú UUID generátorral generálok egy számot. Ez egy 128 bites hexadecimális szám lesz: 6fe163202eb4-11ec-8d3d-0242ac130003. Ebből a 60 bites időbélyegző: 1ec2eb46fe16320 A szabványnak megfelelően először az időbélyegző alsó bitjei, majd a középső bitjei, s végül a felső bitjei következnek a számsor elején. Az utolsó, a felső bitek szakasza egy 1-sel kezdődik, ami nem tartozik az időbélyegzőhöz, hanem a generáló UUID program verzióját jelzi. Azaz ez az érték az első verzióval készült.

      UUID                   = time-low "-" time-mid "-"
                               time-high-and-version "-"
                               clock-seq-and-reserved
                               clock-seq-low "-" node
      time-low               = 4hexOctet
      time-mid               = 2hexOctet
      time-high-and-version  = 2hexOctet
      clock-seq-and-reserved = hexOctet
      clock-seq-low          = hexOctet
      node                   = 6hexOctet

A timeanddate.com oldal szerint a Gregorián naptár bevezetése óta a poszt írásának a dátumáig 160 344 nap telt el. A fenti hexadecimális számot átváltva decimális számrendszerbe a következő értéket kapjuk: 138537041047675680. A UUID értéke szerint ennyiszer 100 nanomásodperc telt el azóta. Ezt átszámítva napokká, azt kapjuk, hogy az 160 343,79 nap. A két érték sacc/kábé még stimmel is.

A hexadecimális kódban az utolsó egység, a node mező – egy 12 számjegyű hexadecimális szám – a kódot generáló számítógép hálózati kártyájának a Mac addresse. Ez esetünkben nem a blogger gépének, hanem a neten a számot generáló programot futtató szerver gépének a fizikai címe.

Biztonsági probléma

Az 1. verziószámú UUID programmal létrehozott véletlenszámból tehát ki lehet olvasni az azt létrehozó számítógép Mac address-ét, ami biztonsági probléma, hiszen a világon minden hálózati kártya egyedi Mac address-t használ. Így a mai UUID generátorok már nem használják fel a Mac address-t a véletlenszám létrehozásához.

Annak idején ez a biztonsági rés vezetett el a Melissa vírus írójához. A vírus volt az első jelentősebb vírus, amely emailekben terjedt. A fertőzött levél tárgya: “Important Message From …”, szövege pedig: “Here is that document you asked for … don’t show anyone else 😉“, a mellékelt dokumentum pedig pornóoldalak listáját tartalmazta. A megfertőzött gép ezután ugyanezt a levelet továbbküldte a felhasználó kapcsolati listáján szereplő első 50 címnek. A vírus 1999. március 26-án kezdett el terjedni, s akkora forgalmat generált, hogy több nagy cég – köztük a Microsoft – levelezési rendszere leállt. S a fenti biztonsági rés vezetett el a vírus írójához, ugyanis a víruskód tartalmazott egy GUID számot, amelyből így ki lehetett olvasni a vírust író személy gépének a Mac address-ét.

A Carrington-esemény a korabeli magyar sajtóban – 1859

I.

A Carrington-esemény

Az 1859-ben bekövetkezett Carrington-esemény az írott emberi történelem második legnagyobb napkitörése volt. A Napból kizúduló töltött részecskeáram olyan erős volt, hogy a földet elérvre komoly problémákat okozott az akkori távíró hálózatban (vezetékek néhol szikrázni kezdtek, ill. távíróhivatalok gyulladtak ki, néhol pedig a hálózatot az azt működtető akkumulátorok nélkül is lehetett használni), ill. olyan erős északi fény lépett fel, hogy azt még Kolumbia egyenlítői vidékén is észlelték és éjjel még a szabad ég alatt is kényelmesen lehetett olvasni.

Ha egy ilyen napkitörés ma következne be, akkor annak katasztofális következményei lennének. Ugyan lenne valamennyi idő a felkészülésre, s az elektronikus rendszerek lekapcsolására, mivel műholdak már a kitörése pillanatában észlelik a napkitörést, s ezután csak három nappal érkezik ide a töltött részecskék vihara. Egy lehetséges forgatókönyv szerint a napkitörés követő 72. órában, amikor megérkezik a Napból származó lökéshullám, akkor:

Egy kattintás ide a folytatáshoz….

A csavart érpár fizikája – avagy: hány méter egy bit?

A csavart érpár

csavart érpárA csavart [sodort, sodrott] érpárban 4 pár szigetelt rézvezeték halad páronként felcsavarva úgy, hogy páronként más-más a felcsavarás sűrűsége. A képen látható kábel pontos neve: árnyékolatlan csavart érpár (UnshieldedTwisted Pair – UTP)

A csavarás az árnyékolást szolgálja, ez csökkenti az interferencia jeltorzító hatását.

A probléma

A Wikipédia a következőképpen írja le, hogy a csavart érpár esetében a csavarás hogyan járul hozzá a zajok kiszűréséhez. A poszt ezt a kérdést fejti ki bővebben.

Egy kattintás ide a folytatáshoz….

Server, stream, XSS támadás – (Node.js – 2)

A kódbazis.hu (Bolgár Máté) Node.js tutorial videói alapján.

Szerver létrehozása

A Node.js-ben beépített könyvtárak vannak, azokhoz is a require() utasítással tudok hozzájutni. A http könyvtárral tudok szervert létrehozni. Google keresés: nodejs create server: How do I create a HTTP server? | Node.js – ott szereplő kód snippet:

const http = require('http');

const requestListener = function (req, res) {
     res.writeHead(200);
     res.end('Hello, World!');
} 

const server = http.createServer(requestListener);
server.listen(8080);
Egy kattintás ide a folytatáshoz….

A wrapper function (Node.js – 1.)

A kódbazis.hu (Bolgár Máté) Node.js tutorial alapján.

A Node.js egy futtató környezet, ami lehetőséget nyújt JavaScriptben írt programok futtatására. JavaScriptet leginkább kliens oldalon szoktak használni a böngészőn keresztül. A Google Chrome böngésző JavaScriptet futtató motorja a V8 engine, aminek a fejlesztése 2006-ban kezdődött. Neve játékos utalás a V8 benzinmotorok teljesítményére (a V8 motorokban 8 henger van két sorban elhelyezve, melyek ‘V’ betűt formázó szöget zárnak be). A Node.js is ezt a motort használja némi módosítással, továbbá beépített könyvtárakat tartalmaz. Alapvetően webszerverek készítésére hozták létre.

Egy kattintás ide a folytatáshoz….

Rxjs – Observable

Mi ez?

Az Observable tkp. olyan mint a Promise, de nem része a JavaScript szabványnak. Az Observable szó azt jelenti, hogy ‘megfigyelhető‘, azaz egy olyan objektum, amelyik folyamatosan változik és meg lehet figyelni, és az alkalmazás különböző pontjain különböző megfigyelők iratkozhatnak fel rá.

  • lehet több megfigyelő
  • az esemény bekövetkeztéről mindenki könnyen értesülhet
  • az eseményeket mint adatfolyamot kezeljük
  • lehet manipulálni (pl. filter, map)
  • mellékhatásokat tudunk vele kiváltani (pl. kiiratjuk az értéket a konzolra)
Egy kattintás ide a folytatáshoz….

A lebegőpontos számábrázolás – avagy: amikor a fal adja a másikat

Az alapok

Az alapokat nem írom le. Rengeteg helyen elmagyarázzák. Jómagam pl. innen értettem meg – bevallom, nagyon nehezen ment, mert kicsit idegen a mindennapok világától a lebegőpontos számábrázolás szemlélete, s ha szükség van rá, bármikor belezavarodok magam is: https://gyires.inf.unideb.hu/GyBITT/31/ch05s05.html

A lényeg az, hogy a JavaScript a 64 bit hosszúságú, ún. dupla pontosságú lebegőpontos számábrázolást (double precision floating point format) használja, ahol a felosztás: 1 bit előjel – 11 bit kitevő – 53 bit mantissza. Viszont 1 + 11 + 53 = 65, ami 1-gyel több, mint 64. A mantissza ui. mindig egy 1-es rejtett bittel kezdődik, amit nem írunk ki. A kitevők ábrázolása viszont csak 1024-ig lehetséges (210) a feszített előjeles ábrázolás miatt.

write(), writeln() – egy kis JavaScript történelem

Egy vizsgateszt kitöltése során találkoztam a JavaScript document.write() utasítással – viszont erről az utasításról még az életben nem hallottam, bár már megszoktam, hogy a vizsgatesztben gyakran olyasmi szerepel, amiről egy szó sem esett az (állami) tanfolyamon, de még a leckék után felsorolt dokumentációkban sem. Úgyhogy utána néztem, s elég érdekes dolgok derültek ki.

Egy ma már alig használt metódus

Napjainkban már a böngészőben megjelenő oldalt leképező DOM fa manipulálása a .js fájlban történik, ill. az utasítás tesztelhető a konzolon. Ha ide írom be a document.write(“Hello, world!”) parancsot, akkor a böngészőből eltűnik az eredeti dokumentum, s csak annyi jelenik meg egy üres oldalon, hogy: Hello, word! – Szemben az .innerHTML metódussal, ami documentumon belül változtatja meg egy element – böngészőben megjelenő – tartalmát, s nem tünteti el az eredeti oldalt.

Egy kattintás ide a folytatáshoz….

Docker

oktatóvideó: sanfranciscoboljottem.com – Docker ismeretek; Kódbázis: Docker

Telepítés: docker.com/product/docker-desktop; egy program, amit írtunk, adott operációs rendszeren, adott futtatókörnyezetben lett megírva. Ha egy másik gépen akarjuk futtatni, akkor ugyanezt a szoftveres környezetet kell létrehozni azon a gépen. A docker egy elszeparált környezetben (ez a konténer) létrehozza a programot futtató környezetet és elraktározza a programot, majd felteszi ezt egy felhőbe. Ezt a konténert onnan letölthetem más gépre, s ott – a szoftveres környezet nélkül is – futtathatom a programot a konténerből.

Egy kattintás ide a folytatáshoz….