Security-all

Na, még ez is: https://www.engadget.com/2017/10/16/encryption-companies-rely-on-has-se…

"The researchers say that key lengths of 1024 and 2048 bits are able to be figured out with little effort using the public portion of the key."

"Researchers at Masaryk University in the Czech Republic uncovered a major security vulnerability in RSA keys generated by Infineon Technologies-produced chips. These chips are used in products manufactured by Acer, ASUS, Fujitsu, HP, Lenovo, LG, Samsung, Toshiba and Chromebook vendors, reports Bleeping Computer and the RSA keys generated by Infineon's chips are used in government-issued identity documents, during software signing, in authentication tokens, with message protection like PGP, in programmable smartcards and during secure browsing."

Csak hogy ne teljen eseménytelenül az idő két wifi router frissítés között, az imént jelent meg egy cikk arról, hogy az Infineon-alapú hardver tokenek (pl. YubiKey) RSA kulcsgenerálása hibás, így az ezzel generált, 2048 bit vagy annál rövidebb kulcsok visszafejthetőek.

Cikk: https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/
Kulcstesztelő: https://keychest.net/roca
YubiKey advisory: https://www.yubico.com/keycheck/

Zsarolóvírus elgyepált egy szervert, csak a webes részen használt fájlokat titkosította. Továbbá a szerveren van egy nyílt ftp is, ott is kifingatott egy pár fájlt.

A levelezést és az userek fájljait nem bántotta.

A szerveren egy régebbi debian van használva.

Nagy kárt ugyan nem tett, a nyílt ftp-t csak fájlok cserélésére, használjuk, a webtartalomról meg mindig van másolat.

A rendszeren (/bin, /usr/bin, /etc, ... stb nem látszik változás fájldátum alapján.

A nagy kérdés: a tárgyban említett zsarolóvírus fogja-e folytatni tevékenységét, esetleg valami módon átterjedhet-e további Linuxos gépekre?

Érdemes-e beruházni licencelt vírusirtóra Linuxis gépeken is (pl. NOD32 Linuxos változata) , vagy az is tehetetlen a zsarolóvírusokkal szemben?

Sziasztok!

Otthoni "szerverem" ssh szolgáltatását próbálják megtörni. Nem hiszem, hogy sikerül, mert csak egyetlen felhasználónak van engedélyezve a szolgáltatás és ő is csak a jelszóval védett rsa kulcsa segítségével authentikálhat, de vannak nem kíván mellékhatásai a betörési kísérleteknek:

1.) Rohamosan hizík az auth.log ezen mennyiségtől:
Sep 23 07:30:31 silent sshd[56367]: Did not receive identification string from 80.200.209.177
Sep 23 07:30:37 silent sshd[56364]: Did not receive identification string from 89.134.132.19
Sep 23 07:30:44 silent sshd[56366]: Did not receive identification string from 94.248.134.50
Sep 23 07:30:57 silent sshd[56368]: Did not receive identification string from 79.122.93.200
Sep 23 07:30:59 silent sshd[56369]: Did not receive identification string from 84.0.156.194
Sep 23 07:31:21 silent sshd[56372]: Bad protocol version identification '2\005\v9\0300\275\304+c\231\304\336/\263f\324\265R\334\243[\313\316:\365\223' from 80.98.102.29 port 50232
Sep 23 07:31:24 silent sshd[56373]: reverse mapping checking getaddrinfo for ecs-114-115-133-158.reverse.hwclouds.com [114.115.133.158] failed - POSSIBLE BREAK-IN ATTEMPT!
Sep 23 07:31:24 silent sshd[56373]: User root from 114.115.133.158 not allowed because not listed in AllowUsers
Sep 23 07:31:24 silent sshd[56373]: input_userauth_request: invalid user root [preauth]
Sep 23 07:31:25 silent sshd[56373]: Connection closed by 114.115.133.158 [preauth]
Sep 23 07:31:33 silent sshd[56376]: Invalid user hacluster from 213.162.48.163
Sep 23 07:31:33 silent sshd[56376]: input_userauth_request: invalid user hacluster [preauth]
Sep 23 07:31:33 silent sshd[56376]: Connection closed by 213.162.48.163 [preauth]
Sep 23 07:31:51 silent sshd[56375]: Did not receive identification string from 89.147.69.187
Sep 23 07:31:58 silent sshd[56378]: Did not receive identification string from 94.248.134.50
Sep 23 07:32:05 silent sshd[56382]: Bad protocol version identification '\375' from 94.21.183.60 port 49731
Sep 23 07:32:14 silent sshd[56380]: Did not receive identification string from 77.98.247.73
Sep 23 07:32:29 silent sshd[56384]: Did not receive identification string from 94.21.239.74
Sep 23 07:32:30 silent sshd[56388]: Did not receive identification string from 89.134.80.99
Sep 23 07:32:35 silent sshd[56383]: Did not receive identification string from 84.1.223.15
Sep 23 07:32:40 silent sshd[56386]: Did not receive identification string from 89.133.255.45
Sep 23 07:32:53 silent sshd[56387]: Did not receive identification string from 37.34.255.55
Sep 23 07:32:54 silent sshd[56389]: Bad protocol version identification '' from 178.164.182.74 port 32993
Sep 23 07:32:55 silent sshd[56390]: Bad protocol version identification '\277\031K\241\f\027\345q\023\335@\233r\355\017\032\371\035\343\2204=RS\260\356\3166V\354\352v:R\331\272s' from 178.164.209.206 port 56791
Sep 23 07:32:56 silent sshd[56391]: Did not receive identification string from 178.164.209.206
Sep 23 07:33:04 silent sshd[56393]: Did not receive identification string from 88.151.101.24
Sep 23 07:33:04 silent sshd[56394]: Bad protocol version identification '#' from 88.151.101.24 port 33904
Sep 23 07:33:08 silent sshd[56399]: Invalid user admin from 176.31.103.117
Sep 23 07:33:08 silent sshd[56399]: input_userauth_request: invalid user admin [preauth]
Sep 23 07:33:08 silent sshd[56399]: Connection closed by 176.31.103.117 [preauth]
Sep 23 07:33:15 silent sshd[56403]: Did not receive identification string from 80.200.209.177
Sep 23 07:33:24 silent sshd[56395]: Did not receive identification string from 81.0.115.55
Sep 23 07:33:25 silent sshd[56396]: Did not receive identification string from 94.21.183.60
Sep 23 07:33:26 silent sshd[56397]: Did not receive identification string from 94.248.134.50
Sep 23 07:33:27 silent sshd[56398]: Did not receive identification string from 195.184.176.2
Sep 23 07:33:28 silent sshd[56409]: Bad protocol version identification '\310\2123\321\274\263Q`\233\355\365\214D0%`\262\304\031\226X_\254\355U`\240r\304\205{"\206\365\232\236' from 185.148.3.118 port 56965
Sep 23 07:33:28 silent sshd[56410]: Did not receive identification string from 185.148.3.118
Sep 23 07:33:33 silent sshd[56401]: Did not receive identification string from 62.201.105.89
Sep 23 07:33:34 silent sshd[56402]: Did not receive identification string from 85.238.76.249
Sep 23 07:33:40 silent sshd[56404]: Did not receive identification string from 81.156.46.114
Sep 23 07:33:40 silent sshd[56413]: Bad protocol version identification '&V\036\005\307\262by\231\261x*C\322\343\033\255\327\376\021\3271\002\002\240\204\256\026\t~\364\231h\177R\220\254\2272' from 80.98.50.45 port 57795
Sep 23 07:33:43 silent sshd[56407]: Did not receive identification string from 91.147.204.212
Sep 23 07:33:44 silent sshd[56408]: Did not receive identification string from 84.0.156.194
Sep 23 07:33:52 silent sshd[56406]: Did not receive identification string from 89.132.92.173
Sep 23 07:33:53 silent sshd[56416]: Did not receive identification string from 95.211.101.149
Sep 23 07:33:56 silent sshd[56412]: Did not receive identification string from 94.21.104.35
Sep 23 07:33:58 silent sshd[56419]: Invalid user hadoop from 213.162.48.163

2.) A túlterhelt sshd daemon néha engem is elzavar "ssh_exchange_identification: Connection closed by remote host" üzenettel, ami jobban zavar.

A hálózat így néz ki:
internet --> lede-t futtató router --> LAN --> debian szerver, melyen fut az sshd

Mivel a szolgáltatómtól dinamikus IP-t kapok, ezért a duckdns szolgáltatását használom a távoli elérés megkönnyítésére és a routeren a port forwardolva van a szerver ssh portjára, ami persze nem az alap 22-es.
Mind a router, mind a szerver csomagszűrőjében droppolva van, ha egy külső IP-ről bizonyos időn belül több kérés érkezik, de mivel változó IP-kről jön a kérés, ez halottnak a csók.

Amit próbáltam:
1.) Új IP kérése a szolgáltatótól. -> Nem vált be: gondoltam a ddns szolgáltatás miatt
2.) ddns szolgáltatás leállítása és új IP kérése a szolgáltatótól -> Nem vált be az új IP-t ddns nélkül is megtalálták

Nem hiszem, hogy jó megoldás, hogy elkezdem növelgetni a MaxSessions és MaxStartups értékeket, ezért jelenleg ez a kompromisszumos megoldásom:
- A ddns szolgáltatás fut a változó IP miatt
- A routeren nem forwardolom a portot az ssh daemon felé
- OpenVPN fut a routeren, mely segítségével elérem a helyi hálót, ahonnan már beléphetek ssh-val a szerverre

Ez azért kényelmetlen, mert eddig elég volt egy pendrive-on vinnem az ssh-n át belépéshez szükséges programot, kulcsot, most meg vpn klienst is cipelhetek a certjével.

Szerencsére ez a támadás nem emészti fel az erőforrásokat (van szabad RAM és a load is 0.07), de zavar.
Mit tehetek még? Mi lenne ennél jobb, de kényelmesebb megoldás? Ti mit tennétek a helyemben?

UPDATE: Megoldva
Elnézését kérem a társaságnak, user error volt és mentem is a lammer számlálót pörgetni.

A logokat visszanézve a próbálkozások, percre pontosan akkor kezdődtek, amikor routert cseréltem és vele együtt openwrt-ről lede-re váltottam. A konfigurálás nem backupból történt, hanem nulláról és kézzel szerkesztettem a konfigurációs fileokat, így a firewall konfigból kimaradt az src_dport sor a portforwardnál.
A post előtt és közben is átnéztem mindent 100-szor, de elsiklottam felette. :-(

Tegnap este a régi config file-ok újakkal történő diffelése dobta ki lammerságom.

Lehet facepalmolni! Ciki, nem ciki: that's all folks! Köszönöm mindenkinek a rám fordított időt!

Nyugdíjas családtag írt nekem, viszont egyáltalán nem értek a témához, mivel a saját gépemen csak Linuxot használok, a céges gépen meg a céges IT által telepített nagyvállalati védelmi megoldás van.

Biztos vagyok benne, hogy valami ingyenes megoldást szeretne. Tudtok segíteni, hogy mit kéne javasolni neki?

Jelenlegi gépem 3 évvel ezelőtti (használtan) vásárlásakor az eladó (egyébként rendszergazda valahol) az MS Essentials-t telepítette víruskeresőként.

Azzal én elégedetlen voltam, mert az internetről percek alatt rengeteg szart szedett össze a gép (felugró ablakok, hangosan bjelentkező reklámok, stb).
Viszont nem tudtam az általam jónak vélt ESET-et felrakni, mert ütközött az MSE-szel. Valahol azt olvastam, hogy az YAC-val le lehet szedni, telepítettem tehát azt.
Az MSE- leszedni ugyan nem tudtam vele, viszont az MS-t kiegészítve egész idáig faszán karbantartotta a gépemet. kipucolta a Junk-okat, a Registry Key-ket, stb.
Szóval nagyon megszerettem az YAC-t és egész idáig használtam is. (YAC=Yet Another Cleaner)

Valami azért nem lehet rendben vele, mert a Win10 Xxxxxx gépére az Istennek sem engedte, hogy telepítsem...

Az eddigi gyakorlatom az volt, hogy az YAC-t minden bekapcsolás után lefuttattam, A MSE-t pedig hetente.

Ma viszont az MSE több tisztítani való dolgot is talált és újraindítás után eltűnt az YAC-m.

KÉRLEK JAVASOLJ VALAMIT HELYETTE, AMI talán NEM CSÍPI A MS SZEMÉT

Van egy intézményi CA. A tanúsítványa természetesen benne van kliensen a Trusted Root CA store-ban.

- aláírok vele egy sima tanúsítványt: host.cegnev.hu -> működik
- aláírok vele egy wildcard tanúsítványt: *.cegnev.hu -> működik
- aláírok vele egy sima tanúsítványt az intranet számára: host.foobar -> működik
- aláírok vele egy wildcard tanúsítványt az intranet számára: *.foobar -> nem működik

A "*.foobar" benne van a CN-ben és a subjectAltName-ben egyaránt, ahogy azt kell.
Az intranetes DNS név feloldódik rendesen.
OCSP nincs használatban.

A Firefox ezt mondja:

host.foobar uses an invalid security certificate.
The certificate is only valid for *.foobar
Error code: SSL_ERROR_BAD_CERT_DOMAIN

A Chrome pedig ezt:

This server could not prove that it is host.foobar; its security certificate is from *.foobar.

De miért nem match-el? Van arra valami előírás, hogy intranetes domainen nem lehet wildcard cert?

"openssl s_client -connect host.foobar:443" szerint a cert rendben van...

Világosítsatok fel, lécci! :)

UPDATE

Ez van a Chromium forrásában:

// We required at least 3 components (i.e. 2 dots) as a basic protection
// against too-broad wild-carding.

Nyilván a Firefox is hasonlóképp viselkedik.

Üdv mindenki,

Csinálok egy doksit (nevezzük úgy), ami amúgy szabadon felhasználható, módosítható, ám én azt akarom, hogy amit én kiadok a kezemből, az egyértelműen azonosítható legyen, hogy azt én csináltam (csesztem) el, és nem más. Gondoltam hogy mi sem egyszerűbb ennél, digitálisan aláírom a .pdf-et, és remek, sőt, csodálatos lesz minden.

Az alapvető probléma ott kezdődött, hogy hirtelen nem nagyon találtam meg, hogy honnét is kapnék én olyan certet (nem bánnám ha nem drágán, hovatovább ingyen), amivel alá tudom írni a fájlokat, és mindenféle csiribú nélkül látszik - elsősorban Windowson -, hogy lám, ezt Fisher csinálta, azért olyan, amilyen.

Csinált már valaki ilyet? Akarok én ezzel szenvedni?

Sziasztok,

Arra esetleg valakinek van otlete ,hogyan lehet elszeparalni egy IoT eszkozt a halozaton? Lehetoleg az alabbi eszkozok segitsegevel :)

Jelenleg egy szolgaltatoi modem/router (Huawei HG635) illetve 3 managed switch all rendelkezesemre:

NetGear ProSafe GS108PE
NetGear ProSafe GS110TP-200EUS
HPE PS1810-8G

Ha berakom az eszkozt kulon VLAN-ba az eleg vagy router oldalon is erdemes lenne jobban korlatozni?

Vagy vegyek egy normalis routert is? (ha ez lenne a konkluzio akkor ehhez is szeretnek segitseget kerni)

Az elerni kivant eredmenyek:

-Az IoT eszkoz tudjon egy adott internetes IP cim fele kommunikalni de ne lasson ra a belso halozatra egy ip kivetelevel.
-Belso halozatrol is elerheto legyen (ez ellentmondas az elozo kitetellel de akkor kellene mukodnia ha masik belso eszkozrol kezdemenyezik a kommunikaciot)
-Ha az eszkozt eltavolitjak masik eszkozt ne lehessen csatlakoztatni (ha jol latom ez megoldhato valamelyik NetGear eszkozzel)

Jelenleg igy nez ki a halozat: (a fekete vonal az ket kulon szintet hivatott abrazolni a hazban)

https://ibb.co/chEYu5

Amióta utoljára láttam fizetős lett a malwarebytes androidos verziója. Megváltozott (elgagyisodott) a kezelőfelület és első ránézésre nekem 'áltudományosnak' tűnik a védekezési metódusa (pl. úgy próbálja gátolni a kártevő települést hogy magára irányítja az apk-futtatást, és persze elutasítja annak a települését - persze ha a user simán kiválasztja a futtatáshoz az apk installert, akkor ennyi). A scanner látszólag úgy tesz, mintha - de nem tudni mi történik.
Kinek mi a tapasztalata, megér ez évi 3990-et? Van-e értelme egyáltalán egy ilyen megoldásnak telefonra?

Üdv,

https://www.atlantic.net/community/howto/install-openvas-vulnerability-…

Telepitettem ezen leirás alapján egy OpenVAS-t tesztelési céllal, viszont scannelni nem akar, mondván "Internal Error"

openvas-check-setup --v9
https://pastebin.com/PCvwQEBf

itt minden jó, a warningok ingorálhatóak.

A probléma ott kezdődik, hogy amikor a webes felületen felveszek egy hostot, taskot, akkor az "Requested" státuszba kerül, amikor rákattintok hogy megnyissan az eredményt átvált "Internal "Error"-ra.

openvasmd.log
https://pastebin.com/h2JcsqfT

openvassd.log
https://pastebin.com/Qx7BFd5K

[root@testvm neut]# uname -a
Linux testvm 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@testvm neut]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

Mi a gond?