Jak jsem potkal počítače 7

13.3. 13:35 | Přečteno: 813× | Historie | | poslední úprava: 13.3. 13:42

Jedno studium končí, další začíná. A objevují se taky nové možnosti, co dělat s počítači, hlavně pokud jsou v síti.

Další etapa

Na jaře 1992, myslím, že to bylo v půlce dubna, jsem udělal státnice, obhájil diplomku a tím se vlastně uzavřela jedna etapa mého života. Promoce pak byla v květnu nebo v červnu. Měli jsem ji dohromady se studenty informatiky, takže jsem se při ní potkal s Davidem. Dozvěděl jsem se, že pojede studovat do USA, tak jsem mu popřál hodně úspěchů a rozloučili jsme se. To bylo naposledy, co jsem ho viděl.

Vzhledem k tomu, že jsem studoval s dobrým prospěchem, dostal jsem nabídku pokračovat v postgraduálním studiu, tedy udělat si doktorát z matematiky. Byla to tehdy čerstvá novinka, myslím, že to začínalo o rok dřív a byla to náhrada tzv. kandidatury věd, za kterou se dával titul CSc. za jméno. V tomto typu studia nás pokračovalo několik, mezi nimi i Igráček, ale na jiném oboru než já. Na postgraduální studium byly nějaké přijímací zkoušky, ale jednalo se víceméně o formalitu. Součástí studia bylo i stipendium zhruba na úrovni nízkého platu, ale člověku zůstaly studentské výhody, jako například laciné jídlo v menze. Navíc mi odpadly starosti se sháněním zaměstnání. Takže jsem nabídku rád přijal a po mých nejdelších prázdninách v životě jsem pokračoval v další životné etapě, která se ale hodně podobala té předchozí.

Povinných přednášek jsem měl daleko méně než při předchozím studiu, ale objevila se nová povinnost – pomoc při výuce. Dostal jsem za úkol vést některá cvičení k přednáškám pro nižší ročníky, celkem 4 vyučovací hodiny. Když jsem přišel do hodiny poprvé, studenti si mysleli, že mají nového spolužáka a musím přiznat, že ze začátku jsem se v tom hodně plácal a docházelo k různým trapasům, když jsem se zasekl v rozpočítaném příkladě a nevěděl, jak dál.

Můj úvazek na práci na chemickém programu ve FORTRANu na jaře končil taky, ale protože program nebyl úplně funkční, dohodl jsem se s doc. Kočou, že během postgraduálního studia budu na programu ještě pracovat. Díky tomu jsem mohl pořád docházet pracovat na katedru informatiky na počítač s UNIXem. Na PC, které byly ve stejné učebně, se objevila hra Civilizace Sida Meiera, která právem může nést označení kultovní. Téměř vždy bylo vidět na několika terminálech typickou mapu oblasti s různými druhy povrchu na jednotlivých herních políčcích a s vybudovanými městy. Když bylo náhodou některé písíčko volné, taky jsem ji zkoušel. Dokázala člověka opravdu vtáhnout.

Výhodou docházení na počítač od AT&T s UNIXem byla možnost používat mail. Po nástupu na postgraduální studium jsem dostal mailovou adresu, kterou mám v podstatě dodnes, jediná změna byla v tom, že po rozpadu Československa se koncovka .cs změnila na .cz. Pro postgraduální studenty byla v přízemí matematické sekce na Janáčkově náměstí zřízena místnost, kde mohli pobývat. Bylo tam k dispozici i několik PC, na kterých bylo možné pracovat. Pokud se dobře pamatuji, pro práci s mailem jsme se hlásili programem telnet na nějaký UNIXový server na katedru informatiky nebo na ÚVT, kde měli pracovníci matematické sekce na Janáčkově náměstí zřízeny účty. To bylo ale možné používat i z počítače od AT&T, kde byl vždycky nějaký volný terminál.

Ne že bych potřeboval mailovat tak často jako v dnešní době, veškerá oficiální komunikace ještě probíhala papírovou cestou a taky nebylo moc s kým si mailovat. Jenže Igráček zjistil, že pomocí mailu je možné stahovat software. Několikrát jsem si objednal nějaký software z časopisu Bajt, kde se objevovaly nabídky zaslání různých zajímavých programů na disketě, většinou shareware nebo demoverze. Ale stalo se mi, že disketa byla špatně čitelná, takže když Igráček přišel s možností použít pro stahování mail, tak jsem byl nadšený.

Dal se k tomu používat Listserv. Ten je primárně určen pro diskusní skupiny a taky jsem se přes něj do několika skupin zapojil. Časem jsem ale přešel na newsgroup, kteroužto službu začal poskytovat i univerzitní server. Jak jsem při psaní tohoto textu zjistil, i mnohé servery které nabízejí službu Listserv, přešly v podstatě na princip, na kterém funguje newsgroup: přihlásíte se na server, který nabízí diskusi o tématu, jež vás zajímá, případně založíte s přáteli vlastní skupinu, a příspěvky můžete dostávat mailem nebo jen číst s pomocí nějakého klienta, v dnešní době jsou jím zpravidla webové prohlížeče.

Původně ovšem Listserv fungoval jinak a je možné to ještě částečně vyzkoušet. Veškerá komunikace probíhá mailem. Můžete začít tím, že pošlete mail bez předmětu s textem zprávy „help“ na adresu listserv@listserv.net. Během několika sekund dostanete odpověď:

> help

LISTSERV(R) version 17.0 - most commonly used commands

INFO      <topic|listname>       Order documentation (plain text files)
SUBscribe listname <full name>   Subscribe to a~list
SIGNOFF   listname               Sign off from a~list
SIGNOFF   * (NETWIDE             - from all lists on all servers
Query     listname               Query your subscription options
Search    listname  keyword...   Search list archives
SET       listname  options      Update your subscription options
INDex     <listname>             Order a~list of LISTSERV files
GET       filename filetype      Order a~file from LISTSERV

There are more commands; send an INFO REFCARD command for a~comprehensive
reference card, or just INFO for a~list of available documentation files.

If you  prefer, you  can use  LISTSERV through  its web  interface at
http://listserv.net/scripts/wa-LNET.exe (the full manuals can also be
browsed online at this URL).

This server is managed by:
 pm_admin@pop.lsoft.com

Na konci zprávy jsou ještě informace o využití zdrojů při zpracování dotazu, které neuvádím. Poslání příkazu „info“, který je uveden jako první v odpovědi, vyvolá odpověď

> info

List of information files available from LISTSERV@LISTSERV.NET:

REFcard    (LISTSERV REFCARD)   Command reference card
FAQ        (LISTFAQ  MEMO   )   Frequently Asked Questions
QUICKstart (LISTQS   MEMO   )   Quick start for list owners
GENintro   (LISTSERV MEMO   )   General information about LISTSERV
KEYwords   (LISTKEYW MEMO   )   Description of list header keywords
AFD        (LISTAFD  MEMO   )   Description of Automatic File Distribution
FILEs      (LISTFILE MEMO   )   Description of the file-server functions
LPunch     (LISTLPUN MEMO   )   Description of the LISTSERV-Punch format
JOB        (LISTJOB  MEMO   )   Description of the Command Jobs feature
DISTribute (LISTDIST MEMO   )   Description of DISTRIBUTE
FILEOwner  (LISTFOWN MEMO   )   Information guide for file owners
DATABASE   (LISTDB   MEMO   )   Description of the database functions
OWNers     (LISTOWNR MEMO   )   Description of list-owners commands
PUT        (LSVPUT   EXEC   )   An exec to facilitate sending PUT commands

You should order the PResentation or GENintro guides if you are new to
LISTSERV.

Pokud podle rady na konci zkusíte objednat GENintro posláním „info gen“, obdržíte LISTSERV(R) general user’s guide, release 1.8c z roku 1996, „info file“ vrátí dokumentaci skoro ještě o 10 let starší. Ale „info FAQ“ končí chybovým hlášením, i když myslím, že tehdy to byla nejrychlejší cesta, jak získat další potřebné informace:

> info FAQ
This server does not have any file by the name "LISTFAQ MEMO".

Je taky možné získat získat adresy serverů, které se věnují nějakému tématu. Pakliže se třeba zajímáte o šachy, můžete poslat dotaz „list global chess“ a vrátí se vám seznam 7 serverů nebo mailových skupin, které mají v názvu „chess“.

Igráček zjistil, že na některých serverech je dostupný volně šířený software, nejen pro PC, ale jiný nás v té době nezajímal. Dnes už si nejsem jistý, jestli bylo nutné se přihlásit do nějaké diskusní skupiny, v každém případě ale šlo příkazem get onen software získat.

Trochu složité ovšem tehdy bylo software z mailu dostat. Standard MIME, který se dnes mimo jiné používá pro přenášení binárních dat elektronickou poštou, byl teprve někde ve svých počátcích a Listserv pro vkládání binárních souborů, at’ to byl jeden spustitelný program nebo více souborů zkomprimovaných do jednoho archivu, používal postup zvaný uuencoding. Nejprve se na straně odesílatele použil program uuencode, který data převáděl do zobrazitelného ASCII kódu. Princip převodu spočíval v tom, že každé 3 bajty se rozsekaly na 4 skupiny po 6 bitech, ke kterým se přičetlo číslo 32, a tím se získal ASCII kódy mezi 32 a 95. Takto získaný „text“ se vložil do zprávy. Byl samozřejmě člověkem nečitelný, to ale při posílání pošty nevadilo. Zpětný postup zajišťoval program uudecode, který musel použít příjemce zprávy. Patrně už tehdy existoval nějaký mailový klient, kteří vše dělal automaticky, tenkrát mě ale ani nenapadlo něco takového hledat a tuto činnost jsem provozoval sám. Šlo o to uložit text mailu do souboru, odmazat vše kromě kódu uvozeného hlavičkou (řádek začínající slovem begin, pak byl číselný mód pro přístupová práva k souboru, nejčastěji 644, následovaný jménem souboru) a ukončeného řádkem se slovem end. Na výsledek se pak pustil program uudecode. Celé se to ještě komplikovalo tím, že maximální velikost zprávy byla tehdy 64KB, takže větší soubory přicházely rozsekané do více zpráv. Bylo potřeba ze všech odstranit nepotřebný balast, pak je spojit do jednoho souboru a výsledek prohnat programem uudecode. Naštěstí byl Igráček UNIXem a možnostmi, jež poskytoval, přímo nadšený, takže napsal program pro automatizaci spojování souborů do jednoho nazvaný m2f (zkratka mail2file). Uvádím ho tak, jak mi jej poskytl, včetně odpoznámkovaných pokusů s programem nawk:

#nawk ’/^begin/ {print ; exit}
# /^table$/,/^begin/’ $1
#tab=‘nawk -f /home/vradek/bin/m2f.nawk $1‘
#nawk ’/^begin/,/^end/’  $1 | /usr/bin/tr -cs $tab ’\040’| \
# /usr/bin/nawk -F ’\040’ ’NF == 1 && length > 0’
#echo end

for i~in $*
do
(echo ":g/^From /.,/^$/d"; echo ":g/^$/d"; echo ":g/\001/d";echo ":x") | vi $i  >/dev/null
done

Stačilo uložit potřebné zprávy do souborů v nějakém adresáři, pustit uvedený program a nakonec použít uudecode.

Pak se objevil protokol FTP, přesněji řečeno Igráček někde zjistil, že něco takového existuje a taky našel spoustu serverů, na které bylo možné se hlásit a stahovat software.

Zdá se, že v dnešní době už je význam tohoto protokolu za zenitem. Podle toho, co jsem zjistil, tak už jej od roku 2021 nepodporují webové prohlížeče. Přenos souborů pomocí FTP protokolu umí některé správce souborů, třeba Midnight Commander nebo Total Commander. V průběhu let jsem pracoval s několika kvalitními klienty, na začátku jsem ale vše dělal v příkazovém řádku.

Asi je zbytečné popisovat jednotlivé příkazy, byly stejné či velmi podobné jako ty, které bylo možno použit v DOSu. Jelikož stahování občas trvalo dlouho, napsal jsem si jednoduchý skript nazvaný tahac, který jsem v případě potřeby spustil na pozadí, a pro stažený soubor jsem mohl přijít další den:

(echo user ftp jmeno@adresa.muni.cz
echo cd $2
echo hash
echo bin
echo mget $3
echo bye)| ftp -vin $1

Program měl tři parametry, které jsem musel zjistit předem: adresu stroje, kam jsem se hlásil, adresář, kde se software nacházel, a soubor, který jsem stahoval. Využíval jsem taky toho, že bylo běžné používat anonymní režim s přihlašovacím jménem anonymous nebo ftp a e-mailovou adresou místo hesla. Časem se vykrystalizovaly dva nejčastěji navštěvované servery, které sídlily v severských zemích: ftp.funet.fi a ftp.sunet.se. Oba existují dodnes a na prvním z nich je dosud možné najít velkou spoustu softwaru z oné doby – například EmTeX z roku 1993.

       

Komentáře

[zito]

Hezké! Jo, ty začátky s ftp se mi teď také vybavují. Pamatuji si, že byl default ascii přenos a občas někdo zapomněl přepnout na bin. Když byl velký soubor, tak se vyplatilo zkusit data opravit. Tenkrát asi neuměl klient a server udělat reget, že? Občas to padlo a muselo se začít znovu. Pomocí prompt nebo set prompt to pak ukazovalo asi hashmark? Každý kilobajt byl hashmark. Člověk na to civěl, jak pomalu naskakují hashmarky, a doufal, že to nepadne...

[zito]

Ne prompt, tak to byl asi ten hash, když koukám na ten skriptík...

[PetebLazar]

Spolužák z fakulty si takto plnil diskety celý týden programy pro Amigu v .lha, aby doma o víkendu zjistil že si stáhl z každého byte pouze sedm bitů.

[podlesh]

sunset měl tuším miror na cuni.cz ale možná to byl sunsite?

[PetebLazar]

Co si vzpomínám tak sunsite.

[Vtipnéř]

Určitě sunsite, což souvisí s firmou Sun, ale sunet je něco jiného.

[podlesh]

Jo a ftp se překvapivě v některých oblastech drží. No ale nebudu si stěžovat, furt lepší než fax!

[Max]

U nás stále používáme. Snažíme se klienty donutit postupně používat sftp.
Jede se přes to částečně komunikace edi zpráv. Na edi je mimochodem oftp, které jsme byli nuceni před delší dobou nasazovat kvůli Škodě. Do té doby jsem ani netušil, že něco takového existuje.
Zdar Max

[luky]

Tak u prumyslovych aplikaci je normalni, ze zarizeni maji zivotnost 20 let i vice, takze FTP s nama nejakou dobu jeste bude. Navic v techto pripadech se vetsinou i pouziva na lokalnich sitich, takze neni treba resit pruchod pres FW a sifrovani.

[Max]

Šifrování je třeba řešit vždy, i na lokální síti.
Zdar Max

[__]

Tohle lpění na šifrování vždy a za všech okolností mi přijde, jako kdybych si pod dům Řípem chtěl pojistit proti výbuchu sopky.

[__]

... si dům pod Řípem ...

pardon

[Max]

Šifrování je naprostý základ už hafec let. Nechápu, že se tomu stále někdo brání. Odchytit ftp komunikaci, získat loginy, znepříjemnit život adminům i klientům, to není tak těžké.
Navíc spousta lidí nedomýšlí další možné komunikace, co nejsou šifrované a neuvědomují si, co tam lítá a jaký je to průšvih.
Zdar Max

[__]

Já ale neříkám, že by se to nemělo dělat. Jen to, že je potřeba zvážit co, proti čemu, v jaké situaci a podobně, chráním. Ano máš pravdu, že na obecné úrovni nelze říct, že v lokální síti je to bez šifrování OK. Ale zcela obdobně mi přijde přehnané tvrdit, že šifrování je naprostý základ. Jsou jednoduše situace, kdy komplikace související s jeho nasazením převažují výhody.

Obdobně jsou situace, kdy třeba prázdné heslo roota je naprosto v pořádku. Nebo by se taky měli zamyslet všichni propagátoři kombinatorické složitosti hesel proč u platební karty je dostačující čtyřciferný pin.

[Max]

Čtyřciferný pin je u karty dostatečný proto, jelikož to samotné řešení umožňuje mít takto krátké a zároveň bezpečné. To samé heslo do TPM. U karty je ta bezpečnost dána tím, že karta musí být fyzicky odcizena + útočník má omezený počet pokusů. V kombinaci s možností nahlášení ztráty, nastavenými limity apod. je to dostatečně bezpečné.
TPM je opět o nutnosti fyzické přítomnosti a nemožnosti dělat bruteforce (pokud je dobře nastaveno).
Zdar Max

[PetebLazar]

Není pravdou, že potenciální útok je omezen pouze na odcizenou kartu. Většina čteček(ISO karty) a tokenů dnes není vybavena klávesnicí, takže PIN k ní se zadává skrze prostředky počítače. V případě, že má útočník vzdálený přístup k počítači s možností zachycení obrazovky(myši) nepomůže ani typická zobrazená scramblovaná klávesnice k zadání PINu.

[Max]

Kopírovači karet jsou zlo, to je pravda. Naštěstí to postupně také začíná ustupovat. Čím dál více poskytovatelů umožňuje platby přes QR kód a používání bankomatů je taktéž na ústupu, tj. nejčastější místo, kde ke kopírování docházelo.
Zdar Max

[PetebLazar]

Nešlo mi o případ zkopírování karty, ale o její zneužití bez vědomí držitele přímo na jeho prostředcích. Po popsaném odchycení PINu možnost přímého zneužití originální karty(tokenu) bez vědomí držitele.

Je to také jedna z historií: od hesel pro telefonni komunikaci, přes papírové seznamy jednorázových hesel autorizující transakce, PINy, time-sync SecurID tokeny, SMS, certifikáty, mobilní klíče. Nakolik v tom posledním případě jde stále o více-faktorovou autorizaci když je i s mobilním bankovnictvím realizována na jediném technickém prostředku (SF)?

[vencour]

Vždyť nemusíte používat jen jeden mobil?

[__]

Já na to nechtěl odpověď :) , to bylo otázka k zamyšlení ohledně tématu bezpečnosti a jestli jsou všechna doporučení opravdu univerzálně platná, nebo je dobré si uvědomit kontext. U toho nešifrovaného ftp by to klidně mohlo být něco ve stylu, když už je útočník ve vnitřní síti, je to tak velký průšvih, že nějaká manipulace nebo jen odposlouchávání ftp je nám jedno.

[Vtipnéř]

Já na to nechtěl odpověď :)

Když mezitím proběhne nějaká diskuse, špatně se hledá, na co vlastně reaguješ. Pomůže, když se tam dá citace.

[Max]

Pokud je útočník ve vnitřní síti, není jedno nic. A z podobných důvodů se musí šifrovat i veškerá komunikace ve vnitřní síti. Tj. komunikace server-server, client-server apod. Reálně to pro firemní prostředí znamená např. vynucování šifrování a podepisování veškeré smb komunikace, šifrovat všechnu webovou komunikaci, ftp, vynucovat šifrování v komunikaci s databázema apod. a i pro čistě lokální app, které jsou dostupné třeba i jen pro IT, tak vynucovat MFA.
Zdar Max

[__]

To je ale přesně ten typ nesprávně universální úvahy, o které píšu. O jaké vnitřní sítí je vlastně řeč? Je opravdu nutné šifrovat třeba přenos mezi teplotním čidlem na balkoně a routrem, který ty údaje cpe do nějké rrd databáze (to asi nebude ftp, ale taková nešifrovaná komunikace bude mít velmi podobné problémy)?

Myslím, že v takovém případě je mi fakt jedno, že útočník, který má přístup do vnitřní sítě může navíc zjistit, jaká je teplota na balkoně a nebo mi dokonce podstrčit nějaká falešná data.

Lpět na šifrování vždy všude mi přijde podobné jako požadovat k platební kartě 12-ti znakové heslo s velkými, malými písmeny, čísly, speciálními znaky a tak.BTW - ani to nic moc nezajistí - qqqQQQ111!!!

[vencour]

Ideální svět je asi jiný než reálný. Vše dlouhodobě udržovat, řešit TCO, to je jiná.

[Max]

Pokud se bavíme o sensorech apod. věcech, tak jejich úroveň zabezpečení záleží na rozhodnutí na základě risk managementu. Třeba my provozujeme nemalou síť kamer a tam je jediný způsob ochrany izolovanost veškeré komunikace, managementu apod.
Zdar Max

[__]

To byl jen příklad. Z mého pohledu jde o: ... je potřeba zvážit co, proti čemu, v jaké situaci a podobně, chráním. a podle toho se rozhodnout, jaký způsob ochrany je vhodný a třeba jestli je nutné šifrovat

vs.

Šifrování je naprostý základ ...

[ehmmm]

A co kdyz ten ftp server akceptuje jakehokoliv anonymouse? Opravdu je potreba i takove ftp sifrovat?

Uz nevim presne, jak to bylo, ale byly nejake vstrikolisy a ty umely nejaky protokol, ktery prave spocival v predavani souboru pres ftp. Rozhodne se ty lisy nechystal nikdo vymenovat. Bylo definovano, jak se maji soubory jmenovat, co do kterho musim zapsat a co potom ten lis na oplatku vygeneruje za soubor. Uz jsem to nasel, jmenuje se to euromap: https://www.euromap.org/media/recommendations/63/2000/eu63.pdf Jen si nejsem jisty tim cislem 63, ale vypada to povedome.

[Max]

Řešil jsem něco podobného u soustruhů, které měly vystavené vnc bez zabezpečení. Některé starší stroje jej měly jen pro čtení, některé novější i pro ovládání soustruhu. Komunikace s dodavatelem prý velmi špatná. Nakonec kompletně izolovaná síť za fw s přístupem jen na přenos souborů tak, aby bylo riziko minimalizováno co nejvíce. Přenos dat nutný, posílaly se nějaké protokoly apod.
Zdar Max

[vencour]

Noo dlouho jsem někde neviděl citovat X.25

[Max]

Pěkné okénko do historie :).
Zdar Max

[regine2]

V uvedeném období jsme užívali ke komunikaci i modemy, hlavně pro přenos většího balíku dat v noci. U Telekomu jsme měli předplacený vyhrazený čas. Přesto si operátorky chtěly občas pokecat s modemy: "Hovoříte ještě?". No, krásná doba. Nakonfigurovat modem bez podpory výrobce bylo téměř nadlidské. Telekom navíc chtěl mít modemy jím schválené, vnucoval nám jejich předražené snad 10x. My měli od nějaké kanadské firmy. Doba monopolu Telekom.