Skip to Content

Hungarian Unix Portal

Tartalom átvétel
"UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." - Dennis M. Ritchie
Frissítve: 10 perc 5 másodperc

C:\Windows\perfc - helyi kill switch a Petya ellen

1 óra 29 perc

98% sure that the name is is perfc.dll Create a file in c:\windows called perfc with no extension and #petya #Nopetya won't run! SHARE!! https://t.co/0l14uwb0p9

— Amit Serper (@0xAmit) June 27, 2017

Amit Serper azt állítja, hogy ha létrehoznunk a C:\Windows\ könyvtárban egy perfc nevű fájlt (kiterjesztés nélkül), az helyi kill switch-ként működik és a Petya nevű ramsomware ha rátalál, nem titkosítja a gépen található fájlokat.

Kategóriák: Informatika

Miért fut Windows az ATM-en?

5 óra 43 perc

kertib írta:

Idézet:
Kedves Trey!

Szeretném felvetni témanak, hogy "Miért fut Windows az ATM-en?"

Engem személy szerint megdöbbentett ez a kép:

http://img4.hvg.hu/image.aspx?id=e59cce47-3569-4de9-a62d-89b6130d06dc&view=54bc8a0e-b0dc-4420-8864-2b54f4f60ed5

  • Az adatok (PIN kód, számlaszám) is kikerülhetnek egy ATM-ből?
  • Hogy tud megfertőzni egy vírus egy ATM-et?
  • Futhatna pl. valamilyen BSD is egy ATM gépen?

Azért főoldalra és nem fórumra szánnám ezt a vitaindítót, mert hátha vannak olyan HUP tagok akiknek rálátásuk van a banki tranzakciós rendszerekre és bizonyos határokon belül (nyilvánvaló banki és biztonságtechnikai) hajlandóak lennének erről megosztani a veleményüket.

Kategóriák: Informatika

Programozás élőben

5 óra 44 perc

A net történetében talán először, élőben közvetíti a Vivaldi ahogy fejlesztőjük beolvasztja a szinkronizációs lehetőséget a böngészőbe. Sync live coding - Starts Jul 5th at 1:00 PM CEST. Bővebben itt.

Kategóriák: Informatika

2,42 milliárd eurós bírságot szabott ki az Európai Bizottság a Google-re

2017, június 27 - 13:21

European Commission fines Google €2.42B https://t.co/csn9bsXEqA

— Hacker News (@newsycombinator) June 27, 2017

Az Európai Bizottság 2,42 milliárd eurós bírságot szabott ki a Google-re, mint keresőmotorra erőfölénnyel való visszaélés miatt. Részletek a bejelentésben.

Kategóriák: Informatika

Hibás a hyper-threading implementáció az Intel Skylake/Kaby Lake processzorokban

2017, június 26 - 20:51

A Debian fejlesztő Henrique de Moraes Holschuh arra figyelmeztet, hogy hibás a hyper-threading implementáció a 6. és 7. generációs (kódnevükön Skylake / Kaby Lake) Intel processzorokban. A fejlesztő azt javasolja, hogy ideiglenes megoldásként az érintett processzorok tulajdonosai tiltsák le a hyper-threading funkcionalitást a BIOS-ban / UEFI-ben:

Idézet:
TL;DR: unfixed Skylake and Kaby Lake processors could, in some situations, dangerously misbehave when hyper-threading is enabled. Disable hyper-threading immediately in BIOS/UEFI to work around the problem. Read this advisory for instructions about an Intel-provided fix.

Henrique de Moraes Holschuh egy perl scriptet tett elérhetővé, amellyel a felhasználók tesztelhetik rendszerük esetleges érintettségét:

#!/usr/bin/perl # Copyright 2017 Uwe Kleine-König # # This program is free software; you can redistribute it and/or modify it under # the terms of the GNU General Public License version 2 as published by the # Free Software Foundation. open(my $cpuinfo, "</proc/cpuinfo") or die "failed to open cpuinfo\n"; my $cpunum, $vendor, $family, $model, $stepping, $microcoderev, $hyperthreading; while (<$cpuinfo>) { if (/^$/) { print "cpu $cpunum: "; if ($vendor eq "GenuineIntel" and $family == 6) { if ($model == 78 or $model == 94) { if ($stepping eq "3") { print "Your CPU is affected, "; if (hex($microcoderev) >= 0xb9) { print "but your microcode is new enough\n"; } elsif ($hyperthreading ne "on") { print "but hyper threading is off, which works around the problem\n"; } else { print "you should install the latest intel-microcode\n"; } } else { print "You may need a BIOS/UEFI update (unknown Skylake-Y/H/U/S stepping)\n"; } } elsif ($model == 85 or $model == 142 or $model == 158) { print "You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)\n"; } else { print "You're likely not affected\n"; } } else { print "You're not affected\n"; } $cpunum = undef; $vendor = undef; $family = undef; $stepping = undef; $microcoderev = undef; $hyperthreading = undef; next; } $cpunum = $1 if /^processor\s*:\s(.*)/; $vendor = $1 if /^vendor_id\s*:\s(.*)/; $family = $1 if /^cpu family\s*:\s(.*)/; $model = $1 if /^model\s*:\s(.*)/; $stepping = $1 if /^stepping\s*:\s(.*)/; $microcoderev = $1 if /^microcode\s*:\s(.*)/; if (/^flags\s*:/) { if (/^flags\s*:.*\bht\b/) { $hyperthreading = "on"; } else { $hyperthreading = "off"; } } }

Részletek itt.

Kategóriák: Informatika

A Microsoft nem patcheli a súlyos WINS sebezhetőséget, aki használja, váltson DNS-re

2017, június 26 - 14:44

"Microsoft will not be patching this vulnerability due to the amount of work that would be required." #Seriouslyhttps://t.co/Y4WGvAltBp

— Wojciech Pawlikowski (@wpawlikowski) June 26, 2017

A FortiGuard Labs 2016 decemberében felfedezett egy súlyos távoli WINS sebezhetőséget a Microsoft Windows Server-ben. 2017 júniusában a Microsoft jelezte a FortiGuard Labs-nak, hogy nem javítja a sebezhetőséget, mert az sok munkával járna. Helyette azt javasolja a WINS felhasználóknak, hogy váltsanak DNS-re. A sebezhetőség érinti a Windows Server 2008, 2012 és 2016 termékeket.

Részletek itt.

Kategóriák: Informatika

Devops: hasznos játék a tűzzel (x)

2017, június 26 - 10:57

Könnyen megégeti magát, aki túl gyorsan vág bele. Tanulságok és tippek egy igazán nagy szervezetből.

A Magyar Telekom saját belső informatikájában az elmúlt években fokozatosan vezette be a devops módszertant a saját rendszerek üzemeltetésében és fejlesztésében. Az átállás kimondottan sikeresnek bizonyult, de nem tanulságok nélkül. Hogy mekkora átállásról van szó, azt jól illusztrálja, hogy a cég rendszerében mintegy 6300 VLAN, 4000 szerver és 800 hálózati eszköz található - egy ügyfél-tranzakció pedig átlagosan 114 különböző alkalmazást, 73 adatbázist, 190 tűzfalat, 145 middleware-t, 595 szoftvert és 23 tárolót érint.

Devops? Egyszerűbb és jobb döntések.

Az egyik legfontosabb érv a devops módszertan bevezetés mellett egy vállalatnál, hogy az összegyúrt csapat komoly (és nagyon hasznos) autonómiát nyer. Míg a fejlesztést és üzemeltetést is érintő kérdésekben korábban az a vezetői szinteken (neadjisten egy egész bizottságban) dőlt el, aki alatt mindkét csapat dolgozott, az összevont csapatok esetében ezek a döntések sokkal alacsonyabb szinten (a csapat vagy annak vezetője szintjén) létre tudnak jönni. Ez lényegesen gyorsabb döntéshozást jelent, nem kell a kérdéseket nehézkesen eszkalálni, majd megvárni, amíg az a megfelelő csatornákon visszacsorog.

Ez a legtöbb esetben egyszerűen jobb döntéseket is jelent, ahogy a fejlesztők és üzemeltetők megismerik egymás szempontjait - és ami sokkal fontosabb, egymás korlátait. Erre rá kell erősíteni a közös felelősség tudatosításával: ha a munkatársak csapatként felelnek a fejlesztési határidők betartásáért és a rendszer stabilitásáért is, akkor hirtelen megváltozik a döntéshozatal dinamikája, bevonják egymást a döntésekbe a fejlesztők és üzemeltetők, kialakul a szokás, hogy megkérdezik egymást a lehetőségekről és az egyes döntések potenciális következményeiről.

Az elvárások átalakítása döntő ebben a kérdésben: korábban a fejlesztőtől kizárólag a gyorsaságot és az új funkciók szállítását, az üzemeltetőtől pedig kizárólag a megbízhatóságot, a szolgáltatás minőségét kértük számon, ami azonnal ütköző pályára is állította a két oldalt. A közös felelősségi körrel ez feloldható és kialakulhat az egészséges kooperáció a csapaton belül.

Az ideális csapatméret meghatározása kemény dió, az ilyen félinformális, nagyon hatékony döntéshozás és kooperáció ugyanis nem skálázódik jól, így bizonyos méret fölött már romlik a csapatok teljesítménye. Az ideális méretet rengeteg faktor befolyásolja, de valahol 5 és 30 fő között érdemes tartani a létszámot.

Vigyázat, buktatók!

A fentiek alapján úgy tűnhet, hogy a devops-ot csak fel kellett találni, ettől a ponttól fogva meg is oldja a szervezet legfontosabb problémáit. Ez sajnos nincs így, az új munkavégzési forma maga is egyedi menedzsment kihívásokat hoz. Az egyik a már említett egyszerűbb döntéshozáshoz kapcsolódik: a sokszáz oldalas fix belső szabyálzatok kidobása ugyan nagyot dob a hatékonyságon, de egyúttal kiiktatja a belső "ellenőrzési pontokat" is, a belső folyamatokkal egyetemben. Az ideális a formalizált folyamatokat valamilyen lazított formában megtartani, mérföldköveket, lépcsőket meghatározni, hogy a devops ne vezessen menedzselhetetlen káoszhoz.

Ennek közvetlen folyománya a biztonság kérdése is. Éles rendszerhez tradicionális üzemeltetés esetén csak néhány kiválasztott fér hozzá, a fejlesztők pedig saját környezetben dolgoznak. A devops ezt felrúgja, hirtelen sokkal többen férnek hozzá az összes környezethez és rendszerekhez, amit szerepkörök meghatározásával, oktatással, tudatosítással kell kezelni.

Tipikus példa a desktop környezetek kérdése: az üzemeltetők erősen korlátozott, magas biztonságú munkaállomásaihoz képest a fejlesztők jóval gazdagabb szoftverkörnyezetet használnak, az IDE, a frameworkök, a hatékony munkavégzéshez elengedhetetlen tucatnyi alkalmazás biztonsági minősítése sokkal nehezebb, ezt a kérdést a devops bevezetésekor szintén kezelni kell.

További tapasztalat, hogy az egy-egy szolgáltatásra beállított devops-csapatok hajlamosak szem elől téveszteni az összképet és csak a rájuk bízott rendszerekkel foglalkozni, saját kis kertjüket ápolgatni. Márpedig az üzlet egész folyamatokban gondolkodik, amelyek sok, egymással integrált, egymást kiegészítő szolgáltatásból állnak, így az egyes csapatok között is meg kell tartani a kommunikációt és az end-to-end szemléletmódot, erre meg kell találni a helyet a szervezetben.

A devops bevezetése hajlamos megbontani a meglévő csoportdinamikát is. A különböző területeket összefogó és kontextusában látó vezető fejlesztő lesz automatikusan a munka középpontja, ahogy a "legokosabb embert" kezdik keresni a problémákkal a kollégák. Ez gyorsan a vezető fejlesztő túlterheléséhez vezet, miközben a munkafolyamatok megállnak. Ezt a helyzetet mindenképp kezelni kell és a feladatokat visszadelegálni a megfelelő szintre, másképp ez szűk keresztmetszete lesz a munkának.

A prioritások okos kezelése is komoly kihívás lehet. A devops üzemmódban ugyanis a sürgős és kritikus hibák elhárítása válik az egyetlen prioritássá, egy folyamatos tűzoltássá válik a munkavégzés, az összes környezetben egyszerre. Ez azzal jár, hogy a hatását hosszabb távon éreztető karbantartásokat a csapat elhanyagolja, erőforrás hiányában nem végzi el. Ez pedig idővel a rendszerek stabilitását ássa alá, megnő az alacsony prioritású backlog és a technical debt, elkezd a szolgáltatás minősége romlani. A megoldás: dedikálni kell néhány főt arra, hogy rendszeresen ezzel, csak a backlog takarításával foglalkozzon. Ehhez azonban nagy fegyelem kell, hogy egy komolyabb krízis esetén is hagyjuk őket végezni a saját dolgukat.

Végső soron be kell látni, hogy a szállítási gyorsaság, az új funkciók és a minőség között alapvető ellentét feszül: a stabil, megbízható rendszerek legnagyobb ellensége a változás (különösen a gyors változás), amely a stabilizált, összecsiszolt informatikát kikezdi. A legjobb fejlesztők és üzemeltetők is hibáznak néha, ezért érdemes a lehető legtöbb tevékenységet automatizálni. Ha a csapat összeül, megérti egymás szempontjait és elkészíti ezeket az eszköztárakat, akkor a legfontosabb hibaforrásokat ki tudja küszöbölni a változtatások során. Ebben rengeteget segít, hogy a devops csapatokban az üzemeltetési készségek mellett megjelennek a fejlesztők is, akik képesek ezeket az eszközöket csapatszinten létrehozni - ez korábban szinte teljesen hiányzott.

(A Magyar Telekom megbízásából készített anyag.)

Kategóriák: Informatika

FreeBSD 11.1-BETA3

2017, június 25 - 09:27

A FreeBSD projekt részéről Glen Barber bejelentette, hogy elérhető a FreeBSD 11.1 harmadik bétája tesztelésre. Telepítő képfájlok elérhetők az alábbi rendszerekhez:

  • 11.1-BETA1 amd64 GENERIC
  • 11.1-BETA1 i386 GENERIC
  • 11.1-BETA1 powerpc GENERIC
  • 11.1-BETA1 powerpc64 GENERIC64
  • 11.1-BETA1 sparc64 GENERIC
  • 11.1-BETA1 armv6 BANANAPI
  • 11.1-BETA1 armv6 BEAGLEBONE
  • 11.1-BETA1 armv6 CUBIEBOARD
  • 11.1-BETA1 armv6 CUBIEBOARD2
  • 11.1-BETA1 armv6 CUBOX-HUMMINGBOARD
  • 11.1-BETA1 armv6 GUMSTIX
  • 11.1-BETA1 armv6 RPI-B
  • 11.1-BETA1 armv6 RPI2
  • 11.1-BETA1 armv6 PANDABOARD
  • 11.1-BETA1 armv6 WANDBOARD
  • 11.1-BETA1 aarch64 GENERIC

Részletek a bejelentésben.

Kategóriák: Informatika

BSD Now 199. epizód - Read the source, KARL

2017, június 25 - 09:24

A BSD Now egy heti rendszerességgel megjelenő video podcast, amelynek célja a BSD operációs rendszerek népszerűsítése, illetve a már meglevő felhasználók friss BSD-s információkkal, hírekkel való ellátása. A BSD Now egyik műsorvezetője a PC-BSD alapító, vezető fejlesztő Kris Moore. Elérhető a BSD Now 199. epizódja, címe "Episode 199: Read the source, KARL".

Kategóriák: Informatika

Az ifupdown helyett a netplan az alapértelemezett az Artful-ban

2017, június 25 - 09:16

Mathieu Trudel-Lapierre nemrég bejelentette, hogy az "Artful Aardvark" (megjelenés után Ubuntu 17.10) disztribúcióban az ifupdown helyét alapértelmezetten a netplan vette át:

Idézet:
Since Friday, netplan is now the default in artful. It is now included in the minimal seed, and thus part of all installs by default (if you find it missing, it's a bug I encourage you to report and let me know). It's a direct replacement for ifupdown: I'm still working on making ifupdown properly disappear from default installs (you will still be able to install it if you really want to). [...] Netplan is a framework for configuring networks. [...] Netplan is intended to be the default configuration method for networking in 17.10.

Kategóriák: Informatika

32 TB-nyi belsős Windows 10 build, core forráskód szivárgott ki online

2017, június 25 - 08:53

Large parts of Windows 10 source code leak online, plus private debugging symbols (#infosec #cybersecurity) https://t.co/YlzCTQdAi2

— Jason Fossen (@JasonFossen) June 23, 2017

32TB of Windows 10 Internal Builds, Core Source Code Leak Online https://t.co/hc03DLfyTs

— Slashdot (@slashdot) June 24, 2017

A The Register cikke szerint az érzékeny adatok egy, a Microsoft céges rendszerébe március hónap körül történt behatolás során kerülhettek illetéktelenek kezébe. A cikk itt olvasható.

Kategóriák: Informatika

A nap képe: SICSO

2017, június 23 - 13:41

Gironial Notwerk Divece pic.twitter.com/OpG2bJhT4j

— Gabriele (@Gabry89) June 22, 2017

Kategóriák: Informatika

1 millió dollár váltságdíjat fizet ki egy dél-koreai hosting cég miután ransomware támadás érte

2017, június 21 - 22:06

A dél-koreai webhosting cég, a Nayana 1 millió dollár váltságdíjat fizet ki azután, hogy ransomware támadás miatt 153 linuxos szerverén tárolt adataihoz nem fér hozzá. A támadás során 3400 ügyfelének weboldala esett áldozatul. A hírek szerint a cég vastagon tehet arról, hogy így járt. Gépein 2008-ban fordított 2.6.24.2-es Linux kernel, Apache version 1.3.36 és PHP version 5.1.4 futott. Részletek itt.

Kategóriák: Informatika

Wannacry fertőzés miatt leállította egyik gyárát a Honda

2017, június 21 - 21:53

Az Ars Technica egyik cikke szerint a Honda leállította egyik japán gyárát, miután WannaCry-t talált a hálózatán. A Tokiótól északnyugatra található Sayama gyárat hétfőn állították le, azután, hogy vasárnap felfedezték a fertőzést. A Honda képviselői nem adtak magyarázatot arra, hogy hogyan lehetett náluk működő WannaCry 37 nappal azután, hogy a "vírust" leállító kill switch-et aktiválták. Az egyik lehetséges magyarázat az lehet, hogy a hálózatukból valamiért nem volt elérhető a kill switch domain.

Részletek itt.

Kategóriák: Informatika