Quantumsoft Blog
Aktualności i praktyczne porady IT
Krótkie, konkretne wpisy o bezpieczeństwie, Microsoft 365, Windows Server, Azure, technologiach sieciowych i serwerowych oraz innych problemach, z którymi na co dzień mierzą się działy IT.
Skuteczne wykrywanie incydentów i nadużyć w domenie wymaga precyzyjnej konfiguracji audytu. Jest to kluczowe w kontekście bezpieczeństwa każdego systemu Windows/Active Directory, by umożliwiść wczesne wykrycie potencjalnego rekonesansu i późniejszgo ataku na infrastrukturę opartą o Windows Server. Poniżej przedstawiam wytyczne oparte na zaleceniach Microsoftu
Zasada 3‑2‑1 przez lata była prostym, a zarazem skutecznym sposobem na ochronę danych: należy utrzymywać trzy kopie danych na dwóch różnych nośnikach, z czego jedna kopia jest przechowywana poza siedzibą. Jednak w erze chmur i ransomware to podejście okazuje się niewystarczające. Ataki typu ransomware regularnie celują w infrastrukturę kopii zapasowych i potrafią zaszyfrować lub usunąć wszystkie kopie w sieci. Firmy przechowują dane w usługach SaaS, a backupy tworzone w tym samym środowisku chmurowym nie zapewniają niezależności. Utrzymanie redundancji bez separacji nie zapewnia odporności.
Dla wielu administratorów pojęcie Patch Tuesday jest codziennością, ale mniej doświadczeni użytkownicy mogą nie wiedzieć, skąd wziął się ten termin i dlaczego jest ważny. Patch Tuesday (dosłownie „wtorek poprawek”) to tradycyjny dzień, w którym Microsoft co miesiąc udostępnia zbiorczą paczkę aktualizacji bezpieczeństwa dla systemów Windows, Office, SQL Server czy Azure. Regularność tego cyklu pozwala planować wdrożenia i minimalizować ryzyko niezgodności.
Większość administratorów kończy konfigurację serwera plików na etapie: "Utwórz folder -> Udostępnij -> Mapuj dysk". To błąd. Domyślna konfiguracja udziałów sieciowych w Windows Server jest nastawiona na kompatybilność, a nie bezpieczeństwo. W efekcie, atakujący, który dostanie się do sieci, może swobodnie przeglądać strukturę katalogów, przechwytywać hashe haseł, a ransomware – szyfrować wszystko jak leci.
W lutym 2026 r. Microsoft zapowiedział trzyetapowy plan wycofania protokołu NTLM, który od lat 90. służył do uwierzytelniania w środowiskach Windows. Przyczyną są słabe mechanizmy kryptograficzne NTLM i podatność na ataki przechwycenia hashy (pass‑the‑hash), replay oraz man‑in‑the‑middle. W kolejnych wersjach Windows Server NTLM będzie domyślnie wyłączany, dlatego administratorzy muszą migrować usługi do nowocześniejszego Kerberosa. Ten artykuł jest uzupełnieniem naszego technicznego opracowania o fazach wycofania NTLM i szczegółach konfiguracji Kerberosa. W sposób bardziej przystępny wyjaśnia podstawy protokołu, jego zalety oraz najważniejsze dobre praktyki, na których powinni skupić się mniej doświadczeni administratorzy.
Instalujesz nową aplikację webową, uruchamiasz konsolę zarządzającą (np. antywirusa) albo konfigurujesz certyfikat SSL. Nagle pojawia się błąd: port 443 jest już w użyciu. Jako doświadczony administrator odpalasz konsolę i wpisujesz znane i lubiane polecenie, aby namierzyć winowajcę:
Get-Process -Id (Get-NetTCPConnection -LocalPort 443).OwningProcess
Zamiast oczekiwanej nazwy aplikacji, system wypluwa jedną, irytującą odpowiedź: System (PID 4).
Ślepy zaułek? Nie do końca. Dziś pokażę Ci, dlaczego Windows ukrywa przed Tobą tę informację i jak za pomocą jednego polecenia wyciągnąć ją na światło dzienne.
W marcu 2026 r. Microsoft ogłosił koniec wsparcia dla algorytmu RC4‑HMAC w protokole Kerberos. RC4 był stosowany od wielu lat dla kompatybilności wstecznej, lecz obecnie jest uważany za słaby. Firma wprowadza stopniowe wzmocnienie protokołu – zamiast RC4 domyślnym algorytmem stanie się AES128/AES256.
Wiedza z artykułu Cię zainteresowała a nie wiesz gdzie zacząć?
Chętnie rozwiniemy któreś z zagadnień.
Ocenimy szanse na wdrożenie i pomożemy je zrealizować jeżeli to będzie najlepszym rozwiązaniem dla Ciebie, lub wskażemy inny sposób realizacji.
Porozmawiajmy o podobnym projekcie