Titkosítás, DES, AES, Blowfish, MD4, MD5, SHA-2, RSA, DSA, RC4, TKIP, WEP, WPA, WPA2, TLS, SSL, PGP, SSH

Igen sok rövidítés került a címbe. Ezek egy része algoritmus, más része hash függvény vagy protokoll. A teljesség igénye nélkül vegyük sorra őket, hiszen ezekkel találkozhatunk a mindennapi életben.

A DES (Data Encryption Standard) illetve a Triple DES és az AES (Advanced Encryption Standard) ún. szimmetrikus kulcsú vagy “titkos kulcsú” algoritmusok. Ez azt jelenti, hogy minden félnek ismernie kell a kulcsot, mind a titkosításhoz, mind a dekódoláshoz. Ez a fő hibájuk egyébként. A DES már történelem. Több mint 20 éve feltörték. 🙂 Az AES algoritmus a WPA2-ben (Wi-Fi Protected Access) használatos, még ma is biztonságosan működik. A Blowfish pedig az egyik első biztonságos blokk-kódoló – szimmetrikus – algoritmus. Ma már az AES népszerűbb.

https://en.wikipedia.org/wiki/Symmetric-key_algorithm

https://en.m.wikipedia.org/wiki/Blowfish_(cipher)

Vannak az előzőekkel szemben az ún aszimmetrikus kulcsú vagyis nyilvános kulcsú titkosító algoritmusok. Ez a korszerű és a biztonságos(abb) egyébként. Itt kulcspárt generálunk, és a fogadó fél a privát kulcsommal kódolt üzenetemet a rendelkezésére bocsájtott nyilvános kulcsommal tudja elolvasni, és vica versa. Ilyen megoldások az RSA (Rivest–Shamir–Adleman) és a DSA (Digital Signature Algorithm) algoritmusok. Az RSA széles körben elterjedt titkosított adatátvitelhez.

https://en.wikipedia.org/wiki/Public-key_cryptography

https://en.wikipedia.org/wiki/RSA_(cryptosystem)

https://en.wikipedia.org/wiki/Digital_Signature_Algorithm

Aztán nézzük meg az MD4-et illetve az MD5-öt (Message-Digest algorithm 5). Ezek egyirányú kódoló algoritmusok. Mára elavultak, ezért az SHA-2 (Secure Hash Algorithm 2) váltotta ki őket. Linux alatt a jelszók kódolására használják ezt a fajta titkosítást. Csak azt lehet ellenőrizni, hogy a két kódolt karaktersorozat egyezik-e, ezért nem lehet egy elfelejtett jelszót “megmondani”. 🙂 A bitcoin kriptovaluta pl. a SHA-2 családba tartozó SHA-256 kriptografikus hash függvényt használja többek között blokk-láncai kódolásához is. A hash függvény matematikai fogalom, egy értékkészletet képez le egy szignifikánsan (jelentősen) kisebb értéktartományra.

https://hu.wikipedia.org/wiki/MD5

https://en.wikipedia.org/wiki/SHA-2

És akkor még itt van az RC4 (Rivest Cipher 4). Ez folyam kódoló, de sajnos olyan törhető titkosításokhoz használták, mint a WEP (Wired Equivalent Privacy). Ezt ma már nem használjuk még véletlenül sem. Volt még ilyen gyermekbetegség-kódolás, a TKIP (Temporal Key Integrity Protocol). Azt sem fejlesztették tovább. 🙂

https://en.wikipedia.org/wiki/RC4

https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy

https://hu.wikipedia.org/wiki/TKIP

Ma nyilvános kulcsú algoritmusból legalább 2048 bites RSA kulcsokat, szimmetrikusból AES-t, illetve egyirányúból SHA-2-t használunk. 🙂

RSA titkosítást használunk a TLS (Transport Layer Security), SSL (Secure Sockets Layer) és SSH (Secure Shell) protokollokban, illetve PGP (Pretty Good Privacy) folyamán.

https://hu.wikipedia.org/wiki/PGP

A TSL-t az a bizonyos “https://” kezdetű rész használja a böngészőnkben a weszerverrel való kommunikációban – fontos eleme a “kézfogás” (handshaking) -, a PGP pedig egy titkos levelezésnél hasznos. 🙂

https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

Egy informatikai biztonsággal foglalkozó kollégám mondta egyszer nekem, hogy informatikai biztonság nem létezik. Csak a vasbeton trezorban a konnektorból is kihúzott számítógép, fegyveres őrrel az ajtóban. És valóban. Mit ér mindez, ha a felhasználó hibájából van a notebook-ban egy cetli a jelszóval. 🙂

Linux parancsok IV.

Sort kell kerítsek még néhány parancs bemutatására. Nézzük sorban. Ha belépünk egy Linux szerverre, hasznos lehet az uname parancs.

gvamosi@gergo1:~$ uname -a
Linux gergo1 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux

A parancs kimenetéből egyből megtudhatjuk, hogy az operációs rendszer Linux, Debian Linux, a hoszt neve gergo1, a kernelünk (leírása később) 4.19-es, a rendszerünk x86 alapú és 64 bites, és egy dátumot is láthatunk az oprendszer kibocsátásával kapcsolatban. 🙂

Fontos parancs lehet még a hostname parancs is, hasonlóan sokmindent kideríthetünk az adott hosztról.

gvamosi@gergo1:~$ hostname
gergo1
gvamosi@gergo1:~$ hostname -I
192.168.0.109

Ebből a parancsból megtudjuk a szerver IP-címét. Nem beszéltem még részletesebben a hálózat egyik alapvető protokolljáról, az ICMP-ről (Internet Control Message Protocol). A hálózat diagnosztikájában segítségünkre lehet a ping parancs. Ez egy ICMP üzenet, datagramm jellegű, ahogy az UDP, és válaszüzenete a pong. Milyen meglepő. 🙂

https://hu.wikipedia.org/wiki/ICMP

Nézzünk egy példát a parancs kimenetére, melyben “megpingetjük” a BME névszerverét.

gvamosi@gergo1:~$ ping nic.bme.hu
PING nic.bme.hu (152.66.115.1) 56(84) bytes of data.
64 bytes from nic.bme.hu (152.66.115.1): icmp_seq=1 ttl=55 time=23.5 ms
64 bytes from nic.bme.hu (152.66.115.1): icmp_seq=2 ttl=55 time=22.9 ms
64 bytes from nic.bme.hu (152.66.115.1): icmp_seq=3 ttl=55 time=32.0 ms
^C
— nic.bme.hu ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 22.899/26.133/32.006/4.161 ms

Látható, hogy feloldja az IP-címet, aztán hogy ctrl+c-vel “lépünk ki” belőle, illetve egy rövid kis statisztika. A 0% csomagveszteség a jó, és ezek a milliszekundomok jó válaszidőnek számítanak. A hálózat megfelelően gyors. 🙂

Van még egy parancs, amiről szólni szeretnék, ez a mount. Ezzel a paranccsal lehetett eredetileg egy CD-t vagy DVD-t a Linux filerendszer részévé tenni, “felcsatolni” a /mnt könyvtár alá. De így lehet pl. a teljes filerendszert újracsatolni, pl. read-only (csak olvasható) módban, vagy akár egy hálózati kötetet csatolni, pl. NFS-en (Network File System) keresztül. A külső médiák behelyezésénél ma már automatikusan működik mindez. Ha pl. egy USB stick-et, egy “pendrive“-ot csatlakoztatok a laptopomhoz, akkor azt a rendszer felismeri. 🙂 De nézzük meg a mount parancs kimenetét paraméterek nélkül. Elég cifra!

gvamosi@gergo1:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=3965840k,nr_inodes=991460,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=797444k,mode=755)
/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,relatime)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=44,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12776)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=797440k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)

Ebben nagyon sok minden van. Látható a “lényeg” is, a root filerendszer: /dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro). Itt az áll, hogy a filerendszer ext4 típusú, és rw – írható módon van csatolva. 🙂

Egyébként az fstab – a /etc könyvtárban – tartalmazza a filerendszer mount-jait (root, swap, etc.)

gvamosi@gergo1:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use ‘blkid’ to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda2 during installation
UUID=cab2004d-b7b8-4ba2-9831-cc1a987e2ba2 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=B5A5-032A /boot/efi vfat umask=0077 0 1
# swap was on /dev/sda3 during installation
UUID=83144245-6f61-477a-97a3-9f55ca34c3fc none swap sw 0 0

És akkor a mai írásom végére egy apró nüansz. Amikor a konzolon bejelentkezik egy felhasználó, vagy akár SSH-n keresztül, kap egy rövid üzenetet. Ez nem máshol van, mint a /etc/motd file-ban. Ide bármit írhatunk, még ún. vezérlő karaktereket is, ha valami színest vagy fényeset szeretnénk. 🙂

gvamosi@gergo1:~$ cat /etc/motd
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Mentés (backup)

A mentés a nagyon fontos gyakorlati rendszergazdai teendő. Az informatika egyik alaptétele a következő: ha egy adat csak egy helyen van meg, az nincsen (!).

Ezért fontos mentési stratégiát kialakítani egy szerver, de akár a desktop gépünk, illetve hordozható eszközünk esetében is! Tiszteljük meg annyira saját magunkat, hogy saját munkáinkat, adatainkat, leveleinket, kapcsolatainkat, etc. legalább lementjük egy fizikailag különböző helyre időközönként! Erre szolgál egyébként a felhő is. Azonban nem minden esetben kifizetődő a használata! Egyébként pl. az ownCloud felhőt mi is telepíthetjük. Lehet saját felhőnk is!

https://owncloud.org/

Nézzük azonban a klasszikus backup-ot, mondjuk egy kódolt hálózatit.

A szeptember 16-ai írásomban az SSH-ról leírtam a publikus kulccsal hitelesített jelszó nélküli kapcsolatot. Ez tökéletes alap egy hálózati mentéshez. Hirtelen két stratégia is eszembe jut.

  1. A távoli szerveren fut egy ún. cron job, a felhasználói crontab-ban – ez egy ütemezett feladatot jelent – mondjuk naponta. Egy script. ami ún. .tar.gz vagy .tgz tömörített állományt (archívumot) hoz létre – ez a Linux/UNIX rendszerek saját ZIP megoldása – a menteni kívánt könyvtárból, természetesen rekurzívan. Futhat pl. hajnai 3-kor. Hajnali fél négykor pedig a helyi gépünkön, ahova mentünk, lefut egy másik script, ami scp-vel, jelszó nélküli átvitelben átmásolja, “letölti” a tömörített állományt. 🙂
  2. A második megoldásban az “ssh” parancs segítségével a távoli gépen – amiről a mentést készítjük – egy scriptet futtatunk, amiben tömörítjük a menteni kívánt könyvtárat a “tar czvf <archívum_időbélyeg.tgz> <könyvtár>” paranccsal vagy a tar és a gzip parancsok kombinációjával (tar cvo <könyvtár> | gzip – > <archívum_időbélyeg.tar.gz>), ezt követően pedig scp-vel átmásoljuk a helyi gépünkre. Ezt elég lesz helyileg ütemeznünk, de akár kézzel is indíthatjuk. 🙂

https://www.shellhacks.com/ssh-execute-remote-command-script-linux/

Látható, hogy nem ördöngősség a mentés. Jóllehet azért nagyon nagy mennyiségű adat mentésénél már több eszközre van szükségünk, mint egy-két Linux parancs. 🙂

Meg kell említsem még a bzip2-t, mint egy újabb, és hatékonyabb tömörítő algoritmust használó tömörítő programcsomagot (https://www.sourceware.org/bzip2/). Általában igaz, hogy a tar archivál, a gzip és a bzip2 pedig tömörítenek. Ma már a bzip2 is alapból telepítve van egy Linux-on, sőt tar-ból is elérhető a “-j, –bzip2” kapcsolóval. Az alábbi linken található még néhány hasznos információ az archiválásról.

https://www.thomas-krenn.com/en/wiki/Archive_under_Linux_(tar,_gz,_bz2,_zip)

Tűzfal (firewall)

A Linux gépeken már régi téma a tűzfal. A tűzfal arra való, hogy védelmet nyújtson a magánhálózatoknak illetve a számítógépeknek az Interneten garázdálkodó rosszakaratú támadók ellen. Éppen ezért beszélhetünk hálózat-biztonságról – erről nálam itthon a router-en lévő tűzfal gondoskodik -, illetve hoszt-biztonságról, ami a Linux notebookom-on van telepítve. Ma már általában egyszerűek a beállítások, mind hálózati, mind hoszt szinten. Debian 10 alatt már automatikus az alap tűzfal-konfiguráció.

Régebben az ipchains volt, ma már az ún. iptables van használatban. Nézzük meg a Linux-unkat!

root@gergo1:~# iptables -L -v
Chain INPUT (policy DROP 590 packets, 93015 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
256 20230 ACCEPT all -- lo any anywhere anywhere
6008 2038K ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:netbios-ns
0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:netbios-dgm
0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:netbios-ssn
0 0 ACCEPT tcp -- any any 192.168.0.0/24 anywhere state NEW tcp dpt:microsoft-ds
0 0 ACCEPT icmp -- any any anywhere anywhere icmp echo-request
6 336 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 6272 packets, 1041K bytes)
pkts bytes target prot opt in out source destination
256 20230 ACCEPT all -- any lo anywhere anywhere

Látható, hogy a bemeneten (INPUT) az SSH szerver, a Samba szerver (Microsoft hálózathoz) és a HTTP szerver van engedélyezve + az ICMP ping (leírása később), továbbá természetesen a már létrejött kapcsolatok is. Forward szinten semmi sincs “átengedve”. Nem továbbítunk adatot hálózatok között. Kimeneten (OUTPUT) pedig mindent “kiengedünk”.

Hogy hol van beállítva? Van egy pici konfigurációs file a /etc alatt.

root@gergo1:~# cat /etc/network/iptables.up.rules
# Generated by iptables-save v1.6.0 on Sat Aug 26 03:40:19 2017
*filter
:INPUT DROP [9:1026]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [22:3482]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
#
# added by gvamosi on 2019-06-07
#
-A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT
-A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT
-A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT
-A INPUT -s 192.168.0.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
#
# added by gvamosi on 2019-09-22
#
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
#
COMMIT
# Completed on Sat Aug 26 03:40:19 2017

És hogyan “töltődik be”? Az ún. init script-ek között kell keresnünk a választ (leírásuk később).

root@gergo1:~# cat /etc/init.d/iptables
#!/bin/sh
echo -n "Applying firewall rules.."
/sbin/iptables-restore < /etc/network/iptables.up.rules
echo "done."

Ez a kicsi init script tölti be a rendszer elindulásakor a tűzfal konfigurációját az iptables-restore parancs segítségével. Ennyi az egész. 🙂

Írhatnánk még az ún. DMZ (Demilitarizált Zóna) fogalmáról is. Ez egy olyan terület egy cégnél pl., ahonnan szerverek “kifelé”, a nagyvilágba, azaz az Internet felé is látszódhatnak. Határzóna a belső, védett, és a külső, védtelen hálózat között.

Ethernet, bridging, switching, routing és a Linux router táblája

Először beszélnünk kell arról, hogy mi az az Ethernet. Az Ethernet a LAN (Local Area Network – helyi hálózat) hálózatokra kidolgozott szabvány. Működésének lényege, hogy hallgatózik az összes résztvevő, és ha “csend” van, akkor küldik az adatokat. Beszélünk ma 100 MBit-es (megabit per másodperc) Ethernetről és GBit-es (gigabit per másodperc) Ethernetről is. Ez az elméleti átviteli maximum, tipikusan a 66%-át lehet elérni rajta. 🙂

https://hu.wikipedia.org/wiki/Ethernet

Ez az a hálózat, ami otthonunkban, munkahelyünkön vagy akár egy kórházban használatos. Van az ún. CAT5-ös kábel, ez a 100 MBit/s -os átvitelhez szükséges UTP (Unshielded Twisted Pair – árnyékolatlan csavart érpár) kábel. Azért csavart – és ez már fizika a javából -, mert így kiegyenlítődnek rajta a zajok. Azért 230-as kábeltől a falban legalább 30-40 centiméterre illik vezetni, tipikusan kábelcsatornában. Plusz feladat, hogy mi az a patch- és a keresztkábel. 🙂

https://hu.wikipedia.org/wiki/UTP

Aztán a hálózati rétegek az ISO-OSI modellből. A 2-es, adatkapcsolati rétegen dolgozik a bridge és a switch is (ha nem layer 3 switch). A router pedig a hármas, hálózati rétegben. A bridge-ek hálózati szegmenseket kötnek össze, MAC-táblát tartanak nyilván. Hasonlóak a repeater-ekhez, bár ez utóbbiak csak jelismétlők (erősítők), és nagyobb távolágok áthidalására használják őket. Az UTP ugyanis 100-120 métert tud csak! A switch-ek több portos bridge-eknek tekinthetőek. 🙂

https://hu.wikipedia.org/wiki/Switch_(informatika)

Linux-unkkal akár bridge-elhetünk, akár switch-elhetünk, sőt még route-olhatunk is! Csak megfelelő interfészeket kell a “dobozba” tenni. A gyakorlatban egyébként ez is történik, csak kész eszközöket használunk, amik azért kisebbek egy PC-nél, és kevesebbet is fogyasztanak. Belsejükben Linux dolgozik. 🙂

Az én itthoni hálózatomban egy kábelmodemből egy router-be érkezik a jel. A router GigaBit-es Ethernet interfészekkel, két sávú WLAN-nal (vezeték nélküli hálózat) rendelkezik. Az egyik helységben van egy switch is, ami elosztóként működik, akár egy 230 V-os elosztó. 🙂 Van még egy konnektorba dugható picike Wi-Fi lefedettség növelőm, az emeletre – és nagyjából ennyi. Asztali gépek, hordozható számítógépek, tabletek, okostelefonok és az aktív és passzív hálózati eszközök (kábelek). 🙂

Összességben elmondható, hogy a Layer 2-es eszközök fizikai, Ethernet MAC-cím (Media Access Control) alapján végzik az összekapcsolást, a router-ek pedig IP-címeket adnak, tipikusan DHCP-vel (Dynamic Host Configuration Protocol), azaz automatikusan kiosztanak minden hálózati résztvevőnek egy (helyi) IP-címet, továbbá a Layer 3-ban “operálnak”. Ha megnézzük a tegnapi írást a hálózatról és az IP-címről, akkor volt ott egy ifconfig parancs, ami kíírta, hogy a Wi-Fi interfésznek “ether 5c:e0:c5:5d:e2:01” a fizikai, gyárilag beállított címe. Ez a MAC-cím. 🙂

https://hu.wikipedia.org/wiki/MAC-c%C3%ADm

Nézzük meg ezek után a Debian 10-es Linux-om router tábláját. Ezt root-ként (rendszergazdaként) érhetjük el, a route paranccsal. Mára jobbára automatikusan beállítódik minden Linux-on.

root@gergo1:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 600 0 0 wlp2s0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0

Látható a cél, a gateway, a netmaszk, pár adat és az interfész. Ami itt van az egy “sima” hálózatba kötés, Wi-Fi-n keresztül. A netmaszkról lehetne beszélnünk. Binárisan ÉS kapcsolattal az egy IP-alhálózathoz való tartozást fejezi ki, egyszerűen hozzá kell ÉS-elni az IP-címhez. A gateway-ról is szóljunk. Ez nem más, mint az átjárónk, azaz a router-ünk. IP-címe jelen esetben 192.168.0.1. Ezt ki is deríthetjük egyrészt a route -n, másrészt a traceroute parancs kimenetéből – miután apt-get install paranccsal felinstalláltuk. Keressük meg tehát a nic.bme.hu-t, a BME elsődleges DNS szerverét (Domain Name System). 🙂

root@gergo1:~# traceroute 152.66.115.1
traceroute to 152.66.115.1 (152.66.115.1), 30 hops max, 60 byte packets
1 _gateway (192.168.0.1) 7.562 ms 7.526 ms 7.575 ms
..
7 tg0-2-0-3-1110.rtr.bme.hbone.hu (195.111.103.205) 22.009 ms 25.032 ms 25.496 ms
8 xge0-0-0-0.rax.net.bme.hu (152.66.0.124) 32.333 ms 32.308 ms 32.283 ms
9 hge1-0-49.rio.net.bme.hu (152.66.0.67) 26.305 ms 27.216 ms 26.405 ms
10 nic.bme.hu (152.66.115.1) 29.336 ms 29.489 ms 30.286 ms

A DNS egyébként a névfeloldást végzi az Interneten. Egy szervernévhez szolgáltatja a hozzá tartozó IP-címet elosztott adatbázisból.

Általában igaz, hogy egy számítógép hálózatba kacsolásához IP-cím, netmaszk (ebből jön a hálózat-cím, ÉS kapcsolattal), a gateway és egy-két DNS-szerver szükséges. 🙂

Hálózat, IP-címek

A tegnapihoz tartozok még egy magyarázattal. A hálózati szereplőknek egyedi címük van, úgynevezett IP címük. Ez a korábban említett IP protokoll a TCP/IP-ből, az ISO-OSI modell harmadik, hálózati rétegéből.

A világot korábban az IPV4 szerint osztották fel. Az egyetemek többek között úgynevezett autonóm zónákat kaptak. A BME például a 152.66.XXX.XXX úgynevezett B osztályú hálózatot. Azért B osztályú, mert az az első két szám kitöltött, és 256×256 számítógépnek van rata hely. 4 oktet. 4 byte-os cím. Vannak A osztályú, illetve C osztályú hálózatok is ezen terminológia szerint. 🙂

https://hu.wikipedia.org/wiki/IP-cím

http://www.vlsm-calc.net/ipclasses.php

Egy idő után azonban kifogytak ezek az IPV4-es címek, ezért van mára IPV6. Ez jóval több számítógép világhálóra (Internetre) kötését teszi lehetővé. Az IPV6 címek 128 bit hosszúak. Ez sose fog kifogyni, pláne, hogy jelenleg is ún alhálózatokba vannak szervezve a gépek, ahol az egyes végpontoknak pl. egy kábel-hálózatnál csak belső IP-címük van – ezért nem lehet az otthoni gépből többek között webszervert csinálni. Elvileg az adatátviteli technológia szimmetrikus is lehetne, de erősen a letöltési sávszélesség nagyobb az otthoni gépünkön. A sok-sok web, játék és egyéb szervert az úgynevezett “gerinchálózatra” kötik, “szerverfarmokon”. Jelenleg egyébként a két címzési mód keverve van jelen a világban. 🙂

https://hu.wikipedia.org/wiki/IPv6

Ezek után nézzük meg a Debian 10-es Linux-unk hálózati interface konfigurációját. Az ifconfig paranccsal írhatjuk ki a hálózati interfészeinket root-ként (rendszergazdaként). Régebben a hálózatot manuálisan kellett beállítani, ma már pl. az otthoni wifi hálózatot teljesen automatikusan konfigurálja a rendszer. 🙂

root@gergo1:~# ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 27044 bytes 2149063 (2.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 27044 bytes 2149063 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlp2s0: flags=4163 mtu 1500
inet 192.168.0.173 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::60da:3b20:dfeb:9fe0 prefixlen 64 scopeid 0x20
ether 5c:e0:c5:5d:e2:01 txqueuelen 1000 (Ethernet)
RX packets 1241841 bytes 1315097554 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 593763 bytes 132026415 (125.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Jól látható a wlp2s0 interface konfigurációja, a “lo” – localhost, konfigurációja után. A belső hálózati IP-címünk a 192.168.0.173. 🙂

Portszkennelés (Port Scan) Linux alatt – nmap, hálózati kapcsolatok – netstat

Telepítettem a napokban régi jó szoftvercsomagomat, az nmap-et is. Beszéltünk róla, hogy Linux alatt 0-65535-ig (2^16-1) számozottak a portok. Egy port lehet TCP (Transmission Control Protocol – kapcsolatorientált, byte-stream jellegû, megbízható protokoll, pl. “on-demand” kép- és hangátvitel, letöltés, mivel a TCP egy megbízható protokoll, újra küldi az “elveszett” csomagokat) vagy UDP (User Datagram Protocol – összeköttetésmentes protokoll, pl. élő kép- és hangátvitel, online játékok – hibaellenőrzés és csomag újraküldés nélküli “kis adatcsomagocskák”).

https://support.holmsecurity.com/hc/en-us/articles/212963869-What-is-the-difference-between-TCP-and-UDP-

Miután kapcsolódtunk a böngészőnkkel pl. a HTTP 80-as szerverportra, egy ún. “socket” nyílik a szerveren, és a kliens egy 1024-nél magasabb portszámmal kapcsolódik. Ez minden hálózati szolgáltatásnál ugyanígy működik.

http://www.steves-internet-guide.com/tcpip-ports-sockets/

Felmerülhet a kérdés, hogy mennyi kliens-szerver kapcsolat lehetséges. Egy kliens max. 65535 kapcsolatot nyithat egy szerverre, de egy szerver 65535 kapcsolatot tarthat fent kliensenként! Határ a memória és a cpu! 🙂

https://serverfault.com/questions/533611/how-do-high-traffic-sites-service-more-than-65535-tcp-connections

Az alábbiakban egy nem teljeskörű lista látható az alapvető Linux (UNIX) portokról. Az 1024-nél alacsonyabb portszámok a root (rendszergazda) felhasználóhoz kötöttek. A portok többsége TCP.

20 – FTP Data (FTP adatátvitel)
21 – FTP Control (FTP kapcsolat indítása)
22 – SSH (biztonságos távoli adminisztráció, SSL-lel kódolt csatornán)
23 – Telnet (kódolatlan távoli adminisztráció)
25 – SMTP (Mail Transfer Agent, e-mail szerver, mint pl. SEND mail)
53 – DNS (TCP és UDP is)
67 – Bootp
68 – DHCP
69 – TFTP (Trivial file transfer protocol, UDP, "kapcsolat nélküli" adatátvitel)
80 – HTTP/WWW(Apache)
88 – Kerberos
110 – POP3 (Mail delivery Agent)
123 – NTP (Network time protocol idő szinkronizálásra, UDP)
137 – NetBIOS (nmbd)
139 – SMB-Samba (smbd)
143 – IMAP
161 – SNMP (hálózatfelügyelet)
389 – LDAP (központi adminisztráció)
443 – HTTPS (HTTP+SSL biztonságos web elérés)
514 – Syslogd (UDP port)
636 – ldaps (TCP és UDP is)
873 – rsync
989 – FTPS-data
990 – FTPS
993 – IMAPS
1194 – openVPN
1812 – RADIUS
995 – POP3s
2049 – NFS (nfsd, rpc.nfsd, rpc, portmap)
2401 – CVS server
3306 – MySql
3690 – SVN
6000-6063 – X11

A hálózatokat leíró ún. ISO-OSI referenciamodellről az alábbi linkek alatt olvashatunk részleteket. Jól látható az a bizonyos hét réteg, melyen keresztül minden hálózati kapcsolat megvalósul. Az SSH szolgáltatás – ahogy a többi is – az alkalmazási (7-es) réteg része, de minden bitje átmegy a fizikai (1-es) rétegen!

https://hu.wikipedia.org/wiki/OSI-modell

https://www.studytonight.com/computer-networks/complete-osi-model

Az nmap segítségével egy szerverről kideríthető, hogy mely portokon vannak szolgáltatások telepítve. Eresszünk rá egy egyszerű scan-t a localhost-ra! 🙂

gvamosi@gergo1:~$ nmap -A -T4 localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2019-09-19 10:09 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00013s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 996 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10 (protocol 2.0)
| ssh-hostkey:
| 2048 5f:9c:30:d8:aa:23:5a:d2:8b:52:ff:22:cf:c0:ae:6d (RSA)
| 256 3e:25:ef:3e:78:88:07:47:8d:76:67:ce:91:dc:8d:d4 (ECDSA)
|_ 256 d6:8f:00:80:43:8a:c7:05:dc:b4:2b:de:96:c3:12:fb (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Apache2 Debian Default Page: It works
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 4.9.5-Debian (workgroup: WORKGROUP)
Service Info: Host: GERGO1; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Host script results:
|clock-skew: mean: -40m00s, deviation: 1h09m16s, median: 0s |_nbstat: NetBIOS name: GERGO1, NetBIOS user: , NetBIOS MAC: (unknown) | smb-os-discovery: | OS: Windows 6.1 (Samba 4.9.5-Debian) | Computer name: gergo1 | NetBIOS computer name: GERGO1\x00 | Domain name: \x00 | FQDN: gergo1 | System time: 2019-09-19T10:10:03+02:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2019-09-19 10:10:03
|_ start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.11 seconds

Látható, hogy a 22-es, 80-as, 139-es és 445-ös portokon találhatóak “nyílt” portok. Ezt tudhatom fejből is, mivel SSH szervert, HTTP szervert, és Windows-os ún. Samba szervert telepítettem, a hálózaton lévő Windows-os gépekkel való adatátvitelhez. 🙂

Végül nézzünk meg egy még egyszerűbb portszkent! (Figyelem: bizonyos szkenek – pl. UDP – root hozzáférést igényelnek.) 🙂

gvamosi@gergo1:~$ nmap localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2019-09-19 10:39 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00013s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

Végül nézzük meg a netstat parancs kimenetelét (miután a net-tools-t felinstalláltuk). A netstat minden hálózati kapcsolatot feltérképez. Jól láthatóak a https kapcsolatok és az ún. ephemeral portok kliens (gergo1) oldalon. Ezek magasabb portszámok – és nálam sok tab van nyitva a Chrome-ban. 🙂

root@gergo1:~# apt-get install net-tools
..
root@gergo1:~# logout
gvamosi@gergo1:~$ netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 gergo1:44450 13.94.251.244:https ESTABLISHED
tcp 0 171 gergo1:44860 109.233.153.16:https FIN_WAIT1
tcp 0 0 gergo1:57636 ws-in-f188.1e100.n:5228 ESTABLISHED
tcp 0 1 gergo1:58322 40.68.210.8:https FIN_WAIT1
tcp 0 1 gergo1:50668 wo-in-f188.1e100.n:5228 FIN_WAIT1
tcp 0 0 gergo1:56840 104.16.190.66:https ESTABLISHED
tcp 0 1 gergo1:44206 13.94.251.244:https FIN_WAIT1
tcp 0 1 gergo1:52762 13.94.112.175:https FIN_WAIT1
tcp 0 0 gergo1:40996 68.232.34.200:https ESTABLISHED
tcp 0 0 gergo1:60478 e1-ha.ycpi.via.ya:https ESTABLISHED
tcp 0 0 gergo1:48022 52.114.158.92:https TIME_WAIT
tcp 0 1 gergo1:51022 13.107.3.128:https FIN_WAIT1
..
tcp 0 0 gergo1:59514 edge-star-shv-01-:https ESTABLISHED
tcp 0 0 gergo1:51986 xx-fbcdn-shv-01-v:https ESTABLISHED
tcp6 0 0 192.168.0.109:45541 13.69.158.96:https ESTABLISHED
tcp6 0 74 192.168.0.109:41903 13.69.158.96:https FIN_WAIT1
udp 0 0 gergo1:40680 prg02s12-in-f10.1e1:443 ESTABLISHED
udp 0 0 gergo1:40731 bud02s28-in-f8.1e10:443 ESTABLISHED
udp 0 0 gergo1:41421 bud02s26-in-f14.1e1:443 ESTABLISHED
udp 0 0 gergo1:33400 wn-in-f189.1e100.ne:443 ESTABLISHED
udp 0 0 gergo1:41687 bud02s27-in-f2.1e10:443 ESTABLISHED
udp 0 0 gergo1:33916 bud02s26-in-f14.1e1:443 ESTABLISHED
udp 0 0 gergo1:54408 wb-in-f189.1e100.ne:443 ESTABLISHED
udp 0 0 gergo1:38164 muc03s07-in-f99.1e1:443 ESTABLISHED
udp 0 0 gergo1:47052 muc03s07-in-f110.1e:443 ESTABLISHED
udp 0 0 gergo1:52313 ham02s13-in-f14.1e1:443 ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ] DGRAM 32111 /var/lib/samba/private/msg.sock/1547
unix 2 [ ] DGRAM 31112 /var/lib/samba/private/msg.sock/1602
unix 3 [ ] DGRAM 11603 /run/systemd/notify
unix 19 [ ] DGRAM 11622 /run/systemd/journal/dev-log
unix 7 [ ] DGRAM 11635 /run/systemd/journal/socket
unix 2 [ ] DGRAM 11664 /run/systemd/journal/syslog
unix 2 [ ] DGRAM 23637393 /run/wpa_supplicant/p2p-dev-wlp2s0
..

Sőt, így a végére még UNIX domain socket-ek is jutnak. 🙂 Ezek file alapú IPC (inter-process communication) socket-ek. 🙂