Skip to Content

IT nieuczesane.
category

Category: security

krótkie URLe…

…zniknęły.

nie wczoraj, a pół roq temu, ale może komuś umknęło to tak, jak mi. chodzi o skrócone adresy URL, które dostępne były w różnych serwisach typu OneDrive czy Google Maps. z jednej strony co za różnica czy adres jest skrócony, przecież i tak się go nie uczymy na pamięć, tylko wysyłamy mailem czy innym medium, z drugiej strony miało to ciekawy efekt psychologiczny – taki krótki adres nie straszy. kiedy widzi się długi ciąg znaków w adresie, który mamy kliknąć to budzi niepoqj, w przeciwieństwie do krótkiego, zwięzłego. no i mimo wszystko, rzadko-bo-rzadko, ale czasem taki adres trzeba przedyktować przez telefon. dziwne przypadki się zdarzają.

zastanawiałem się, czemu serwisy Google czy MS wycofały tą usługę i okazuje się, że chodzi o bezpieczeństwo. jeśli udostępnialiście kiedyś pliki lub lokalizacje z usługi chmurowej, to wiecie, że całe bezpieczeństwo opiera się w właśnie na linq – w nim zawarty jest token, upoważniający do edycji lub odczytu pliq. to samo w sobie nie jest jeszcze tragedią, bo wysyłając link mailem musimy pamiętać, że może kiedyś trafić ‚gdziekolwiek’ i doqment/lokalizacja będzie mógł być pobrany lub edytowany przez przypadkową osobę. większym problemem był fakt, że token w zawartym linq, oraz uporządkowana struktura serwisu pozwala na dostęp do innych danych.

całość, wraz z raportem na podstawie odkodowanych linqw można znaleźć w tym artyqle a dla leniwych, skrócona wersja przykładowych scenariuszy ataq:

  • dla OneDrive, znalezienie katalogu z zapisem, umożliwia łatwe wstrzyknięcie wirusa/malware na komputery użytkownika, ponieważ usługa ta daje możliwość synchronizacji katalogu, która jest powszechnie wykorzystywana. statystyki z badania pokazały, że aż 7% katalogów dawało możliwość zapisu [SIC!]
  • dla GMaps, wykrycie zapisanych przez użytkownika miejsc, daje możliwość bardzo dokładnego profilowania – w skrócie dostęp do informacji kim jesteśmy, gdzie bywamy, a nawet z kim się spotykamy – co daje podstawy do bardzo dobrze sprofilowanego ataku – czy to elektronicznego, czy IRL.

to w sumie oczywiste, ale przypomina, jak olbrzymia odpowiedzialność spoczywa na dostawcach usług globalnych. taki mały niuansik – ot, skrócony link…

w epoce ‚chmury’ i wszechobecnego ułatwiania sobie życia, czasem zapominamy jak niebezpieczne jest udostępnianie danych. nie jestem zwolennikiem paranoidalnego odcinania się od usług… bo są wygodne. i dużo traci się na blokowaniu wszelkich ciasteczek, korzystania z map, backupu zdjęć czy trzymania doqmentów w chmurze. poszukiwanie niszowych rozwiązań, które są rzadziej kierunkiem ataq ze względu na mniejszą popularność, może być jakimś rozwiązaniem. ale traci się wtedy na integracji – decydując się na usługi jednego dostawcy, mamy tzw. ‚suite’ czyli cały pakiet usług, pomiędzy którymi łatwo wymienia się dane, co daje olbrzymią elastyczność i wygodę.

wybór należy do Ciebie – byle świadomy!

eN.

SecureString

Windows_PowerShell_iconscenariusz użycia

używanie SecureStringów w PS jest poniekąd wymuszone – w taki sposób przechowywane są hasła, np. w credentialsach:

SecureString przydaje się do przechowywania haseł, używanych w skryptach – np. skrypt do automatycznego podpięcia licencji office365, który wymaga podania credsów użytkownika z uprawnieniami co najmniej ‚User Manager’. można hasło zapisać w pliq jako SS a potem wewnątrz skryptu je odczytać i użyć do złożenia credsów:

bezpieczeństwo SS

rodzą się natychmiast pytania o bezpieczeństwo SecureString – czy takie hasło da się odszyfrować i jak łatwo? hasło jest szyfrowane kluczem, który generowany jest na podstawie hasła użytkownika, a masterkey jest przechowywany na komputerze lokalnym. odpowiedzialne jest za to DPAPI – tutaj znajdziecie więcej informacji. klucz jest przechowywany w $env:USERPROFILE\Application Data\Microsoft\Protect\<GUID>. w efekcie

  • plik jest nie do odczytania na innej maszynie
  • plik jest nie do odczytania przez innego użytkownika

czyli nic da ‚wykradzenie’ pliq lub użycie go w kontexcie innego użytkownika.

są potencjalnie metody potrafiące złamać klucz [np. hawkeye inject], ale nie znalazłem praktycznego opisu i na pewno nie są to metody na poziomie script kiddie. można zatem uznać, że jest to świetne narzędzie dla skryptów, które wymagają podania hasła.

addendum

na koniec – jak  odczytać hasło zapisane jako SS? podam dwie metody – dla devów i dla opsów (;

dla devów:

dla opsów:

po zbudowaniu obiektu credential z wcześniejszego przykładu, mamy zmienną $creds

eN.

Obronić się przed MiTM

Minęło wiele lat od kiedy napisałem tu ostatni post a do tego temat na (re)debiut już nie jest gorący. Chociaż z drugiej strony nie zdążył jeszcze wystygnąć i w każdej chwili może ponownie wybuchnąć. Ale do rzeczy. Dziesięć miesięcy temu okazało się, że przez pół roku Lenovo raczyło swoich użytkowników certyfikatami umożliwiającymi ataki MiTM (https://www.us-cert.gov/ncas/alerts/TA15-051A). Wiadomo, generalne oburzenie, Chińczycy nas śledzą, na pewno to sprawa służb, teorie spiskowe  i w ogóle koniec świata. Szczerze mówiąc temat spłynął po mnie jak po kaczce, sprawdziłem swój tablet (kupiony w przypływie weny wracając z baru po spotkaniu świąteczno noworoczny) i zapomniałem o temacie. Potem gdzieś pojawił się problem z Dell System Detect i zdalnym wywołaniem kodu, który został załatany przed opublikowaniem dziury (http://tomforb.es/dell-system-detect-rce-vulnerability). To ruszyło mnie trochę bardziej, sprawdzanie kto ma zainstalowane oprogramowanie i usunięcie starych wersji okazało się nie być trzema kliknięciami ale koniec końców temat załatwiony i systemy załatane w kilka godzin.

Niby dwie z pozoru niepowiązane rzeczy a jednak ostatnio okazało się, że niektórzy wolą się uczyć na własnych błędach zamiast na cudzych i Dell obdarzył nas kolejną serią serią wpadek (http://joenord.blogspot.in/2015/11/new-dell-computer-comes-with-edellroot.html,http://www.kb.cert.org/vuls/id/925497) instalując razem ze swoim oprogramowaniem certyfikaty w Trusted Root razem z ich kluczami prywatnymi. Do tej pory jest jeszcze prawie ok. Oprogramowanie potrzebuje coś samo podpisać żeby system się nie burzył przy instalacji, certyfikat jest oznaczony jako nieeskportowalny. Nie jest najgorzej, w końcu to narzędzie systemowe a nie aplikacja pokazujące  reklamy jak w przypadku Lenovo i jesteśmy zadowoleni dopóki nie zauważymy, że nasz kolega ma ten sam certyfikat a ktoś nam powie, że klucz prywatny można wyeksportować na przykład za pomocą mimikatz.

W głowie zaczynają układać się klocki pokazujące bardzo prosty scenariusz ataku:

  1. Eksportujemy certyfikat (patrz link powyżej)
  2. Stawiamy darmowe WiFi z SSID Starbunio i idziemy w pobliże kawiarni
  3. Czekamy na kogoś z laptopem Della kto podłączy się do naszego WiFi i otworzy stronę, którą warto przechwycić
  4. Zmieniamy SSID i miejsce bo w naszym pierwotnym celu są same błyszczące Maci
  5. Bingo, złapaliśmy klienta otwierającego stronę banku. Dla niego wszystko wygląda w porządku, jest https, jest zielona kłódeczka a przeglądarka nie ma żadnych podejrzeń. Dopiero jak gość będzie bardzo dociekliwy to okaże się, że certyfikat uwierzytelniający bank wystawił Dell a nie Verisign. My sobie po drodze cały ruch odszyfrowujemy, podmieniamy numery kont (bo kto to sprawdza w smssach) i jesteśmy szczęśliwi.

Problem pojawia się kiedy zdamy sobie sprawę, że nie tylko my możemy tak zrobić a nasi użytkownicy na pewno nie sprawdzają za każdym razem kto wystawił certyfikat stronie i możemy się założyć, że kwestią czasu jest kiedy wypłyną dane z naszej firmy albo ktoś dostanie karnego na Facebook’u. A co jeśli nie tylko Dell i Lenovo mają problem z certyfikatami? Będziemy czekać na białe kapelusze aż opublikują artykuły i łatać za każdym razem licząc na to, że czarne kapelusze nie wkroczyły jeszcze do akcji? A może pójdziemy o krok dalej i będziemy bardziej proaktywni sprawdzając czy mamy jakiekolwiek podejrzane certyfikaty na naszych komputerach?

Teoria mówi, że żaden certyfikat znajdujący się w Trusted Root Certification Authorities nie powinien mieć klucza prywatnego. Gdzieś daleko od nas jest CA a my jemu ufamy ponieważ znamy klucz publiczny CA pasujący do klucza prywatnego używanego do podpisywania certyfikatów. Tyle teorii, praktyka okazuje się być trochę bardziej brutalna ale o tym później.

Kiedy mamy problem z pomocą przychodzi korporacyjna nowomowa i nagle problem staje się on wyzwaniem, a kto nie lubi wyzwań? Do tego jeszcze można zaprzęgnąć lubianego PowerShell i System Center lubiane … inaczej ;)

Zaczynamy od kawałka banalnego kodu:

Który przeleci nam po wszystkich dostępnych certificates stores wyłączając z tego:

  • My – certyfikaty użytkownika/komputera
  • Remote Desktop – to chyba nie wymaga tłumaczenia
  • SMS – certyfikaty używane przez klienta SCCM

w tym kroku można się pokusić jeszcze o wyłączenie innych rzeczy (np. certyfikatów klienta SCOM) albo zamianę

na

żeby zaglądać tylko do Trusted Roots. Na razie trzymajmy się pierwszej wersji żeby zobaczyć co się w ogóle dzieje.

 

Jak już wiemy jakie mamy Certificates Stores to warto do nich zajrzeć i zobaczyć jakie mamy certyfikaty z kluczami prywatnymi

żeby uniknąć szumu wywalamy:

  • certyfikat Fiddlera – jego celem jest robienie MiTM i osoby mające go na komputerach wiedzą co robią
  • certyfikat zawierający z temacie nazwę hosta – tak to ciągle jest niebezpieczne ale wiemy, że ten certyfikat mamy tylko my i ewentualnie ktoś kto go nam wygenerował a nie cały internet. Takie świństwa podrzuca na przykład Skype ze skonfigurowanym Click to call

Reszta to proste działania mające na celu sprawdzenia czy mamy jakiekolwiek podejrzane certyfikaty i podanie ich listę lub potwierdzenie, że komputer jest ok.

 

Kiedy mamy już PowerShell to warto byłoby uruchomić go na wszystkich komputerach i sprawdzić kto ma coś podejrzanego na swojej maszynie. Fajnie byłoby też aby sprawdzanie odbywało się cyklicznie i informowało nas kiedy jest coś nie tak. Tutaj przydaje się SCCM i Compliance Settings.

Tworzymy Configuration Item uruchamiające skrypt i sprawdzające co jest na wyjściu

Configuration item

2015-12-08_21-47-13

Compliance Rules

2015-12-08_21-47-35

Compliance Rule

Potem robimy Configuration Baseline, dodajemy do niego nasz Configuration Item i robimy Deploy na kolekcje użytkowników oraz na kolekcje komputerów (odpowiednio All Users i All Systems). Ostatnie może się wydać trochę dziwne ale jest potrzebne żeby sprawdzić zarówno co mają użytkownicy jak i konto local system. Configuration baseline uruchomiony w kontekście systemu (Deploy na kolekcję komputerów) nie może zajrzeć do certyfikatów użytkowników bo te są trzymane w profilach*, a użytkownicy nie mogą zobaczyć jakie certyfikaty ma konto local system, za to zarówno użytkownik jak i local system mogą sprawdzić zawartość Certificate Store: Local Machine.

*-to nie jest do końca prawda bo można podmontować Hive i dekodować certyfikaty ale są na to prostsze sposoby

Jakby ktoś się pokusił dodatkowo o Remediation script żeby usuwać podejrzane certyfikaty to warto pamiętać, że Local System będzie mógł usuwać certyfikaty zarówno swoje jak o Local Machine a użytkownik będzie mógł usuwać wyłącznie swoje.

Na koniec pozostaje skonfigurowanie alertów, wysyłanie ich do SCOM i workflow do obsługi zdarzeń ale to już temat na osobny wpis.

 

|Security use case

Kilka dni temu na blogu zaufanatrzeciastrona.pl (całkiem niezły site) pojawił sie taki opis ataku:
https://zaufanatrzeciastrona.pl/post/uwaga-na-nowy-sprytny-atak-na-polskich-internautow/

Impreza zaczeła się, gdy do netu wypłynęło, że atak sie powiódł, do tego stopnia, że jego wynik, dość wnikliwie opisany na wspomnianym blogu, został usunięty po niecałych 24h od ukazania sie:
https://zaufanatrzeciastrona.pl/post/ogromny-wyciek-danych-duzej-polskiej-kancelarii-skutkiem-niedawnych-atakow/

ale mamy inne opisy:
http://cyberprzestepczosc.pl/2015/mamy-pierwszy-wyciek-danych-z-kancelarii-adwokackiej/
http://serwisy.gazetaprawna.pl/orzeczenia/artykuly/892135,znana-kancelaria-prawna-padla-ofiara-hakerow-wyciekly-dane.html

Temat okazał sie dość gruby, bo do klientów kancelarii, która stała sie jego celem należeli min.:  Bank DnB Nord, IBM, Kraft Foods, PGNiG, Raiffeisen, Telekomunikacja Polska, Unilever, KGHM Polska Miedź, ITI  – reszta klietntów tutaj: https://web.archive.org/web/20150717035609/http://dt.com.pl/index.php?mod=klienci&lang=pl

Gównoburzy w necie dodaje smaczku fakt (no… wyczytałem ten fakt w komentarzach), że wspomniana kancelaria reprezentowała tzw.: „frankowiczów” w procesie z bankami.
Tutaj można sobie poczytać w komciach:  https://zaufanatrzeciastrona.pl/post/wiesz-kto-wlamal-sie-kancelarii-100-000-pln-nagrody-czeka

Dla mnie ważne jest, że to pierwszy przypadek, gdy klienci sami widzą  że te hakiery, to rzeczywiście mogą napsuć krwi i rozpoczyna się dyskusja o podniesieniu poziomu bezpieczeństwa.  Chodź należy też zauważyć, ze wspomniany wyżej atak był dość precyzyjnie skierowany, a to nie pozostawia wiele szans na  obrone.
Ten przypadek może służyć za argument w dyskusji z biznesem, żeby wysupłać pare groszy więcej na ogólnie pojęte bezpieczeństwo.

właściciel plików: administrators

UAC_insigniaprodukty eMeSa wykazują się niesamowitą inkoherencją. z jednej strony  genialnością i pomysłowością, po czym trafia się na opcje [lub ich brak] lub mechanizmy, które zaburzają cały obraz. jednym z najbardziej niedopracowanych i kontrowersyjnych mechanizmów jest UAC – User Account Control. dość często na niego przeklinam i trafiłem na kolejny argument, świadczący o tym, że był wymyślany na złość administratorom. a tak na prawdę będzie to połączenie kilq bezsensownych i niewyjaśnialnych zachować systemu.

chodzi konkretnie o własność [ownership] plików zakładanych przez użytkownika, który należy do grupy administratorów lokalnych. czyli praktycznie zawsze – bo któż inny zarządza serwerem? pliki w takim przypadq mają jako właściciela wpisywane… ‚Administrators’ – zamiast konkretnej osoby. dla windows 2oo3 dało się to wyregulować polisą GPO:

„Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\System objects: Default owner for objects created by members of the Administrators group”

problem polega na tym, że takiego ustawienia nie ma dla systemów w2k8+. w taki czy inny sposób polisę można przywrócić w interfejsie, ale nie ma to znaczenia, ponieważ systemy jej nie respektują. a jest tak ponieważ zespół wdrażający UAC uważał, że jest tak samo genialny i nieomylny jak ten, który zarządził, że metrointerfejs będzie standardem wszędzie, zawsze i bezwzględnie, łącznie z serwerami. można znaleźć KB, które opisuje, że to właśnie ten wspaniały mechanizm zapewnia, że uprawnienia będą automatycznie nadawane na konkretną osobę, ponieważ nie ma tokena administratora.

wszystko by się nawet kleiło, gdyby nie jeden podstawowy fakt – ktoś, kto to wymyślał raczej nigdy nie administrował serwerem pliqw, pozostając w jakiejś sferze teorii. w ogóle poruszanie się po zarządzanym serwerze jest mało wykonalne bez uprawnień admina, więc nie ma innego wyjścia jak UAC obejść – czy to odpalając jakiegoś file managera w trybie ‚run as administrator’, czy to po prostu wyłączając cały mechanizm. pozostaje jeszcze jeden opisywany radośnie przypadek – UAC nie działa przy operacjach zdalnych, przez sieć, więc tu też zawsze będzie ‚owner:administrators’.

jak to obejść? jedyny sposób jaki znam, to utworzenie grupy, która będzie miała pełne uprawnienia do wszystkich pliqw, ale nie będzie w grupie adminów. takie to trochę naciągane, mało wygodne i zastanawiam się, czy kiedykolwiek widziałem zastosowane w praktyce? uważam, że to jest poważne niedociągnięcie w bezpieczeństwie, ponieważ nie daje łatwej metody sprawdzenia kto dany plik/katalog założył. oczywiście, że ownera da się zmienić, więc można polemizować ‚jakież to tam zabezpieczenie’, jednak z doświadczenia mogę powiedzieć – w większości przypadqw poziom wiedzy, ignorancja i lenistwo są na tyle powszechne, że bardzo podstawowe mechanizmy wystarczają aby odpowiedzieć na podstawowe pytania. a przeciw tym na prawdę dobrym, działającym z premedytacją i tak ciężko coś przeciwdziałać. wielokrotnie też miałem przypadek, kiedy nie chodziło o bezpieczeństwo sensus stricte a po prostu zwykłe wyjaśnienie – ‚kto ten katalog/plik utworzył?’.

eN.

 

Zły to świat…

Wiecie doskonale, że zestrzelono samolot pasażerski…oczywiście w takich sytuacjach następuje natychmiastowy szaber kart kredytowych z rozrzuconego bagażu i ciał ofiar. No i to jakoś jeszcze, ledwo bo ledwo, ale mieści się w mojej głowie…To natomiast to, co się dzieje później już przechodzi wszelkie granice przyzwoitości.

Cytuję za Niebezpiecznik.pl

„…W przypadku MH17 ataki phishing ułatwiają pełne dane wszystkich pasażerów lotu MH17, które zostały opublikowane przez Malezyjskie linie lotnicze. Dzięki nim phisherzy mogą odnaleźć rodziny ofiar w mediach społecznościowych i rozpocząć ukierunkowane ataki (np. podając się za urzędników, wyciągając dodatkowe dane pod pretekstem zasiłków pogrzebowych lub wyłudzając fundusze pod pretekstem opłat dotyczących organizacji pochówku/transportu na miejsce katastrofy)…”

raport uprawnień w AD

podczas audytu AD warto przejrzeć gdzie, kto i co  może. pisałem jakieś skrypty i inne wynalazki, ale są narzędzia, które można zassać bez napocenia się aż tak bardzo. dwa z nich to:

  • dla tych, którzy chcą sobie tylko pooglądać – LIZA. zaletą jest interfejs pozwalający chodzić sobie po drzewq. jednak do audytów jest niezbyt przydatny – nie filtruje defaultSecurityDescriptors, co znacząco utrudnia wykrycie anomalii.. no i nie ma exportu. niewątpliwie tool bardziej administratorski do zapytań typu: „gdzie ma dostęp grupa G?„.
  • fajniejszy jest IMHO ten oto skrypcik w PS. ma wszystko to, co jest potrzebne do analizy – tworzy raporty html/csv, filtruje co trzeba, no i jest w powershellu więc można sobie dokonywać modyfikacji bez konieczności visual studio (;

eN.

Odrobina prywatności na codzień

Temat PRISM powoli się przewala, choć najprawdopodobniej to tylko wierzchołek góry lodowej. Ja trochę się poddałem, bo po kilku latach wykorzystania własnych narzędzi do synchronizacji telefonów, stawiania serwerów do tego celu i ogólnie z góry przegranej walki o prywatność przez przypadek znychronizowałem wszystkie moje skrupulatnie chronione kontakty telefoniczne z kontem gmaila i cała prywatność w pizduuu…

Dla dociekliwych stronka https://prism-break.org przedstawiająca wszelkie „darmowe”, „wolne”, „chroniące prywatność” narzędzia. Ja już chyba jestem za stary na używanie TOR’ów w codziennym życiu, a na forach nie hejtuje, wiec potulnie korzystam z chroma….  ale może ktoś skorzysta z wyszukiwarek mających zastąpić googla… powodzenia.

Windows 8.1 z reklamami

Jak zwykle Microsoft nie zawodzi w dostarczaniu tematów do pisania.

Ostatni news z teamu Windowsa jest co najmniej niepokojący – otóż w Win 8.1 mają być serwowane reklamy – mają one być integralną częścią systemu.

I nie byłoby to dziwne, w sumie Google serwuje reklamy w Androidzie, Ubuntu również – z tym, że te dwa systemy są darmowe – jest to pewien rodzaj układu – my dajemy wam system za darmo w zamian serwujemy reklamy.

W przypadku Windowsa sytuacja jest zupełnie inna – to produkt komercyjny za który się płaci – i to nie mało, z mi znanych popularnych systemów operacyjnych jest to najdroższy system operacyjny na rynku: http://windows.microsoft.com/pl-pl/windows/buy

Ktoś kto płaci taką kwotę za goły system operacyjny ma prawo oczekiwać, że to co dostaje będzie ad-free – a tutaj.. rozczarowanie.. chociaż – może MS zrobi Win 8 Premium – bez reklam za cenę odpowiednio jeszcze wyższą.

Teraz druga strona medalu – skoro reklamy mają być serwowane w lokalnych wynikach wyszukiwania to jak np będziemy chcieli odnaleźć na naszym lokalnym dysku rozebrane zdjęcia swojej dziewczyny której kiedyś zrobiliśmy takie fotki, to czy teraz, wraz z Windowsem 8.1, dostaniemy reklamy spersonalizowane np innych rozebranych dziewczyn w twojej okolicy? Co z prywatnością? Wszyscy przecież wiemy, że MS skanuje np prywatne foldery na Skydrive (http://www.neowin.net/news/microsofts-ban-of-nudity-on-skydrive-questioned) – czy teraz będzie również skanował twój osobisty i prywatny komputer by dopasować reklamy?

http://community.bingads.microsoft.com/ads/en/bingads/b/blog/archive/2013/07/02/new-search-ad-experiences-within-windows-8-1.aspx

PKI – a nie mówiłem…?

ROTFLMAO – tak można podsumować wtopę, jaką zaliczył eMeS w ten weekend. a w zasadzie od piątq. cała chmura Azure wyparowała. dosłownie *cała*. od usług komercyjnych, darmowych, xbox… a wszystko przez… nieodświeżony certyfikat!

o tym, że PKI jest sztuką zanikającą i dla większości wdrożeń nazwa “PKI” jest mocno na wyrost, pisałem całkiem niedawno. ale to co się wydarzyło ciężko nawet komentować, więc zamiast się nabijać kilka wniosqw dla nas wszystkich:

  • CERTYFIKATY SĄ WAŻNE. jak widać – jeden zły cert i cała wielka machina może zdechnąć.
  • to, że nie dzieje się tak w innych firmach wynika z faktu, że każdy zna trywialim “bezpieczeństwo jest bardzo ważne/najważniejsze” ale środowisko konfiguruje się przeciwnie. ponieważ niewiele osób certyfikaty rozumie, aby sobie nie utrudniać życia, wszystko konfiguruje się tak, żeby “niewadziły”. czyli używa się self-signów, wyłącza się weryfikację CRL, pozwala się na połączenia pomimo braku poprawnej walidacji itd. czyli jakiś cert jest, jakieś szyfrowanie jest i wszyscy skaczą szczęśliwi że mają PKI i super bezpieczeństwo.
  • w Windows od zawsze brakowało automatu, przypominającego o wygasającym certyfikacie. taka funkcjonalność została dodana – AFAIR w Vista, jednak trzeba się lokalnie zalogować na serwer/stację, aby komunikat zobaczyć. tam, gdzie PKI jest istotne – jak np. główny cert firmy czy jakiejś aplikacji Web – admin powinien od razu wrzucić jakieś przypomnienie do kalendarza…

zamiast ustawiać przypomnienia na konkretne daty, co jest mało elastyczne z 1ooo powodów, warto byłoby zrobić coś bardziej uniwersalnego. na szybko – skrypt, który sprawdza wszystkie certy w computerMY i jeśli data jest powżej 6o% czasu życia, wysyła maila z informacją. skrypt można by wrzucić do do schedulera na serwerach. trzeba będzie nad tym pomyśleć…

eN.