Skip to Content

IT nieuczesane.
archive

> Monthly Archives: Lipiec 2016

logowanie na szybko – commandlet defaults

Windows_PowerShell_icondobrze jest dodawać jakieś logi do skryptu. można sobie ułatwić to zadanie na wiele sposobów, ale chciałem dorzucić jeszcze jeden, który może przydać się przy innych scenariuszach, jeśli tylko często wykonuje się jakieś polecenie z takimi samymi wartościami parametrów.

jeśli logowanie robimy przekierowując przy pomocy out-file to co chwila będziemy wpisywać:

niby nie dużo, ale czemu nie skrócić tego zapisu? można ustawić standardowe wartości parametrów dla wszystkich commandletów. robi się przy pomocy zmiennej $PSDefaultParameterValues, a w praktyce wygląda to np. tak:

eN.

nazwa katalogu ‚calendar’

exchange-logoniby trywialne… znalazłem kilka rozwiązań, ale żadne mi nie odpowiadało. to moje:

eN.

prawdziwy PS guru

https://geekeefy.wordpress.com/

eN.

hack the hash – master level

Windows_PowerShell_iconpoprzedni konqrs okazał się zbyt łatwy. no to kto będzie prawdziwym cwaniakiem i rozkmini na tym poziomie? tym razem trochę wiedzy o:

  • rekurencji
  • zakresach zmiennych
  • praktyka
  • i kolejna zagadka (;

poprzedni wpis zainspirowany został podczas poprawiania skryptu.. czy też pisania go od nowa, który gdzieś tam wewnątrz miał funkcję budującą listę użytkowników grupy distribution:

jak widać jest to rekursywne zapytanie, w wersji ‚czyste zło’. zło, które zostało wskazane w odpowiedzi przez bula – tak na prawdę funkcja nie zwraca jednej zmiennej, tylko całą serię zagnieżdżonych zmiennych. zwróćcie uwagę, że wewnątrz funkcji jest deklaracja ‚$members=@()’ – czyli przy każdym kolejnym zagnieżdżeniu tworzy się nowy ‚$members’. w efekcie, nie dość, że technicznie nie ma jednego wyniq a seria wyniqw, to jeśli osoba należy do wielu grup, pojawi się wiele razy. jeśli okaże się, że grupy są gdzieś zapętlone, co przy skomplikowanej strukturze może się wydarzyć, to skrypt będzie leciał w nieskończoność [grupa A należy do grupy B, B do C, C do A – pętelka. AD pozwala nawet na A do B i B do A – nie ma tutaj weryfikacji].

rekursja jest również zła ze względu na obsługę pamięci i możliwość przepełnienia stosu. to trochę zabawne [i frustrujące] ale na pierwszym roq, na programowaniu uczono mnie rekurencji. potrzebowałem duuużo czasu i dobrego przykładu aż w końcu zrozumiałem. bo jak mówi stare przysłowie – ‚rekurencję zrozumiał ten, kto zrozumiał rekurencję‚. a jak już zrozumiałem, to ten sam wykładowca [Ś.P. prof. Bielecki] poświęcił następny semestr na wyjaśnianiu czemu rekurencja jest zła, czemu należy jej unikać i jak z niej wychodzić… w skrócie – nad wywołaniem rekurencyjnym na prawdę trudno zapanować, chyba że ktoś umie myśleć jak implementacja zagnieżdżonego stosu.

anyway… najprostszą metodą, jest po prostu wyrzucenie zmiennej do wspólnego zakresu [scope]. zmienne mają swoje ‚skołpy’, co najlepiej widać właśnie przy rekursji. ale w prostym przykładzie:

output to: 2,1 . wewnątrz funkcji ‚test’ są dwie zmienne $a – ta wewnątrz funkcji i ta zadeklarowana na poziomie skryptu. słowa ‚globalnie’ unikam świadomie, ponieważ są trzy podstawowe poziomy: global, script, local. więcej tutaj.

fajnym testem rekursji+zakresu jest taki przykład:

co wyświetli się na ekranie? spróbuj wymyślić, odpal kod, sprawdź… jeśli nie jesteś zaskoczony – to jesteś unikatem, który na prawdę zajebiście rozumie działanie stosu. ale to nie była końcowa zagadka. do tego jeszcze dojdę.

…. a nie będę pisał na razie dalszej części. zostawię w tym miejscu bo tłumacząc zepsuję zabawę, a dzięki temu ilość zagadek się zwiększy q:

czyli kolejna zagadka i kontynuacja przeróbki skryptu – jakoś na dniach ^^

hef fan

eN.

 

hack the hash

taki mały konqrs. jest sobie hash-tablica:

$a=@{}

cechą hashtable aka tablicy słownikowej jest to, że klucze w niej są unikalne – stąd nazwa ‚słownikowa’. przykład:

przy próbie dodania drugiego klucza o tej samej nazwie, dostajemy błąd. jasne.

no to teraz taki hack the hash:

i okazuje się, że są dwa klucze o tej samej nazwie!

pytanie konqrsowe – jak to możliwe? (:

odpowiedź… jak mi się przypomni q:

eN.

get-MACAddressVendor

Windows_PowerShell_iconadresy MAC to tzw. OUIs – Organizationally Unique Identifier przyznawane przez IEEE. wszystkie można ściągnąć w postaci pliq textowego (1oMB). w związq z tym skrypt, który odpytuje się o MACa może albo wykorzystać jakieś query dostępne w necie, albo ściągną bazę lokalnie i operować na lokalnym pliq.

plik można ściągnąć na kilka sposób. w tym przypadq invoke-webRequest się wywala ze względu na timeout [duża wielkość pliq]. można zmienić timeout, można oprogramować metodę [System.Net.WebClient] … a można wykorzystać BITS.

poniżej prosty skrypcik, do weryfikacji MAC vendor, po uprzednim zassaniu oui.txt lokalnie. to na co warto zwrócić uwagę – to alternatywny sposób na pobieranie pliqw z netu, oraz parametr ‚context’ dla select-string.

get-MACAddressVendor.ps1

eN.

 

 

what-is-my-ip – kontunuacja

Windows_PowerShell_iconpo  komentarzach na FB, zamieszczam prosty skrypt, który pozwala odpytać dwóch różnych stron – whatsmyipaddress, API, które zwraca czysty adres, ale ponieważ:

You may programmatically query that server but limit queries to no more than once per five minutes and include an appropriate user agent that will allow us to contact you if needed

dodałem starą metodę przegrzebującą się przez HTML.

get-ExternalIP.ps1

eN.

mała-wielka zmiana. MS16-072

chaoswyszła ostatnio poprawka, która zabezpiecza przed pewnymi scenariuszami MitM attacks. mniejsza-o-większość, szczegóły można doczytać na technecie, a ja chciałem się sqpić nad pewną drobną konsekwencją, która może sporo namieszać.

po zainstalowaniu tej poprawki, przestają działać te polisy, które filtrowane są na podstawie uprawnień dla poszczególnych obiektów, i nie posiadają dodanego ‚authenticated users: Read’ . w efekcie po wylistowaniu gpresult, pojawia się komunikat: ‚not applied (unknown)’ .

oczywiście – wedle ‚best practices’ nie powinno się nigdy zdejmować tego uprawnienia, a tylko wyrzucać ‚apply’, niemniej nigdy nie stanowiło to problemu.

widziałem już różne dziwne metody stosowania GPO u klientów – tak dziwne, że patrzyłem i nie wierzyłem, że można coś tak dziwnego wymyślić. efekt tego, że jakiś admin-samouk zaczął coś w pokrętny sposób wdrażać, a potem trzeba to było kontynuować, bo oczywiście posprzątanie to ryzyko i chaos. w takim środowisq, ta mała zmiana, będzie miała olbrzymi wpływ. dotknęło to również środowiska jednego z obecnych klientów, gdzie ktoś dzięki dziwnemu zestawowi uprawnień wdrożył polisy terminalowe w zupełnie odwrotny sposób – zamiast stworzyć GPO na komputer z ‚loopback processing’, zrobione były polisy na użytkowników, z wyciętymi uprawnieniami dla komputerów. nadal nie jestem pewien, jakim cudem to w ogóle działało… przyszła poprawka i wymusiła porządki.

to tak jakby ktoś miał wątpliwości, czemu warto stosować proste, prawidłowe metody, zamiast dziwolągów, bazujących na nieudokumentowanych testach – po prostu z-dnia-na-dzień mogą przestać działać.

eN.