Törölnöm kell az nmap-ot...

A kedves munkaadóm IT security csapata utasított, hogy törölnöm kell minden szerverről az nmap-ot!
Persze indoklás nincs!

El se tudom képzelni, hogy mit hisznek erről a programról...

( persicsb | 2019. 08. 06., k – 12:40 )

Első körben inkább az a kérdés, hogy egy diagnosztikai célú eszköz mit keres egy production szerveren?

Pont diagnosztikai célok miatt.
Mivel a tűzfalakra külön csapat van, ha nem működik két gépem között a kapcsolat, akkor nmap-al szoktam csekkolni, és küldeni az illetékeseknek róla képernyő képet.

Mit árthat az nmap, ha csak és kizárólag legális célokra használom, kizárólag a saját hálózatunkban, és csak akkor, ha valami gebasz van?

nmap es nc mellett meg telnet kliens is van. Le akartak szedetni, azota is van. Mert kell. Pedig nem olyan nagy kornyezet, <1k host. Poppet bonyolult a network, sokszor kell olyat nezni hogy adott hostrol, adott remote host adott tcp portja elerheto-e, milyen portok vannak nyitva stb.
____________________
echo crash > /dev/kmem

Mivel scannelsz vele és portokat próbálgatja mindet egyesével gondolom erősen meghajtha a netzwerkes eszközöket és vmi ddos attacknak vagy akárminek érezheti a tűzfal vagy eszköz.
Kérjél exceptiont rá hogy neked kell különben nincs debuggolás, rakj mellé 1-2 ticketet is példának. Vagy a következő debugnál szólj egy managernek hogy húú de jó lenne most az nmap de security letöröltette szóval én most megyek kávézni mert annyira sajnálom de nem tudok már mást csinálni.
Több céget is megjárva az a tapasztalatom hogy a security-s emberkék nem prodból jönnek és nem értik a folyamatokat ott de ez csak saját tapasztalat és nem általánosítanék hogy mind egy szellemi fogyatékos mocsári nyehőce lenne, tényleg nem.
Ha nem adják meg akkor meg a netcat, telnet binárisok futtatása kézzel bár úgyis észreveszik.Volt már hogy így kellett megoldani, de mondjuk ha megoldást találsz rá akkor elfelejtheted az exceptiont.

Egy gépről is lehet DDoS-t végrehajtani? Szerintem nem!
Mellesleg ez nem volt célom, írtam is fentebb, hogy kizárólag a saját lanunkon belül szkenneltem azokat a portokat, ahol elvileg az appnak kell figyelnie. Bebaszna, ha egy szál "nmap -p 22,80,443,stb remotehost" ledosolna egy hostot/switchet/routert :-)

Hacsak nem az a controller gép ami az összes többi hálózaton belüli (megtört) gépet irányítja :)
Amúgy ne DDOS-ban gondolkodj: Az túl feltűnő.. A legtöbb esetben meg pont a rejtőzködés a cél, hogy minél mélyebben be tudják enni magukat..
Nmon esetén inkább a port scanning az ami production oldalról nem kellemes
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ahhoz se telnet, se nmap nem kell, elég egy bash:

/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a TCP connection to the corresponding socket.
/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.

Pl:
$ cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_8.0
^C
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

perl? Az mindenhol van :)

# perl -le 'use IO::Socket::IP; $socket = IO::Socket::IP->new(PeerAddr => "localhost", PeerPort => 22); if ($socket) { $socket->close; print "OK"; } else {print "NOK"}'
OK
# perl -le 'use IO::Socket::IP; $socket = IO::Socket::IP->new(PeerAddr => "localhost", PeerPort => 23); if ($socket) { $socket->close; print "OK"; } else {print "NOK"}'
NOK

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

DNS névfeloldásra ott a dig (az még tudtommal nem security kockázat, bár a franc se tudja :)) - hogy kapcsolódik ez egy tűzfal beállítás / szolgáltatás elérhetőség teszteléshez?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Úgy kapcsolódik, hogy a domain név feloldhatóság a szolgáltatás elérésének egy feltétele, amit neked debugkor le kell ellenőrizned.

Viszont itt van egy nagy tévedés: a dig/host egy dns resolverként műkidk, nem teszteli a rendszer name service rendszerét: pl. ha domain név feloldás a hosts file-ban beállítva azt diggel nem tudod tesztelni.

( bAndie9100 | 2019. 08. 06., k – 12:50 )

az semmi, nekem a corporate viruspajzs mindig torli alolam a netcat.exet mert az "potentially malicious". meg a cygwines gnubugreport.exe ... az mind kozul a leveszedelmesbike.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Korabbi munkahelyemen volt, hogy valamilyen virusvedelem panaszkodott, hogy egy program egy uj .exe-t hozott letre, es az milyen veszelyes dolog, illetve, hogy az exe hash-e nincs benne az ismert programok listajaban, es amugy is ki akar menni a netre. A program, ami az exe-t csinalta, a Visual Studio akkor aktualis valtozata volt (mondjuk a virusokat valoszinuleg tenyleg ezzel forditottak), a program valoban neten kommunikalt, a hash-e meg azert nem volt benne, mert akkor fordult.
Vegul felvettem a kivetelek koze.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Attol fugg.. ha az uj programot felismerte, a VS-t is felismerhette volna, nem olyan ritka Windowson, szerintem hallottak rola (van egy tippem, hogy a legtobb antivirus is azzal keszult).
Jo, adminkent nem volt nehez felvenni a kivetelek koze, de allitolag van olyan ceg, ahol fejlesztokent sem kapsz admin jogot a gepedre.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

> Jo, adminkent nem volt nehez felvenni a kivetelek koze, de allitolag van olyan ceg, ahol fejlesztokent sem kapsz admin jogot a gepedre.

Sajnos a tobbseg valamiert ilyen. Mondjuk az jo volt, amikor a lokal rendszergazda azzal probalt lerazni, hogy a global CIO tud csak ilyet engedelyezni, en meg irtam neki egy levelet, ccben a kollegaval, masnapra meglett az admin jog.

> az install/uninstall is eleg indok.
Ezt mondjuk Linuxon kivaloan meg lehet oldani local repo-val es megfelelo sudo jogokkal. Csak mondom.

> Oszinten szolva nem ertem ezt a nagy admin-idegenkedest
En is local admin parti vagyok. De elnezve hogy mennyi sikeres malware/ransomware tamadas van mostanaban, megertem hogy cegek miert nem szeretik.
____________________
echo crash > /dev/kmem

> Ezt mondjuk Linuxon kivaloan meg lehet oldani local repo-val es megfelelo sudo jogokkal. Csak mondom.

Windows-on is, de ha mar arra kell varni, hogy valaki betegye a local repoba a csomagot, akkor ott vagy, ahol a part szakad. :)

> De elnezve hogy mennyi sikeres malware/ransomware tamadas van mostanaban, megertem hogy cegek miert nem szeretik.

Hat ja, de pont ez az, hogy ezek jelentos resze nem ker admin jogot, eleg ha van rw jogod a halozati meghajtora. :)

Peldaul ha embedded eszkozoket fejleszt, akkor az EPROM égetéstől kezdve az eszközzel való kommunikációs programig bármi kérhet admin jogot, ami a szabvány protokolloktól eltérő módon tervezi felhasználni bármelyik csatlakozót a gépen.
--
Blog | @hron84

"valahol egy üzemeltetőmaci most mérgesen toppant a lábával" via @snq-

( hrgy84 | 2019. 08. 06., k – 14:35 )

Bocs, üzemeltetőként mondom, hogy teljesen jogos az IT security észrevétele. Ha feltörik a szervert akármiért, ne álljon a betörő kezében egy portscannelésre kész eszköz. Arról nem beszélve, hogy a hálózati monitoring szerveren kívül semmelyik prod szerveren nem kötelező fenn lennie. Vannak alap dolgok, amiket én is szeretek kézközelben tudni, ahol nincs külön hálózatos csapat, ott az nmap is ilyen, de ahol van, ott a szerverüzemeltetésnek nem scope-ja a hálózat tesztelése semmilyen formában.

De ki is tolhatsz velük: csinálj rá egy SELinux szabályt, hogy csak az nmap role-al rendelkező felhasználók/programok indíthassák el. De sajnos a legtöbb cégnél a SELinux is Disabled állapotban van.
--
Blog | @hron84

"valahol egy üzemeltetőmaci most mérgesen toppant a lábával" via @snq-

Attól függ.. Ha direktben az OS fölött fut az adott sérülékeny szolgáltatás, akkor valóban nincs nagy különbség. Viszont normális helyeken most már igyekeznek minimum plusz egy izolációs réteget rakni az OS és a service közé (pl konténer), mely esetben viszont már nem alap akár egy python megléte a szolgáltatás megtörése után.

Edit: Amúgy a port scanning csak egy tulajdonsága az nmap-nak ami miatt security szempontból kifogásolható.. A fingerprint/version detection, illetve scripting engine support sokkal komolyabb probléma forrás tud lenni (utóbbival simán lehet Vulnerability detection scan-t is csinálni, tehát nem csak azt nézed meg, hogy adott port elérhető e, hanem a mögötte lévő szolgáltatás sérülékeny e arra a hibára amire neked már van exploitod)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Persze, hogy meg fogja nézni, de ne kínáljunk már neki ezüsttálcán egy toolt amivel ezt teljesen automatizáltan meg is tudja tenni, ahelyett, hogy kismillió scriptet / binárist fel kelljen töltenie..
A patchelés meg amúgy szép dolog, de egy hibásan beállított szolgáltatás ugyan úgy sérülékeny tud még lenni tőle.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Értem is meg nem is az érveidet.
Ha feltörik a szervert, akkor azt csinál vele, amit akar, pl "yum install nmap -y".

Csak akkor használom, amikor az addig működő szolgáltatás már nem működik tovább, mert tőlem kívül álló csoportok/cégek néha keresztbe tesznek nekünk. Szóval utasításra leszedtem, de amikor kell, újra fel fogom tenni, aztán persze megint le fogom szedni.

Értem is meg nem is az érved.
Alapból abból indulsz ki, hogy ha valaki feltöri a szervert, akkor nyomban root access-t is szerez, holott simán lehet, hogy csak a szerveren futó egyik szolgáltatáson keresztül tudott bejönni (mely esetben a szolgáltatás jogosultságát örökli, ami meg értelmes (!) esetben nem root). Persze innen még lehetősége van egy támadónak továbbmenni (és mondjuk egy privilege exploit-on keresztül feltörni magát rootba), de pont ez miatt szokták leszedni az olyan toolokat, amit user mode-ban is lehet használni, hogy adott támadó ne legyen képes azon keresztül tovább támadni (bármely irányba).
______________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Rossz kérdés: Nem a feltölt szervert scanneli, hanem a vele azonos hálózatban lévő további szervereket, lehetséges célpontok után kutatva (lásd: worm)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( NevemTeve | 2019. 08. 06., k – 17:03 )

Nincs új a nap alatt: nálunk N+1 évvel ezelőtt hallottak IP/ICMP-alapú támadásokról (pl), ezért törölték a /usr/bin/ping nevű fájlt. (És még szerencse, hogy nem tudtak arról, hogy a sérülékenység (mármint, ha van egyáltalán) a kernelben van, mert akkor talán azt is törölték volna.)

Röviden: Igen (maximum annyi időre teszünk fel fordítót amíg az tényleg kell, utána azonnal le vele - alternatíva, hogy containerben fordítunk, majd a fordított bináris kimenekítése után a containert teljesen leállítjuk / eldobjuk).

Kicsit hosszabban: Ha feltételezzük, hogy valakinek sikerült bejutnia egy szerveredre (tipikusan valamilyen szolgáltatás userének a nevében), akkor onnan általában 2 út vezet előre* :
1) A hálózaton belül elérhető további célpont(ok) keresése és támadása
2) A már megszerzett gépen privilégium szint emelés (rootig ha lehet)

Na most ha a rendszeren már alapból van bármilyen tool ami ezeket segíti, az security szempontból csücskös. Ha megnézel egy tipikus támadási modelt, akkor azt fogod látni, hogy emberünk valahogy bejut, körbenéz mit lehet használni (ha talál valamit akkor annak örül és használja), és a hiányzó dolgokat megpróbálja magától pótolni. Ebben benne van egy sima file letöltéstől kezdve (amiben aztán bármi lehet) egy teljes kernel exploit fordítása is.
Adott kérdésre visszatérve: Ha van a gépen compiler, akkor egy ilyen fordítást eléggé meg tudsz neki könnyíteni. Persze ezt is simán ki lehet játszani (mondjuk a támadó maga előre lefordítja / cross-compile-olja az exploitot, feltölti a saját oldalára, majd azt próbálja meg letölteni a szerveredről aztán futtatni), de ezek mind-mind plusz "zajt" generálnak, amit könnyebben észre lehet venni (mást nem utólag)

* Esetleg ide lehet még sorolni azt is, hogy megelégszik valaki a megszerzett privilégiummal, és simán átáll "hallgató" (de hülyén hangzik - listening) módba, és simán monitorozza a forgalmat ezen keresztül..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

bocsánat, kihagytam hogy a történethez az is hozzátartozik, hogy ide van embereknek ftp/shell accesszük. és nem rbash. így szerintem értelmetlen valamit nem telepíteni system-wide, amikor különösebb nehézségek nélkül tud hozni magával az aki akar.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Nem, nem mind1.
Még ha van mindenkinek is FTP/Shell access-e (Remélem SFTP / SSH-ra gondoltál, mert plaintext ftp/telnet-et már rég ki kellett volna írtani mindenhonnan!), és nem anonymousként logolnak be, akkor is csak a belső hozzáférések adta risk-et tekintheted elfogadhatónak (vagy csak simán ignorálod, hogy van ipari kémkedés a világon), de egy külső (értsd: Hozzáféréssel amúgy alapból nem rendelkező) támadó ellen akkor is védekezni kell! Az nem kifogás, hogy "De ha a Jucika belép, akkor ő már azt csinál amit akar" (Elnézést minden Jucikától) -> 1 részről NEM, nem csinál azt amit akar, csak amihez joga kell legyen (azt ne mond, hogy direktbe rootként lépnek be, mert akkor szerintem kapcsold ki az összes tűzfalat is), más részről ha netalán joga is van arra, hogy olyat csináljon akkor azokat a usereket úgy is kell védeni, hogy bárki csak úgy ne tudja megszerezni őket (pl CSAK SSH hozzáférés, kulcs alapú authentikáció, és csak adott host(ok)ról)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

sokmindenről írsz ami általánosságban jó, igaz, de itt a feléről szó sincs.
nem érdekes milyen SSL/TLS réteg felett nemérdekes milyen cipher suittal és milyen rekeying gyakorisággal utazik a nemérdekes milyen fájlrendszer hozzáférést nyújtó protokol a hálózaton, és szintén nem tartozik a témához hogy a parancsvégrehajtást nyújtó cucc telnet/rsh/rpc/fastcgi, a lényeg hogy megengedett egy alapkörű fájl/shell access. (és épp plaintext keblekre gondoltam)
unauthorized támadó? miben nehezíti a /usr/bin/gcc hiánya az unauthorized emberkét a támadásban?
"amihez joga kell hogy legyen" – természetesen, én is követem a least privileges principlet, de attól még szerintem overkill uninstallálni a cat-ot mondvan hogy mivan ha a billzetről begépel egy malicious kódot.
tudom ez egy elfajzott példa, de talán szemlélteni hogy a cat se, a gcc se ajtó se az épületbe se az épületben a kincstárba, hanem egy állomás a sok útvonal egyikén.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Teljesen jogos, hogy a sok állomás közül az egyik (lehet), és alapvetően egyet is értek azzal amit írsz.
Viszont vedd figyelembe azt is, hogy security szemlélettel nézve a gcc igen is használható egy újabb állomás elérésére, így ennek a támadási vectornak a kihasználhatóságát limitálni kell (vagy lehetőség esetén megszüntetni).

Tudok én is olyan use case-t ami prod környezetben megköveteli a gcc meglétét, de általánosságban ez (a személyes tapasztalatok alapján) elég ritkán jön elő - tipikusabb az, hogy előre fordított és csomagolt dolgokat kell feltenni. Persze más dolog ha nem production rendszerről beszélünk, hanem development / staging-ről (itt már sokkal indokoltabb szerintem is a fordító léte, tekintve, hogy ezen rendszereken valós fejlesztés folyik).

Ha ez a megállapítás viszont megállja a helyét, akkor security szempontból tényleg nehezen indokolható, hogy egy "évente párszor szükséges" tool folyamatosan fent legyen egy prod szerveren, úgy hogy bizonyos szinten security risk-et hordoz magában.. És ha még így is valaki kardoskodik amellett, hogy "de, még így is kell", akkor is lehet azzal érvelni, hogy "akkor miért nem fordítasz containerben?, ami amúgy security szempontból teljesen elfogadható kompromisszum lenne (egész addig amíg auditálható, hogy pontosan ki indítgatja a konténereket).

De amúgy igazat adok abban, hogy feleslegesen pörgünk itt a gcc-n.. Van még jó pár olyan tool ami ebbe a kategóriába tartozik és szintén izolálni kéne -szerintem- a fő rendszertől ha SecOps-ban gondolkodik az ember..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Baromsag, akinek annyira kell a gcc, visz magaval. A legtobb malware-t meg eleve sajat linkerrel linkelik forditaskor, es igy erik el, hogy a virusirtok tobb false positive-ot fognak ma mar, mint tenylegesen malware-t.

A tamadonak nem lesz sokkal kevesebb baja attol, hogy nincs ott egy gcc, ha mar volt olyan ugyes, hogy odaig bejutott. Ellenben az adminnak tobb munkanapjaba kerulhet, hogy nincs. Uzleti statisztikaban az utobbi nagyobb varhato veszteseg.

milyen usecase-ben kell hasznalni prod serveren gcc-t? ugye minden program valami csomagbol jon, az meg nem helybe buildeljuk. most igy hirtelen valami elvetemult perl/python libraryt tudok elkepzelni ahol a asm kodot dinamikusan forditja telepiteskor. esetleg valami dkms modul.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

"lyukas az egyik csomag es a distro nem adja az ujat" - Ilyet commercial distronál (Redhat / SLES / Ubuntu Advantage) tapasztaltál (ahol ezért amúgy elvileg auto nyithatod is a support ticketet), vagy valami self-hosted környezetről beszélünk?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( msandor v | 2019. 08. 07., sze – 12:14 )

Azt elfelejtettem mondani, hogy egyik szerverünk sem érhető el az Internet felől, tűzfal mögött ül a DMZ-ben egy reverse proxy szerver, és csak a 80/443-as portokat kapja meg, majd a megfelelő szerverre továbbítja a forgalmat, amik egy másik tűzfal mögött ülnek a DMZ2-ben.
És van még egy tűzfal a DMZ2 és a LAN között, ahol csak a LAN-ból mehetünk a DMZ-be, ssh-n.

Szóval nem érzem nagyon kockázatosnak a dolgot...

Sima ügy, szóltak a főnökömnek, ős szólt nekem, én azonnal töröltem mindenhonnan.
Nem a felelősség vagy a parancs végrehajtása a kérdés, pusztán szeretném tudni az okát.
Mert én sem tudok mindent, minden nap tudok újat tanulni, ez is ilyen dolog.

És sok hasznos hozzászólás érkezett, amiből már látom, hogy veszélyes fegyver lehet az nmap, hiába csak jó célra használtam eddig. Gondolom a legrosszabb esetre kell készülni.

Azt nem tiltják, hogy debuggolás miatt ne telepítsem, de utána rögtön le is fogom szedni, és akkor békesség lesz :-)

Pl. lehet egy ok, hogy a menedzsment nem szeretné, ha a belső topológiára vonatkozó információk könnyen megszerezhetővé vagy elérhetővé válnának. Másik ok, hogy a szoftverkörnyezetben vagy benne van az nmap, mert valamilyen okból erre szükség lehet, vagy nincs és akkor ha mégis fenn van, le kell venni. Sztem ennél idiótább dolgok is előfordulhatnak, ez nálam még nem veri a lécet.