Linux-security

Sziasztok,

Eddig a szervereimen letsencrypt-et használtam, de most van egy aminek gogetssl-től vásárolt certificate-et kellene beállítanom.

Csináltam egy privát kulcsot amiből generáltam egy csr file-t. Ezt elküldtem az ügynöknek, aki visszaküldött egy zipet amiben mindösszesen két file van:
domain.ca-bundle (ez két  begin end certificate részt tartalmaz)

domain.crt (egy begin end certificate)

A .crt-t le tudtam ellnőrizni a openssl x509 -text -noout -in domain.crt paranccsal, látszanak benne a következő adatok:

- Issuer: GoGetSSL

- validity: from-to dátum

- Subject: CN=domain

A szerveren Debian stable fut. Hogy kell ebből nginx alá kulcsokat generálni?

köszi,

Zamek

miért vették le a kernel.org-ról és miért nincs erről infó?

Nem olvastam, hogy lett volna hír róla, itt a hupon.  Esetleg van valakinek bővebb infója?

https://biztonsagportal.hu/igy-leplezi-magat-egy-linuxos-trojai.html

Any unprivileged user can gain root privileges on a vulnerable host.

10 éves bug, részletek itt.

A segítségetekre van szükségem. Tesztelem a készülő ContainerSSH 0.4 preview releaset és tesztadatokra lenne szükségem. Kérlek, teszteld le:

TÖRÖLVE

Tetszőleges felhasználónévvel/jelszóval jelentkezz be és légyszi jelezd ha találsz valamilyen anomáliát. Egy bugot már találtunk, MacOS/kitty kombóban a prompt kétszer jelenik meg.

Ha találtál valamit, légyszi küldd el az oprendszeredet, terminálod típusát, a teszt időpontját, az IP címedet, és egy képernyőképet a handshake@containerssh.io cimre. Igény szerint megtalálod a GPG kulcsunkat itt.

Az adataidat természetesen töröljük amint a release elkészült, illetve igény szerint értesítünk arról, hogy mi volt a probléma.

Köszönöm szépen a rászánt idődet.

Update: köszönjük  tesztelést, a honeypotot lekapcsoltuk.

Update 2: Megjelent, köszönjük mindenkinek a segítséget!

Sziasztok!

Általában nem a 22-es porton használom az SSH-t és eddig elég ritkán találták meg.

Azonban most az elmúlt hónapokban több szerveremnél is rátaláltak és persze megváltoztathatom megint, de
elgondolkodtam, hogy a 22-es portra felrakok valami fake SSH szervert és ott nyugodtan próbálkozhat.
Így nem fogja keresni a valós másik port-ot amit használok.

Elég sok fake ssh-t találtam, de nem tudom melyik a jó, melyik az amelyiket tényleg nem tudja egy bot sem megkülönböztetni egy igazitól?
Vagy ssh honeypot-ra keressek inkább?

- mielőtt még írná valaki, használok fail2ban-t és nem a biztonság növelése érdekében, hanem zavar ha valaki dörömböl az ajtón miközben én dolgozok
- a fail2ban teszi is a dolgát, de még így is sok kérés van, mert van hogy napi szinten 300-400 különböző IP-ről próbálkoznak
- jelenleg valamivel több mint 1 napig tiltom ki az IP-t, növelhetném, de úgy gondolom ez nem jó megoldás
- kulcsot használok a belépésre és erős jelszavaim vannak

Ezeket találtam és a star-ok alapján az első lenne a nyerő, használja valaki?
- https://github.com/cowrie/cowrie
- https://github.com/skeeto/endlessh (köszi ibenny)
- https://github.com/jaksi/sshesame
- https://pypi.org/project/fake-ssh/
- https://github.com/fffaraz/fakessh
- https://github.com/cheeseandcereal/fake-ssh
- https://github.com/droberson/ssh-honeypot

Köszi!

Hi!

Kezdjük azzal, hogy "eddig működött". :-)

Szerveren Ubuntu, több porton figyelő OpenVPN szerver - portonként más-más VLAN-ba enged be-, cliensen Windows10 20H2 OpenVPN 2.5.0 client.

Az egyik portra történő csatlakozáskor úgy tűnik a TAP adapter nem kapja meg az IP-t, holott a logban - és a GUI-ban is - az látszik, hogy megkapja, sőt a routing is "lejön", de az ipconfig ezt mutatja:

====================

Unknown adapter OpenVPN TAP-Windows6:

   Connection-specific DNS Suffix  . :
   Default Gateway . . . . . . . . . :

route print
===========================================================================
Interface List
  6...8c 47 be 22 74 9d ......Realtek PCIe GbE Family Controller
 21...........................Wintun Userspace Tunnel
 19...00 ff af af 16 18 ......TAP-Windows Adapter V9
 11...28 cd c4 f4 a4 d7 ......Qualcomm QCA61x4A 802.11ac Wireless Adapter
 22...2a cd c4 f4 a4 d7 ......Microsoft Wi-Fi Direct Virtual Adapter
  3...3a cd c4 f4 a4 d7 ......Microsoft Wi-Fi Direct Virtual Adapter #2
 15...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
  7...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
  9...00 1e 10 1f 00 00 ......HUAWEI Mobile Connect - Network Card
  5...28 cd c4 f4 a4 d8 ......Bluetooth Device (Personal Area Network)
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
     192.168.31.0    255.255.255.0     192.168.17.9               13    281
     192.168.38.0    255.255.255.0     192.168.17.9               13    281
     192.168.39.0    255.255.255.0     192.168.17.9               13    281
[...]

======================

Csatlakozáskor ez a "gyanús" sor:

===========================

Thu Jan 21 10:14:06 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Thu Jan 21 10:14:06 2021 Route: Waiting for TUN/TAP interface to come up...

==============================

Na és amikor a configban kizárólag a portot írom át, akkor szépen csatlakozik,  IP rendben, routing rendben.

==========================

Unknown adapter OpenVPN TAP-Windows6:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.16.156
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

route print
===========================================================================
Interface List
  6...8c 47 be 22 74 9d ......Realtek PCIe GbE Family Controller
 21...........................Wintun Userspace Tunnel
 19...00 ff af af 16 18 ......TAP-Windows Adapter V9
 11...28 cd c4 f4 a4 d7 ......Qualcomm QCA61x4A 802.11ac Wireless Adapter
 22...2a cd c4 f4 a4 d7 ......Microsoft Wi-Fi Direct Virtual Adapter
  3...3a cd c4 f4 a4 d7 ......Microsoft Wi-Fi Direct Virtual Adapter #2
 15...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
  7...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
  9...00 1e 10 1f 00 00 ......HUAWEI Mobile Connect - Network Card
  5...28 cd c4 f4 a4 d8 ......Bluetooth Device (Personal Area Network)
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric

    192.168.1.101  255.255.255.255     192.168.16.9   192.168.16.156    281
    192.168.1.117  255.255.255.255     192.168.16.9   192.168.16.156    281
    192.168.1.181  255.255.255.255     192.168.16.9   192.168.16.156    281
      192.168.2.0    255.255.255.0     192.168.17.9   192.168.16.156    281
      192.168.2.0    255.255.255.0     192.168.16.9   192.168.16.156    281

=======================================

Természetesen linux cliensen ugyanezekkel a konfigokkal mindkét portra történő csatlakozás működik.

Amit eddig próbáltam - sikertelenül :-( :

- tűzfal, víruskereső kikapcsolása

- TAP, majd OpenVPN cliens újratelepítés

Régebben ez a hiba akkor jött elő, amikor a GUI nem rendszergazdaként futott, most ez is rendben.

Valakinek ötlete, javaslata?

Előre is köszönöm!

Több független szerver backblaze mentésénél is a mai nap hibákat kezdett dobálni a restic.

A backup lefut, majd az utána következő forget jelzi, hogy még zárolva van a repo. Egy check esetén azonban kiderül, hogy valami más a gond:

Remove(<lock/d43a67329c>) returned error, retrying after 822.534738ms: Delete: b2_download_file_by_name: 404: File with such name does not exist.

Ilyen hibaüzenetből van 10-20.

Vannak mentések, ahol előjön, vannak, ahol nem. Ti tapasztaltatok ilyet? Tudtok az okáról valamit?

Debian 10 alatt kellene elérnem egy távoli DELL szervert, amihez - ha jól tudom - iDarc adminisztrációs felület van.

Természetesen csak java 7 futtatja használhatóan, és a https hitelesítése érvénytelen (mint ez manapság már szokásos a szolgáltatóknál).

A 7-es JRE-t az oracle oldaláról töltöttem le, és az update-alternatives paranccsal be is állítottam a java és a javaws alternatívákat.

A terminált elindítva indul is a java 7, de mivel nem érvényes a certificate, leáll.

Ha a distro saját openjdk 11 verzióját használom, akkor elindul a java app, csak a billentyűzet nem használható. :(

A java 7 saját java.security fájljában is kikommenteztem a jdk.tls.disabledAlgorithms kezdetű sort. Ennek ellenére nem hajlandó futtatni a java appot.

Anélkül, hogy véleményezném most ezt a fajta szolgáltatást, hogyan érhetném el, hogy állíthatnám be, hogy az oracle java 7 akkor is futtassa az appot, ha az érvénytelen hitelesítésű https-ről származik?

Éjjel riasztott az Icinga 2, hogy egy hosttal baj van. Majd öt perc múlva már jött is a RECOVERY e-mail, hogy a szerver helyreállt. Kb egy órára rá, ugyanaz a szerver ismét elérhetetlenné vált, jött is az újabb ALERT e-mail. Öt perc múlva ismét helyreállt. Az icinga webes felületén zöld is lett a státusza, de RECOVERY e-mail értesítés már nem érkezett. Egy ideig még flip státuszban maradt a szerver, majd azóta is stabilan OK.

Megnézve az icinga naplóit, nem látom nyomát annak, miért nem küldte el a második RECOVERY e-mail-t. Debug logolás nem volt bekapcsolva. Most kapcsoltam notification debug-ot, de nem tudom, ez elég lesz-e egy hasonló ilyen esethez.

Megnézve az icinga szerverén futó exim naplóját, abban nem is szerepel a negyedik e-mail. Vagyis az icinga meg sem próbálta elküldeni a notification e-mailt. Egyébként több e-mail cím is van a contact groupban, egyikre sem ment ki a negyedik levél.

Ez ugyan nem akkora gáz, de mi van, ha egyszer ugyanez történik egy ALERT e-maillel?

Találkozott már valaki hasonló problémával? Netán tud is rá megoldást? Hogyan stabilizálható az icinga, hogy megbízható legyen? Vagy hogyan találhatom meg a hiba okát?

Megoldás: nem bug, feature