A

ge to proste, nowoczesne i bezpieczne narzędzie do szyfrowania plików oraz biblioteka języka Go. Charakteryzuje się małymi, jawnymi kluczami, brakiem opcji konfiguracyjnych i możliwościami kompozycji poleceń w stylu Unix. Program ten tworzy asymetryczną parę kluczy: publiczny i prywatny. Wersja publiczna jest używana do szyfrowania, a prywatna do odszyfrowania (plików, katalogów i wiadomości). Dla wygody age obsługuje również szyfrowanie za pomocą publicznych kluczy SSH oraz odszyfrowywaniu przy użyciu odpowiedniego pliku klucza prywatnego. Kilka przykładów zastosowania:

agresor@darkstar:~$ sudo apt install -y age
agresor@darkstar:~$ age-keygen | age -p > age-private.key
Public key: age1vvdj5yvk0psrz6vs5lrgqjew7h5vaep6rdtg9lwyt62x69ltu5esmpl2ad
Enter passphrase (leave empty to autogenerate a secure one):
age: using autogenerated passphrase "borrow-journey-define-exile-earth-win-cigar-yard-urge"

Tworzymy parę kluczy, z czego klucz prywatny będzie dodatkowo zaszyfrowany hasełem. Teraz możemy zaszyfrować plik nfsec_pl.txt otrzymanym kluczem publicznym:

agresor@darkstar:~$ age -o nfsec_pl.txt.age -r age1vvdj5yvk0...69ltu5esmpl2ad nfsec_pl.txt
agresor@darkstar:~$ head -3 nfsec_pl.txt.age
age-encryption.org/v1
-> X25519 Tlw8RQmWEXu7mjpBUJ1GNV2ZRuM5c0lc7++OT4Y+j24
xzwZGjRDJVQywki6tOmSaXIKjFXrg1+ycPVjtljF1es

Tak zaszyfrowany plik możemy odszyfrować za pomocą polecenia:

agresor@darkstar:~$ age -d -i age-private.key -o nfsec_pl.txt nfsec_pl.txt.age
Enter passphrase for identity file "age-private.key":

Ten sam proces (szyfrowania) możemy przeprowadzić za pomocą publicznego klucza SSH:

agresor@darkstar:~ $ age -R .ssh/id_rsa.pub nfsec_pl.txt > nfsec_pl.txt.age
agresor@darkstar:~ $ head -3 nfsec_pl.txt.age
age-encryption.org/v1
-> ssh-rsa x4o9pQ
2VKd5t82j0zjoO7PMt+xZKTxPEVAJSH/fvWWJYfHy+Q0jZkw01k6oGOXfq1BbDDE

A następnie odszyfrować go kluczem prywatnym SSH:

agresor@darkstar:~ $ age -d -i .ssh/id_rsa nfsec_pl.txt.age > nfsec_pl.txt

W ten sposób możemy bardzo prosto i szybko szyfrować wiadomości i pliki dla użytkowników, którzy zdecydowali się opublikować swoje klucza na profilu GitHub:

curl -s https://github.com/$login.keys | age -R - nfsec_pl.txt > nfsec_pl.txt.age

Więcej informacji: age encryption

K

onfiguracja SSH oprócz: zezwolenia wybranych użytkowników; wyłączenia / podkręcenia niektórych funkcji; zastanawiania się czy hasłem, czy kluczem i którym portem – przede wszystkim powinna się skupić na rodzajach algorytmów, które oferują nam bezpieczną, szyfrowaną transmisję. Od strony manualnej możemy skorzystać z dobrego przewodnika Mozilli lub zaprząc do tego automat, który podpowie nam, jakie algorytmy są już przestarzałe i nie powinny być już oferowane od strony serwera w naszej wersji:
[ czytaj całość… ]

Kolejny powód dlaczego nie należy pozostawiać niezablokowanego komputera.

[agresor@darkstar ~]$ security dump-keychain -d ~/Library/Keychains/login.keychain

Jeśli po wydaniu powyższego polecenia wszystkie nasze zapisane hasła i certyfikaty w systemie zaczną pojawiać się na ekranie – oznacza to, że mamy zbyt luźną politykę jeśli chodzi o Dostęp do pęku kluczy (ang. Keychain Access). Możemy zmienić to poprzez polecenie:

[agresor@darkstar ~]$ security set-keychain-settings -lut 60

Spowoduje ono blokadę pęku kluczy, za każdym razem, gdy komputer wejdzie w stan uśpienia oraz po minucie nie korzystania z danego pęku kluczy.

Więcej informacji: man security

P

rzedstawiony hack jest tłumaczeniem „Quick Logins with ssh Client keys” z książki „Linux Servers Hacks” autorstwa Rob’a Flickenger’a udostępnionym on-line (Hack #66) na stronie http://hacks.oreilly.com. Do tłumaczenia zostało dodane także parę informacji od tłumacza.
[ czytaj całość… ]

W

szyscy używamy / korzystamy z połączeń SSH. Dzięki temu protokołowi jesteśmy w stanie w bezpieczny sposób łączyć się z inną maszyną i wykonywać na niej w zdalny sposób komendy. Jesteśmy także w stanie przesyłać bezpiecznie pliki (SCP), a nawet tworzyć o niebo bezpieczniejszą alternatywę dla FTP (RSSH + SCPOnly), czy tworzyć szyfrowane tunele itp. Jednak wiele osób nie zdaje sobie sprawy z tego, iż chociaż SSH szyfruje przesyłane dane to dla atakującego wcale nie jest problemem podsłuchać Naszą sesję. Podsłuchiwanie to z powodu szyfrowania sesji przybiera trochę inny kształt: atakujący może symulować serwer, z którym chcemy się połączyć. Dzięki symulowaniu serwera będzie w stanie Nas „podsłuchiwać”, ponieważ chociaż dane są szyfrowane to de fakto będą one przechodziły (lub adekwatnie od intencji atakującego — dochodziły) przez „niepowołaną” maszynę. Jest to tzw. atak typu Man-In-The-Middle. Artykuł ten ma na celu przybliżenie sposobu ochrony Naszej szyfrowanej sesji SSH dzięki kluczom identyfikacyjnym serwera.
[ czytaj całość… ]