Security-all

Apropó a téma újbóli feldobására,
Spanyol helyzet (Infineon):
- http://www.zdnet.com/article/id-card-security-spain-is-facing-chaos-ove…

Észt helyzet (Gemalto):
- http://www.zdnet.com/article/estonias-id-card-scrisis-how-e-states-post…

Részletek:
- https://arstechnica.com/information-technology/2017/10/crypto-failure-c…
- https://crocs.fi.muni.cz/public/papers/rsa_ccs17

Röviden: "A remote attacker can compute an RSA private key from the value of a public key. The private key can be misused for impersonation of a legitimate owner, decryption of sensitive messages, forgery of signatures (such as for software releases) and other related attacks."

Vajon a hazai igazolványokkal mi a helyzet?

Sziasztok,

nem tudja valaki hogy alapvetöen elehtséges-e openwrt/LEDE-ben a vezetékes hálózati interfészt wpa-val felhozni mint Ubuntuban:
auto eth0
iface eth0 inet dhcp
wpa-iface eth0
wpa-driver wired
wpa-conf /etc/wpa_supplicant/wired.conf

Egy NAC(Radius) felé kellene Cert-el authentikálnom vezetékes hálózaton. Most próbálgatom nem sok sikerrel eddig...

Köszi,
üdv!

Sziasztok,

A segitsegeteket szeretnem kerni az alabbiak megvalaszolasaban:

Nemreg elkezdtem hasznalni a Yubikey 4 -et.

Sikeresen atpakoltam ra a gpg kulcsomat (Master private key kivetelevel szoval csak a subkey -ek vannak rajta) mukodik is tokeletesen.
Az viszont nem egyertelmu szamomra ,hogy a gpg kulcson kivul tudok e ra mast is pakolni parhuzamosan pl X509 certeket?
Azt tudom hogy onmagaban ez lehetseges de akkor is ha mar rajta van a gpg kulcs is? Vagy ez masik slotban tarolodik?

Egy réssel kevesebb. :)

Hello!

Generáltam több privát kulcsot openssl-lel. Sajnos nem tudom, hogy melyik kulccsal generáltam a .csr-t.
Hogy tudom kideríteni a .csr és az aláírt cert file-ból, hogy melyik a hozzá tartozó .key ?

Köszi, cs.

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