Search Results

Niedawno dowiedzieliśmy się o problemie z bezpieczeństwem związanym z nieautoryzowanym dostępem do podzbioru repozytoriów kodu Slacka. Klienci nie zostali dotknięci, nie są wymagane żadne działania, a incydent został szybko rozwiązany. Slack udostępniamy szczegóły incydentu. Co się stało 29 grudnia 2022 roku zostaliśmy powiadomieni o podejrzanej aktywności na naszym koncie GitHub. Po przeprowadzeniu dochodzenia odkryliśmy, że ograniczona liczba tokenów pracowniczych Slack została skradziona i niewłaściwie wykorzystana w celu uzyskania dostępu do naszego zewnętrznego repozytorium GitHub. Nasze dochodzenie ujawniło również, że cyberprzestępca pobrał prywatne repozytoria kodu 27 grudnia. Żadne pobrane repozytoria nie zawierały danych klientów, środków dostępu do danych klientów ani podstawowej bazy kodów Slacka. Nasza odpowiedź i dochodzenie Po powiadomieniu o incydencie natychmiast unieważniliśmy skradzione tokeny i rozpoczęliśmy badanie potencjalnego wpływu na naszych klientów. Nasze obecne ustalenia pokazują, że cyberprzestępca nie uzyskał dostępu do innych obszarów środowiska Slack, w tym do środowiska produkcyjnego, ani nie uzyskał dostępu do innych zasobów Slacka ani danych klientów. Nie miało to wpływu na nasz kod ani usługi, a także jako środek ostrożności wymieniliśmy wszystkie odpowiednie dane uwierzytelniające. Na podstawie obecnie dostępnych informacji nieautoryzowany dostęp nie wynikał z luki w zabezpieczeniach Slacka. Będziemy nadal badać i monitorować dalsze narażenie. źródło: https://slack.com/intl/en-au/blog/news/slack-security-update

Masowe kampanie złośliwych reklam w Google – podszywają się Visual Studio, Zooma, Slacka, Grammarly, Malwarebytes, Afterburnera, Audacity, Brave, uTorrent czy Dashlane. Na koniec – infekcja komputera. Na sekuraku dużo ostatnio było o tym informacji - Nasz czytelnik wygooglał pakiet instalacyjny Gimpa. Trafił na fejkową reklamę, zainfekował komputer i stracił dostęp do konta Google Kolejna fałszywa reklama w Google, tym razem MSI Afterburner Nasz czytelnik googlował sterowniki do karty graficznej. Kliknął w reklamę i wylądował na zainfekowanej stronie. Uwaga! Reklama nie przenosi Cię na właściwą stronę - łudząco przypomina tą właściwą. Są także inne reklamy więc warto uważać co pobieramy z internetu przez wyszukiwanie tego w google. Opisywany proceder jest o tyle ciekawy, że na początek reklamowane serwisy są całkiem w porządku (nie serwują malware) – to uspokaja Google. Później jeśli normalnie wchodzimy na dany serwis – również wszystko w porządku. Ale jeśli ktoś kliknie w reklamę, trafia na serwis „proxy”, który automatycznie przekierowuje do serwisu z malware: Finalna strona sugeruje pobranie danego oprogramowania np. z GitHuba. I tutaj znowu mniej zorientowani użytkownicy mogą myśleć – pobiorę coś z GitHuba – to na pewno będzie bezpieczne. Błąd: Ładunek złośliwego oprogramowania Vermux — udostępniany bezpłatnie w serwisie GitHub Ładunek Vermux jest w większości zbudowany w oparciu o trojana Vidar do kontroli i pewną zastrzeżoną kompilację oprogramowania do wydobywania Monero opartego na Pythonie. Pliki są zgodne z zasadami, o których wspominaliśmy wcześniej, co sprawia, że ​​są trudne do wykrycia i wymykają się. Vermux nie tylko nadużywa reputacji i siły propagacyjnej Google Ads, ale także nadużywa reputacji znanych usług udostępniania plików i repozytoriów kodu, takich jak BitBucket, GitHub, Dropbox, OneDrive itp. Oto kilka przykładów takich repozytoriów odkrytych w GitHub: Ale widać że jest tego znacznie więcej: Kilka rad: Zainstalujcie AdBlockera – np. uBlock origin. Dokładnie sprawdzajcie pasek adresu strony, z której pobieracie instalatory. Czasem różnica z oryginałem może być minimalna: Przed instalacją warto przeskanować plik instalacyjny w serwisie virustotal.com Konto Google: pamiętaj o silnym haśle (idealnie > 15 znaków), włącz dwustopniowe uwierzytelnienie oraz wygeneruj kody zapasowe (mogą być one potrzebne do sprawnego odzyskania dostępu do konta, jeśli stracisz do niego dostęp). Wszystko to możesz zrobić na zakładce Security (https://myaccount.google[.]com/security) Rozważ skonfigurowanie Google Advanced Protection. Streszczenie Bezpieczeństwo to kwestia zaufania — dlatego stale polegamy na zaufanych, renomowanych dostawcach w naszych codziennych staraniach w Internecie. Nikt nie jest jednak doskonały i prawdopodobnie jest więcej złych aktorów, którzy chcą wykorzystać te luki w zabezpieczeniach, niż możemy sobie wyobrazić. Tutaj dokładnie to widzimy — nieustanny wyścig szczurów między firmami stojącymi za tymi potężnymi systemami reklamowymi, globalną dostawą treści i infrastrukturą bezpieczeństwa do tych wymijających aktorów, którzy znajdują sposób, by wymknąć się spod radaru i wykorzystać zaufanych innych dla własnych korzyści. Ta koncepcja „masquerAd” jest prosta, ale robi dokładnie to, czego potrzebują ci aktorzy — nadużywa zaufania, które czasami ślepo obdarzamy Google i ich promowane wyniki wyszukiwania. Do tego dochodzi nadużywanie renomowanych serwisów wymiany plików oraz znanych marek oprogramowania, co sprawia, że ​​omijają one nawet najbardziej zaawansowane EDR-y na rynku. Stosowanie bardziej behawioralnego i bezstronnego poziomu ochrony jest nieuniknione — nawet w przypadku najprostszych i najczęstszych czynności, takich jak wyszukanie czegoś w googlach… Nie daj się nabrać na błędne nazwy domen i zawsze dokładnie sprawdzaj, skąd pobierasz pliki!

Curl https://cheat.sh/ Features cheat.sh Has a simple curl/browser/editor interface. Covers 56 programming languages, several DBMSes, and more than 1000 most important UNIX/Linux commands. Provides access to the best community driven cheat sheets repositories in the world, on par with StackOverflow. Available everywhere, no installation needed, but can be installed for offline usage. Ultrafast, returns answers within 100 ms, as a rule. Has a convenient command line client, cht.sh, that is very advantageous and helpful, though not mandatory. Can be used directly from code editors, without opening a browser and not switching your mental context. Supports a special stealth mode where it can be used fully invisibly without ever touching a key and making sounds. Fajne to :)

Mowa o https://whatsmyname.app/ wystarczy wpisać jeden (lub więcej) nicków w pole wyszukiwania https://twitter.com/osintcombine/status/1609375630579372035?s=20&t=ym9b3TVgTD_Cg7cD5yyoOA

Na pewno każdy z Was spotkał się z sytuacją kiedy super promocja posiadała tak naprawdę cenę wyższą, niż ta regularna sprzed promocji. Z tym właśnie ma walczyć nowe prawo, które weszło od 1. stycznia https://sip.lex.pl/akty-prawne/dzu-dziennik-ustaw/informowanie-o-cenach-towarow-i-uslug-18109812/art-4 W każdym przypadku informowania o obniżeniu ceny towaru lub usługi obok informacji o obniżonej cenie uwidacznia się również informację o najniższej cenie tego towaru lub tej usługi jaka obowiązywała w okresie 30 dni przed wprowadzeniem obniżki.

Za nami rok 2022 przed nami nowy rok 2023. Nowe możliwości wyzwania czy okazje. Pamiętajmy jednak że, nadal wiele podstępnych metod na pozyskanie naszych pieniędzy dalej działa w internecie. Pamiętajcie by być czujnym i ostrożnym. Jak zwiększyć swoje bezpieczeństwo, poprzez aplikacje Niebezpiecznika - CyberAlert Uważajcie na podobne metody ataku: Uwaga na SMS-y o zawieszeniu konta Netflix Uwaga klienci mBanku! Uwaga na e-maile od Krajowej Administracji Skarbowej! Uwaga klienci ING! Uwaga, nie płaćcie tego mandatu! Orange ostrzega. Uwaga na fałszywe bramki BLIK używane przez polskich złodziei Przestępcy stosują spoofing SMSów przy oszustwach na OLX. Podszywają się pod InPost czy pod sam OLX „Oddam w dobre ręce laptopa” – czyli jak przestępcy organizują sobie darmowe zakupy. Uważajcie Wystarczy tylko „zatwierdzić wniosek o zwrot podatku” aby otrzymać sporo pieniążków. A nie, czekaj, to oszustwo! Z poprzedniego roku może być jeszcze więcej spersonalizowanych ataków: Twierdzi, że ma bazę z danymi 400 milionów użytkowników Twittera Uwaga użytkownicy aplikacji LastPass! LastPass – o co chodzi w wycieku haseł z tego managera i jaki jest koszt złamania wszystkich Twoich haseł? Punktowy wyciek danych kupujących na Allegro. Dane wystawiono na sprzedaż. Incydent nie ma charakteru masowego. Oczywiście jest to tylko przekrój listopadowo / grudniowy. Miłej lektury. Źródła: sekurak.pl https://zaufanatrzeciastrona.pl/ https://niebezpiecznik.pl/

Za nami już cztery cześci o terraform mojego autorstwa o których przeczytasz tu: Materiał na wstęp i część pierwsza. Część druga Część trzecia Część czwarta A w tym artykule spotykamy się po raz piąty - i porozmawiamy sobie o zmiennych i zobaczymy jak dobre zaplanowanie naszego modułu pozwoli nam skonfigurować nasze środowisko developerskie i produkcyjne na podstawie tego samego modułu. Poprzez nadpisywanie zmiennych. Zatem zapraszam materiał do poczytania i obejrzenia. Małe zmiany by uzyskać elastyczność Finalna konfiguracja z części czwartej pozwala nam utworzyć projekt w DigitalOcean (taki byt w DigitalOcean według, którego można organizować "grupować" swoje zasoby) do tego projektu podpinamy strefe DNS. Tworzymy też VPC - czyli naszą sieć poprzez deklaracje adresu sieciowego dla regionów dostępnych w digitalocean - obecnie jest ich czternaście na czas pisania tego artykułu. Koncepcyjnie dla projektu przyjąłem sieć 10.X.0.0/16 i podzieliłem ją na pod sieć 10.X.0.0/20. Pozwoliło mi to pokryć każdy region i pozostawiło mi jeszcze dodatkowe dwa adresy sieci dla moich podsieci jako rezerwowe. Gdybym chciał bazując na tej konfiguracji stworzyc nowy projekt - czyli wykorzystać utworzony moduł. Byłoby to problematyczne ponieważ dużo wartości konfiguracyjnych zdefiniowałem jako stałe wpisy. Postarajmy się przerobić naszą konfiguracje tak by udało się elastycznie tworzyć drugie środowisko w naszym terraform na DigitalOcean. Zacznijmy od zasobu projekt w naszej konfiguracji. Plik procject.tf prezentuje się następująco: Będziemy musieli dodać tak jak to jest w polu name odwołanie do naszej zmiennej która, będzie wstawiać właściwą wartość w odpowiednim polu. Dodajmy zatem naszą odpowiednią zmienną: variable "digitalocean_project" { description = "" type = object({ name = string description = string purpose = string environment = string }) default = { description = "Project for YouTube Channel" environment = "development" name = "YoutubeProject" purpose = "Learning" } } Zmienna już dekralowaliśmy więc nie jest to dla nas jakaś nowość. Nowością może być fakt że nasze wartości które opisują projekt są w jednej zmiennej obiektowej z odpowiednimi własnościami. Deklarując taką zmienną w: type - wpisujemy rodzaj naszej zmiennej, tym razem będzie ona typu obiektowego co pozwoli nam zdefiniować dodatkowe pola i określić typ tych pól. I mamy tu name, description, purpose, environment typu string. default - tu możemy jak poprzednio zdefiniować wartości domyślne dla naszych zmiennych, tak by zabezpieczyć się przed tym jakby, ktoś podczas importowania/używania naszego modułu nie wskazał wartości dla tych zmiennych. Odwołanie teraz do tych zmiennych też już znamy. Dochodzi tutaj tylko aspekt jak odwołać się do poszczególnych wartości w tym obiekcie. Możemy to zrobić za pomocą kropki - czyli: var.digitalocean_project.name Po wprowadzeniu zmiany nasz zasób będzie wyglądał następująco: resource "digitalocean_project" "youtube-project" { name = var.digitalocean_project.name description = var.digitalocean_project.description purpose = var.digitalocean_project.purpose environment = var.digitalocean_project.environment } Możemy już teraz sprawdzić poprzez polecenie terraform plan czy nasza modyfikacja nie wprowadza żadnych zmian w stanie naszego terraforma. Pamiętamy że, w stanie terraform nie są przechowywane zmienne tylko juz wartości tych zmiennych, zatem terraform plan powinien pokazać że nie ma żadnych zmian: Teraz możemy te zmienne użyć w naszym module - a dokładnie w jego deklaracji w pliku main.tf - może to wygladać tak: module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "development" } } Zatem widzimy i wcześniej już to pokazywałem przez deklaracje naszego modułu możemy nadpisywać zadeklarowane zmienne - lub podawac ich wartości jeżeli nasze zmienne były by bez wartości default. Znów uruchomienie terraform plan nic nie zmieni - bo stan zgadza się z tym co jest w naszym backend ze stanem terraform. Możemy też gdybyśmy chcieli zmienić te wartości sprawdzic jak sie zachowa nasz terraform plan gdy taka zamianę testowo wprowadzimy do naszego pliku konfiguracyjnego. Terraform wykrywa zmiany i jak widzimy modyfikuje te wartości które zmieniamy - reszta pozostaje bez zmian i po stronie digitalocean odbywa to się w formie modyfikacji zasobu nie jego usunięcia. Bo i takie modyfikacje sie zdarzają by coś zmienić trzeba zasób najpierw usunąć a potem go dodać na nowo. Oczywiście terraform to robi automatycznie i nasz w podsumowaniu planu o tym informuje. Poprawiamy VPC Zmiana ta będzie zmiana dająca nam elastyczność również w przypadku tworzenia sieci. Obecnie tego nie mamy bo wartość adresu sieciowego tworzonego dla naszego regionu i danego VPC jest podawana na stałe. Musimy zmodyfikować naszą wartość dla pola ip_range na taką by była generowana dynamicznie. Możemy się wzorować na tym co mamy w polu name dla tego zasobu - resource "digitalocean_vpc" "sfo1" {}. Tu będziemy potrzebować dodatkowej zmiennej i musimy ją zadeklarować: variable "secound_octet_number" { description = "value" type = string default = "0" } Po deklaracji jej w naszym pliku vars.tf - mozemy ja wykorzystać w naszej konfiguracji i pliku vpc.tf. Przykład dla jednego regionu: A tu dla kompletnego pokrycia wszystkich regionów: resource "digitalocean_vpc" "nyc1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc1-vpc" region = "nyc1" ip_range = "10.${var.secound_octet_number}.0.0/20" } resource "digitalocean_vpc" "nyc2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc2-vpc" region = "nyc2" ip_range = "10.${var.secound_octet_number}.16.0/20" } resource "digitalocean_vpc" "nyc3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc3-vpc" region = "nyc3" ip_range = "10.${var.secound_octet_number}.32.0/20" } resource "digitalocean_vpc" "sfo1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo1-vpc" region = "sfo1" ip_range = "10.${var.secound_octet_number}.48.0/20" } resource "digitalocean_vpc" "sfo2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo2-vpc" region = "sfo2" ip_range = "10.${var.secound_octet_number}.64.0/20" } resource "digitalocean_vpc" "sfo3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo3-vpc" region = "sfo3" ip_range = "10.${var.secound_octet_number}.80.0/20" } resource "digitalocean_vpc" "tor1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-tor1-vpc" region = "tor1" ip_range = "10.${var.secound_octet_number}.96.0/20" } resource "digitalocean_vpc" "lon1" { name = "terraform-${var.type_env}-${var.name_env}-europe-lon1-vpc" region = "lon1" ip_range = "10.${var.secound_octet_number}.112.0/20" } resource "digitalocean_vpc" "ams2" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams2-vpc" region = "ams2" ip_range = "10.${var.secound_octet_number}.128.0/20" } resource "digitalocean_vpc" "ams3" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams3-vpc" region = "ams3" ip_range = "10.${var.secound_octet_number}.144.0/20" } resource "digitalocean_vpc" "fra1" { name = "terraform-${var.type_env}-${var.name_env}-europe-fra1-vpc" region = "fra1" ip_range = "10.${var.secound_octet_number}.160.0/20" } resource "digitalocean_vpc" "sgp1" { name = "terraform-${var.type_env}-${var.name_env}-asia-sgp1-vpc" region = "sgp1" ip_range = "10.${var.secound_octet_number}.176.0/20" } resource "digitalocean_vpc" "blr1" { name = "terraform-${var.type_env}-${var.name_env}-asia-blr1-vpc" region = "blr1" ip_range = "10.${var.secound_octet_number}.192.0/20" } resource "digitalocean_vpc" "syd1" { name = "terraform-${var.type_env}-${var.name_env}-australia-syd1-vpc" region = "syd1" ip_range = "10.${var.secound_octet_number}.208.0/20" } Mamy nasze VPC obsłużone - zostało nam jeszcze do modyfikacji lekkiej plik domain.tf tak by odwołać się do właściwej nazwy projektu w naszym data - będzie to dokładnie: data "digitalocean_project" "youtube-project" { name = var.digitalocean_project.name } a całość prezentuje się w następujący sposób: data "digitalocean_project" "youtube-project" { name = var.digitalocean_project.name } resource "digitalocean_project_resources" "domain" { project = data.digitalocean_project.youtube-project.id resources = [ digitalocean_domain.dev-technicznie-nietechnicznie-cloud.urn ] } resource "digitalocean_domain" "dev-technicznie-nietechnicznie-cloud" { name = "${var.app_env}.technicznie-nietechnicznie.cloud" } I teraz kompletny plik main.tf module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "development" } type_env = "development" secound_octet_number = "1" name_env = "youtube" app_env = "dev" } Sprawdzamy i znów terraform plan nie pokazuje żadnych zmian. Czas zatem je wprowadzić w postaci uruchomienia nowego projektu na podstawie naszego moduły. Plik main.tf bedzie wyglądał nastepująco: module "myovh" { source = "./modules/myovh" } module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "development" } type_env = "development" secound_octet_number = "1" name_env = "youtube" app_env = "dev" } module "digitalocean-youtube2" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } digitalocean_project = { name = "ProdYoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "production" } type_env = "production" secound_octet_number = "2" name_env = "newyoutube" app_env = "prod" } Sprawdźmy zatem ile i jakie zmiany dokonają się w naszym stanie i na naszym DigitalOcean. wydajemy polecenie terraform init i potem terraform plan Jak widzimy w podsumowaniu zostanie dodanych siedemnaście zasobów w digitalocean jako nowe - czyli nasz poprzedni moduł i utworzone zasoby nie zostaną w żaden sposób zmodyfikowane. Możemy teraz to zweryfikować po stronie DigitalOcean i pokaże nam się nowy projekt: W projekcie nowo utworzonym widzimy że, nasza domena została prawidłowo podpieta I sieci zostały po tworzone dla naszych regionów - vpc nie mozna przypisac do projektu dlatego widoczne są też te wcześniej tworzone dla poprzedniego modułu w terraform. Jak widać wszystko działa i zachowuje się według ustalonej konfiguracji. W tym artykule to wszystko. Daj znać czy taka seria Ci się podoba. Pozdrawiam.

Niestety przed samymi świętami (23 grudnia) zdarzyło się to, czego najbardziej obawiają się administratorzy systemów – ujawniono poważną lukę bezpieczeństwa w systemach Linux. Zero Day Initiative (ZDI), firma zajmująca się badaniami nad podatnościami typu zero-day, ogłosiła nowy błąd jądra Linuksa. Luka umożliwia uwierzytelnionym użytkownikom zdalne ujawnianie poufnych informacji oraz uruchamianie kodu w podatnych na ataki wersjach jądra. Zródło: https://nakedsecurity.sophos.com/2022/12/27/critical-10-out-of-10-linux-kernel-smb-hole-should-you-worry/ Any Linux from 5.15.61 on, or any 6.x, is already patched. Pierwotnie ZDI oceniło podatność jako krytyczne 10 w skali od 0 do 10 powszechnego CVSS. Teraz luka ma „tylko” 9.6, co w praktyce nadal oznacza „załataj najszybciej, jak się da!”. Problem dotyczy programu ksmbd, wersji jądra 5.15 usługi Server Message Block (SMB). Konkretnie podatność występuje w przetwarzaniu poleceń SMB2_TREE_DISCONNECT i wynika z braku walidacji istnienia obiektu przed wykonaniem na nim operacji. Osoba atakująca może wykorzystać tę lukę do wykonania kodu w kontekście jądra. Nowy moduł SMB, opracowany przez firmę Samsung, został wprowadzony do jądra Linux w 2021 roku. Jego celem było zapewnienie wysokiej wydajności w obsłudze plików SMB v3. Jak wiadomo, protokół SMB używany jest w systemie Windows, a w systemie Linux – jako nadrzędny protokół wymiany plików za pośrednictwem Samby. Podatny moduł ksmbd nie ma na celu zastąpienia Samby, ale jej uzupełnienie. Deweloperzy Samby i ksmbd pracują nad tym, aby programy działały wspólnie. Jeremy Allison, współtwórca Samby, zauważa: „ksmbd nie współdzieli kodu z produkcyjną wersją protokołu Samba. Jest napisany całkowicie od zera. Tak więc obecna sytuacja nie ma nic wspólnego z serwerem plików Samba, który można bez obaw uruchamiać w swoich systemach”. Każda dystrybucja korzystająca z jądra Linuksa 5.15 lub nowszego jest potencjalnie podatna na ataki. Obejmuje to Ubuntu 22.04 i jego następców oraz Deepin Linux 20.3. Jeśli chodzi o serwery, Ubuntu jest najbardziej niepokojące. Inne dystrybucje wykorzystywane przemysłowo, takie jak rodzina Red Hat Enterprise Linux (RHEL), nie używają jądra 5.15. Aby zweryfikować, czy na konkretnej dystrybucji Linuksa uruchomiona jest podatna usługa, należy wykonać: $ uname -r aby zobaczyć, której wersji jądra używasz; $ modinfo ksmb – aby sprawdzić, czy podatny moduł jest obecny w systemie i uruchomiony. Any Linux from 5.15.61 on, or any 6.x, is already patched. To check your Linux version: $ uname -o -r 6.1.1 GNU/Linux To see if this kernel feature is compiled in, you can dump the compile-time configuration of the running kernel: $ zcat /proc/config.gz | grep SMB_SERVER # CONFIG_SMB_SERVER is not set If this compile-time configuration setting is unset, or set to "n" for no, the feature wasn't built at all. If it says "y" for yes, then the kernel SMB server is compiled right into your kernel, so ensure you have a patched version. If it says "m" for module, then the kernel build probably includes a run-time module that can be loaded on demand. To see if your kernel has a loadable module available: $ /sbin/modprobe --show ksmbd modprobe: FATAL: Module ksmbd not found in directory /lib/modules/6.1.1 Note that "--show" means "never actually do it, just show if loading it would work or not". To see if your system has the ksmbd module already active: $ lsmod | grep ksmbd If you see no output, the module wasn't matched in the list. To stop the module loading inadvertently in case it ever shows up, add a file with a name such as ksmbd.conf to the directory /lib/modules.d or /etc/modules.d with these lines in it: blacklist ksmbd install ksmbd /bin/false To, co chcemy zobaczyć, to to, że moduł nie został znaleziony. Jeśli jest załadowany do pamięci, powinniśmy natychmiast wykonać aktualizację jądra Linux do wersji przynajmniej 5.15.61. Niestety nie wszystkie dystrybucje otrzymały już aktualizacje. Lista jest dostępna tutaj. Niektórzy zastanawiają się, czy omawiana podatność jest rzeczywiście tak poważna, jeśli nie nadano jej nawet numeru CVE. Greg Kroah-Hartmann, opiekun jądra Linuksa, wyjaśnił: „…programiści jądra w ogóle nie pracują z CVE, ponieważ w większości nie są one odwzorowaniem konkretnych problemów”. To prawda, że „niektóre organizacje linuksowe nadal nalegają na przypisywanie CVE, ale ma to przede wszystkim na celu umożliwienie wewnętrznych procesów inżynieryjnych”. Warto pamiętać, że implementacje Windows SMB mają długą, brzydką historię swoich zabezpieczeń. Rozpoczynając od podatnego i nieużywanego już SMB v1 (WannaCry), a kończąc na SMBGhost, który otworzył komputery z systemem Windows 10 na ataki bez uwierzytelnienia. Nie tylko osoby z zewnątrz martwią się o bezpieczeństwo ksmbd. Kees Cook, starszy programista zajmujący się bezpieczeństwem jądra Linuksa, napisał: „Niektóre z tych luk to dość fundamentalne właściwości bezpieczeństwa systemu plików, których nie testowano pod tym kątem”. Podsumował: „Martwię się tutaj o jakość kodu i myślę, że coś musi się zmienić w procesach recenzji i testowania”. Taka wypowiedź świadczy o tym, że zawodzą wewnętrzne procedury testów bezpieczeństwa, które powinny być pierwszym etapem znajdowania i naprawiania takich właśnie błędów. Aktualizacje z poprawkami są dostępne, ale sytuacja pokazuje, że kod wymaga dokładniejszego przeglądu i zabezpieczenia, zanim wszyscy będziemy w stanie zaufać mu w pełni na produkcji. Rozsądnie byłoby na razie załatanie jądra i wstrzymanie się z jego używaniem na rzecz funkcjonalności Samba.

Jak dowiedział się Dziennik Gazeta Prawna, planowane są nowe zmiany m.in. w Prawie Telekomunikacyjnym. Rząd chce zaproponować stworzenie katalogu zastrzeżonych nadpisów dla instytucji publicznych. Operatorzy telekomunikacyjni mieliby obowiązek blokowania SMS-ów, które korzystałyby z nadpisu znajdującego się we wspomnianym katalogu, a wychodzących z innego systemu (tzw. bramki SMS) niż tego zarządzanego przez państwo. Nadpis to nic innego jak nazwa nadawcy, którą widać na górze SMSa (w tym przypadku to InPost). Oczywiście ostatni SMS nie przyszedł wcale od InPostu, a jedynie przestępca wysyłając wiadomość podał nazwę nadawcy: InPost (sieci komórkowe pozwalają obecnie na takie „akcje”). I właśnie z tym ma walczyć nowe prawo. Wracając do oryginalnego cytatu, być może możliwość zastrzeżenia nazwy nadawcy będą miały tylko instytucje rządowe: (…) obowiązek blokowania SMS-ów, które korzystałyby z nadpisu znajdującego się we wspomnianym katalogu, a wychodzących z innego systemu (tzw. bramki SMS) niż tego zarządzanego przez państwo. Regulacja ta ma wprowadzić możliwość nieodpłatnego wysyłania SMS-ów m.in. przez organy administracji rządowej, sądy, prokuraturę, samorządy, NFZ, ZUS czy KRUS. Czy więc – jak zresztą wskazują eksperci cytowani w opracowaniu DGP – czeka nas teraz fala SMSów z ZUSu, sądów czy innych instytucji rządowych? Niby lepiej dostać SMSa informującego, że coś mam sprawdzić w ZUSie (niż zwykłą pocztę „za pobraniem”), ale z drugiej strony może to skusić przestępców do podszywania się pod te instytucje („wiadomo przecież że ZUS pisze SMSy”). Czekamy na rozwój sytuacji, w tym kwestii czy również prywatne instytucje (np. InPost) mogłyby być włączone do takiego rejestru.

Okta, producent rozwiązań Identity and Access Management (IAM), w swoim oświadczeniu napisało, że zostali zhackowani w tym miesiącu. W wyniku ataku zostały wykradzione kody źródłowe z repozytoriów platformy GitHub. Niestety w tym roku to nie pierwszy przypadek, więcej poczytać możesz na sekuraku: Pierwszy przypadek włamania do okta w tym roku: https://sekurak.pl/wlamanie-do-okta-swiatowego-lidera-w-zarzadzaniu-tozsamoscia/ Zatakowała grupa LAPSUS$ https://sekurak.pl/lapsus-dobralismy-sie-kodow-zrodlowych-microsoftu-bing-bing-maps-cortana/ GitHub poinformował dostawcę o “podejrzanej aktywności” z początkiem miesiąca. Okta zablokowało dostęp do swoich repozytoriów, weryfikując wszystkie dostępy. Następnie stwierdzili, że cyberprzestępcy uzyskali dostęp do kodów źródłowych rozwiązania Workforce Identity Cloud (WIC) – czyli rozwiązania bezpieczeństwa klasy enterprise będącego w ofercie Okta. Jednocześnie wskazali, że nie doszło do naruszenia bezpieczeństwa usług związanych z danymi klientów i Auth0, które zostało zakupione w 2021. źródło: https://sec.okta.com/articles/2022/12/okta-code-repositories https://sekurak.pl/okta-ponownie-z-incydentem-skradzione-kody-zrodlowe/

W kolejnej czwartej części zajmiemy się konfiguracja naszego Digital Ocean i tu skonfigurujemy nasze sieci (Networking) - czyli VPC dla adresu sieciowego 10.1.0.0/16 z podziałem na podsieci, oraz skonfigurujemy strefa DNS (Domain) dla dev.technicznie-nietechnicznie.cloud. Dodamy też trochę zmiennych tak by nasza konfiguracja była bardziej elastyczna. Jeżeli trafiłeś tu i nie znasz poprzednich materiałów poniżej mały spis (poroponowana kolejność czytania): część pierwsza - Infrastruktura jako kod (IaaC) - cześć 1 część druga - Zmieńmy naszą konfigurację na moduł. Infrastruktura jako kod (IaaC) - cześć 2 część trzecia - Infrastruktura w Kodzie (IaaC) - Digital Ocean, prosty cloud na start - część trzecia. Wstępniak teoretyczny: Terreform - początki (czysto teoretyczne) Dodajmy zmienne W terraform często będziemy wykorzystywać zmienne lub się do nich odnosić na różne sposoby. Będziemy też wykorzystywać wartości, które wygeneruje nam pewien zasób (resources) stworzony w Digital Ocean, a że nie znamy jego nazwy przed stworzeniem czy identyfikatora będziemy musieli się do niego jakoś odnieść - po przez właśnie zmienne lub "kotwice". Zadeklarujemy sobie kilka zmiennych na początek. Tworzymy plik vars.tf - jego konstrukcja bedzie nastepująca: variable "type_env" { description = "Type enviroment example: development, staging or production." type = string default = "development" } variable "name_env" { description = "Name enviroment." type = string default = "youtube" } variable "app_name_type" { description = "Application name" type = string default = "dev" } variable "app_name" { description = "Application name" type = string default = "Application" } Nie pierwszy raz już deklarujemy nasze zmienne więc sposób deklaracji ich w terraform nie powinien być dla nas zaskoczeniem. Spojrzymy tylko na nowe elementy: type - określa jakiego typu jest to zmienna - w tym przypadku jest to string - isinieje jeszcze kilka innych typów. default - określa domyślna wartość w przypadku nie podania tej zmiennej przez użytkownika terafforma (operatora). Pierwszą zmienna z naszej listy type_env możemy wykorzystać już w poprzednio naszym utworzonym pliku project.tf - wykorzystanie bedzie bardzo proste wskazujemy jaki obiekt nas interesuje w tym przypadku var a po kropce odwołujemy się do nazwy naszej zmiennej - całość prezentuje się tak resource "digitalocean_project" "youtube-project" { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = var.type_env } Naszą zmienna type_env użyjemy w wartości enviroment. Dzięki temu będziemy mogli później przez nasz moduł nadpisywać te zmienne i uruchomić przykładowo takie samo środowisko produkcyjne w naszej konfiguracji. Po prostu tworząc nowy moduł a w nim tylko nadpisując zmienne. Przykład poniżej: module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } type_env = "production" } Tak uruchomiony kod w Terraform dla mojej aktualnej konfiguracji oczywiście spowodowałby zmiany ponieważ ja już mam skonfigurowany projekt w DigitalOcean z wartości development dla enviroment w resources "digitalocean_project" "youtube-project". Sprawdzenie potwierdziło, że funkcjonalność działa tak jak należy. Konfigurujemy sieć dla naszych regionów Regionów w digitalocean nie jest tak dużo jak w AWS czy Azure, ale liczba 14 regionów i konieczność ręcznej konfiguracji sieci w każdym z tych regionów byłaby męcząca. Wezmę sieć 10.1.0.0/16 i podzielę ja na podsieci z maską 10.1.X.X/20 (cidr). Da to mi w moim przypadku podział na 16 podsieci czyli przy 14 regionach jest to idealny podział. W digitalocean regiony mamy następujące: North America: NYC1 NYC2 NYC3 SFO1 SFO2 SFO3 TOR1 Europe: LON1 AMS2 AMS3 FRA1 Asia: SGP1 BLR1 Australia: SYD1: Konfiguracja sieci odbywać się będzie w następujący sposób poprzez resources "digitalocean_vpc" poniżej przykład dla jednego regionu: resource "digitalocean_vpc" "nyc3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc3-vpc" region = "nyc3" ip_range = "10.1.32.0/20" } Gdzie odpowiednie pola: name - to nazwa naszej sieci (vpc) region - to informacja dla jakiego regiony bedzie dostepna ta konkretna sieć ip_range - tu podział na moje subnety A tak prezentuje się całościowo plik konfiguracyjny vpc.tf: resource "digitalocean_vpc" "nyc1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc1-vpc" region = "nyc1" ip_range = "10.1.0.0/20" } resource "digitalocean_vpc" "nyc2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc2-vpc" region = "nyc2" ip_range = "10.1.16.0/20" } resource "digitalocean_vpc" "nyc3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-nyc3-vpc" region = "nyc3" ip_range = "10.1.32.0/20" } resource "digitalocean_vpc" "sfo1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo1-vpc" region = "sfo1" ip_range = "10.1.48.0/20" } resource "digitalocean_vpc" "sfo2" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo2-vpc" region = "sfo2" ip_range = "10.1.64.0/20" } resource "digitalocean_vpc" "sfo3" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-sfo3-vpc" region = "sfo3" ip_range = "10.1.80.0/20" } resource "digitalocean_vpc" "tor1" { name = "terraform-${var.type_env}-${var.name_env}-northamerica-tor1-vpc" region = "tor1" ip_range = "10.1.96.0/20" } resource "digitalocean_vpc" "lon1" { name = "terraform-${var.type_env}-${var.name_env}-europe-lon1-vpc" region = "lon1" ip_range = "10.1.112.0/20" } resource "digitalocean_vpc" "ams2" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams2-vpc" region = "ams2" ip_range = "10.1.128.0/20" } resource "digitalocean_vpc" "ams3" { name = "terraform-${var.type_env}-${var.name_env}-europe-ams3-vpc" region = "ams3" ip_range = "10.1.144.0/20" } resource "digitalocean_vpc" "fra1" { name = "terraform-${var.type_env}-${var.name_env}-europe-fra1-vpc" region = "fra1" ip_range = "10.1.160.0/20" } resource "digitalocean_vpc" "sgp1" { name = "terraform-${var.type_env}-${var.name_env}-asia-sgp1-vpc" region = "sgp1" ip_range = "10.1.176.0/20" } resource "digitalocean_vpc" "blr1" { name = "terraform-${var.type_env}-${var.name_env}-asia-blr1-vpc" region = "blr1" ip_range = "10.1.192.0/20" } resource "digitalocean_vpc" "syd1" { name = "terraform-${var.type_env}-${var.name_env}-australia-syd1-vpc" region = "syd1" ip_range = "10.1.208.0/20" } Wartość ta terraform-${var.type_env}-${var.name_env}-europe-fra1-vpc jest niczym innym jak generowaną nazwa dla vpc na podstawie stałych elementów + uzupełniona z wcześniej zadeklarowanych zmiennych wartościami. Możemy teraz uruchomić terraform plan i sprawdzić czy wszystko będzie dodane prawidłowo. Komunikat o 14 dodanych zasobach jest poprawnym komunikatem. Terraform apply i możemy weryfikować po stronie DigitalOcean czy mamy wszystkie VPC stworzone. DNS po stronie Digital Ocean - działamy z modułem OVH Dobrze mieć naszą konfigurację tak ustawiona dla naszych maszyn wirtualnych że, będa one automatycznie otrzymywać nazwy FQDN. Tworząc zasób w digital ocean oprócz IP będę też mu przydzielał łatwiejszą do zapamiętania nazwę kanoniczna. W głowie wolę pamiętać numery telefonów a nie adresy IP :) Muszę zatem wykierować moją subdomenę z OVH do DigitalOcean. Dlatego też stworzony wczesniej moduł OVH i obsługiwany w terraform wykorzystam do tego. Mogę szybko tą zmianę zrobić z poziomu mojego kodu. Tworzę trzy rekordy NS kierujące na moją zone w DigitalOcean. resource "ovh_domain_zone_record" "ns1-dev-technicznie-nietechnicznie-cloud" { zone = "technicznie-nietechnicznie.cloud" target = "ns1.digitalocean.com." fieldtype = "NS" subdomain = "dev" ttl = "0" } resource "ovh_domain_zone_record" "ns2-dev-technicznie-nietechnicznie-cloud" { zone = "technicznie-nietechnicznie.cloud" target = "ns2.digitalocean.com." fieldtype = "NS" subdomain = "dev" ttl = "0" } resource "ovh_domain_zone_record" "ns3-dev-technicznie-nietechnicznie-cloud" { zone = "technicznie-nietechnicznie.cloud" target = "ns3.digitalocean.com." fieldtype = "NS" subdomain = "dev" ttl = "0" } Konfiguracja po stronie DigitalOcean będzie wyglądać następująco - tworzymy nowy plik domain.tf data "digitalocean_project" "youtube-project" { name = "YoutubeProject" } resource "digitalocean_project_resources" "domain" { project = data.digitalocean_project.youtube-project.id resources = [ digitalocean_domain.dev-technicznie-nietechnicznie-cloud.urn ] } resource "digitalocean_domain" "dev-technicznie-nietechnicznie-cloud" { name = "${var.app_name_type}.technicznie-nietechnicznie.cloud" } Pojawiły nam się trzy nowe obiekty oraz nowy typ w terraform, data - dostępny z naszego providera digitalocean. data "digitalocean_project" "youtube-project" - to wartość, która pobierze nam kilka pól z projektu o nazwie "YoutubeProject" ale nas będzie głownie interesować ID naszego projektu. Potrzebny będzie ono nam do połączenia URN Domeny z ID projektu i w ten sposób zapięcia Domeny w DigitalOcean do naszego projektu który stworzyliśmy. resource "digitalocean_project_resources" "domain" - zasób ten właśnie robi nam połączenia i w ten sposób Projekt w Digital Ocean wie że domena dev.technicznie-nietechnicznie.cloud należy do tego własnie projektu jakim jest "YoutubeProject" resource "digitalocean_domain" "dev-technicznie-nietechnicznie-cloud" - to już deklaracja samej naszej Zony jeszcze bez rekordów, nie licząc trzech rekordów NS) Już na tym etapie wiemy co robimy :) wiec po naszym terraform plan, terraform apply sprawdzamy czy mamy naszą zone w digitalocean. Projekt pokazuje nam naszą zone - zatem wszystko mamy skonfigurowane jak należy. W tym artykule to tyle, w kolejnym materiale uruchomimy naszą pierwsza aplikacje skonfigurowana w terraform.

Według ekspertów ds. Agencja zaleca teraz, aby specjaliści IT zastąpili SHA-1, w ograniczonych sytuacjach, w których jest nadal używany, nowszymi algorytmami, które są bezpieczniejsze. SHA-1, którego inicjały oznaczają „bezpieczny algorytm mieszania”, jest używany od 1995 roku jako część Federalnego Standardu Przetwarzania Informacji (FIPS) 180-1 . Jest to nieco zmodyfikowana wersja SHA, pierwszej funkcji skrótu, którą rząd federalny ustandaryzował do powszechnego użytku w 1993 roku. Ponieważ dzisiejsze coraz potężniejsze komputery są w stanie zaatakować algorytm, NIST ogłasza, że ​​SHA-1 powinien zostać wycofany do 31 grudnia. , 2030, na korzyść bezpieczniejszych grup algorytmów SHA-2 i SHA-3. „Zalecamy, aby każdy, kto polega na SHA-1 w zakresie bezpieczeństwa, jak najszybciej przeszedł na SHA-2 lub SHA-3” — powiedział informatyk NIST, Chris Celi. SHA-1 służył jako element konstrukcyjny wielu aplikacji zabezpieczających, takich jak sprawdzanie poprawności witryn internetowych — dzięki czemu po załadowaniu strony internetowej można mieć pewność, że jej rzekome źródło jest autentyczne. Zabezpiecza informacje, wykonując złożoną operację matematyczną na znakach wiadomości, tworząc krótki ciąg znaków zwany hashem. Niemożliwe jest zrekonstruowanie oryginalnej wiadomości na podstawie samego skrótu, ale znajomość skrótu zapewnia odbiorcy łatwy sposób sprawdzenia, czy oryginalna wiadomość została naruszona, ponieważ nawet niewielka zmiana w wiadomości radykalnie zmienia wynikowy skrót. Dzisiejsze, potężniejsze komputery mogą tworzyć fałszywe wiadomości, których wynikiem jest ten sam skrót, co oryginał, co potencjalnie zagraża autentyczności wiadomości. Te ataki „zderzeniowe” były wykorzystywane w ostatnich latach do osłabiania SHA-1 . NIST ogłosił wcześniej, że agencje federalne powinny zaprzestać używania SHA-1 w sytuacjach, w których ataki kolizyjne stanowią krytyczne zagrożenie, na przykład przy tworzeniu podpisów cyfrowych. Ponieważ ataki na SHA-1 w innych aplikacjach stają się coraz poważniejsze , NIST przestanie używać SHA-1 w swoich ostatnich pozostałych określonych protokołach do 31 grudnia 2030 r. Do tego dnia NIST planuje: Opublikuj FIPS 180-5 (poprawkę FIPS 180), aby usunąć specyfikację SHA-1. Zrewiduj SP 800-131A i inne publikacje NIST, których to dotyczy, aby odzwierciedlić planowane wycofanie SHA-1. Utwórz i opublikuj strategię przejścia do sprawdzania poprawności modułów i algorytmów kryptograficznych. Ostatnia pozycja odnosi się do Programu Walidacji Modułów Kryptograficznych ( CMVP ) NIST, który ocenia, czy moduły – elementy budulcowe tworzące funkcjonalny system szyfrowania – działają efektywnie. Wszystkie moduły kryptograficzne używane w szyfrowaniu federalnym muszą być sprawdzane co pięć lat, więc zmiana statusu SHA-1 wpłynie na firmy opracowujące moduły. „Moduły, które nadal używają SHA-1 po 2030 roku, nie będą mogły być kupowane przez rząd federalny” – powiedział Celi. „Firmy mają osiem lat na przesłanie zaktualizowanych modułów, które nie używają już SHA-1. Ponieważ często występują zaległości w przesyłaniu przed upływem terminu, zalecamy, aby programiści przesłali swoje zaktualizowane moduły z dużym wyprzedzeniem, aby CMVP miał czas na odpowiedź”.

Witam ponownie w trzeciej już części naszych (moich) zmagań z Terraform. W tym odcinku dodamy obsługę Digatal Ocean i przygotujemy nasz kod do obsługi właśnie tej infrastruktury Cloud. Ktoś pewnie zapyta dlaczego nie AWS - przecież jest bardziej popularny i szerzej wykorzystywany przez organizacje. Oczywiście zgodze się - lecz hobbistycznie w domowym zaciszu wolę pobawić się inną platformą niż tą którą bawię się w pracy :) Work Life Balance :D :D - gotowi zaczynamy. ... a tak poprzednie dwie części znajdziesz tu: Część pierwsza - Infrastruktura jako kod (IaaC) - cześć 1 Część druga - Zmieńmy naszą konfigurację na moduł. Infrastruktura jako kod (IaaC) - cześć 2 A teraz część trzecia Na tym etapie mamy już katalog ./modules i nasz pierwszy moduł w postaci konfiguracji OVH (w katalogu ./modules/myovh) - dzięki temu mam możliwość kontroli moich rekordów w OVH z poziomu terraforma. Jak będę potrzebował dowolnego rekordu na przykład A wystarczy że dodam taki wpis (przykład): resource "ovh_domain_zone_record" "ID-5251866548-technicznie-nietechnicznie-cloud" { fieldtype = "A" subdomain = "" ttl = "0" target = "213.186.33.5" zone = "technicznie-nietechnicznie.cloud" } I po wydaniu polecenia terraform apply będzie on w mojej konfiguracji już wprowadzony po stronie OVH. Proste czytelne i mamy kontrolę zmian. Widzimy kto co i kiedy dodawał - oczywiście nie w samym terraform ale w naszych "commitach" do repozytorium kodu git. Okej, teraz dodajmy sobie obsługę DigitalOcean i sprawimy że nasza konfiguracja zacznie żyć. Pojawią się pierwsze usługi, uruchomimy naszą stronę www, postawimy bazę danych i stworzymy aplikację. Ale pomalutku, dodajmy nasz pierwszy koncept czyli byt jakim jest projekt w DigitalOcean. Obsługa Digital Ocean Dodajemy wpis w pliku providers.tf w naszym głownym repozytorium z informacja o naszym wymaganym prowiderze: terraform { required_providers { ovh = { source = "ovh/ovh" } digitalocean = { source = "digitalocean/digitalocean" version = "~> 2.0" } } backend "pg" { conn_str = "połączenia do bazy danych PostgreSQL" } } Dokładnie interesuje nas ta nowa sekcja w której wybieramy nazwę dla naszego providera. Dokładnie to słowo przed znaczkiem równości. Nazwa ta jest umowna, gdybym wpisał tu "pomidor" i po tej nazwie się odwoływał wszystko by działało. Najważniejsza jest ta cześć po znaku równości. Czyli nasz source i version. Source znamy już z poprzednich dwóch części i wskazujemy tu naszego dostawcze i providera od tego dostawcy Version określa wersję naszego provaidera jaką chcemy pobrać. Ten akurat zapis pobierze najnowszą wersje ale nie mniejsza niż 2.0. Możemy tutaj zastosować inne kombinacje. W tym samym pliku będziemy potrzebować dodać obsługę naszego nowego providera plus deklaracja naszej zmiennej poprzez variable. Oczywiście skąd takie ustawienia można znaleźć w dokumentacji. Zatem dodajemy: variable "do_token_youtube" { description = "Digital Ocean Acces token" sensitive = true } provider "digitalocean" { alias = "youtube-do" token = var.do_token_youtube } Sekcja variable jest już dla nas znana zawiera deklarację zmiennej plus informacje o tym że wartości w tej zmiennej będą wrażliwe i będa pokazywane za pomocą gwiazdek w outputach terraform. To co nowe to wartość alias oraz token. Zacznijmy od tokena - to po prostu zmienna z wartością tokena do naszego konta w DigitalOcean, którego możemy utworzyć w DigitalOcean w tym miejscu: Po utworzeniu go dodajemy wartość naszego tokena do pliku .auto.tfvars z naszymi kluczami do OVH przy wartości do_token_youtube = " " - tak jak przedstawiłem to poniżej. Plik jest uwzględniony w .gitignore wiec nie znajdzie się w naszym repozytorium podczas commitowania zmian. # OVH ovh_endpoint = "ovh-eu" ovh_application_key = "" ovh_application_secret = "" ovh_consumer_key = "" # DigitalOcean do_token_youtube = "" Wróćmy do aliasa. Alias to jak nazwa wskazuje dodatkowy łącznika do wykorzystania ponownie tego samego providera i możliwość nadpisywania zmiennych w providerze w danym module. Terraform nie pozwala wielokrotnie deklarować tego samego providera nawet pod inna nazwą i daje za to mechanizm aliasów. Zatem naszym nadpisywany elementem w przypadku digitalocean będzie to token, a w przypadku ovh byłoby to odpowiednio endpoint, application_key, application_secret i consumer_key. Wykorzystanie takiego provideram bedzie w pliku main.tf jako deklaracja naszego nowego modułu: module "myovh" { source = "./modules/myovh" } module "digitalocean-youtube" { source = "./modules/digitalocean/youtube-do" providers = { digitalocean = digitalocean.youtube-do } } Source - wskazujemy ścieżkę do konfiguracji naszego modułu względem naszego pliku main.tf z folderu z naszym repozytorium git. Providers - to nic innego jak lista zdefiniowanych naszych providerów połączonych przez alias Do kompletu potrzebujemy folderu tak jak zadeklarowaliśmy to w sekcji source dla modułu digitalocean-youtube. W tym katalogu tworzymy dwa pliki project.tf i provider.tf. Plik z provider.tf będzie zawierał informację z jakiego providera ma korzystać. Wiem troche to takie masło maślane ale tak działa terraform i jego moduły. Po prostu moduł nie wie z jakiego modułu korzysta nasz cały projekt i musimy mu to powiedzieć. A żeby nie deklarować w różnych katalogach zmiennych nasz moduł łączymy z aliasem naszego providera i zmienne są przekazywane przez te alias terraform { required_providers { digitalocean = { source = "digitalocean/digitalocean" version = "~> 2.0" } } } Plik z project.tf to już konfiguracja naszych zasobów po stronie digitalocean. Tym pierwszym zasobem będzie skonfigurowanie naszego projektu w digitalocean. resource "digitalocean_project" "youtube-project" { name = "YoutubeProject" description = "Project for YouTube Channel" purpose = "Learning" environment = "development" } Taki wpis w pliku tworzy nam nowy zasób, który utworzy nam w digital ocean byt zwany projektem o parametrach opisanych w pliku terraform. Jestesmy juz gotowi na uruchomienie i wydanie polecenia terraform init, który to zaciągnie nam wszystkie brakujące moduły i providerów do naszej konfiguracji. Zielony komunikat "Terraform has been successfully initialized!" informacje nas że wszystko jest okej z nasz inicjalizacją. Wydanie polecenia terraform plan pokazuje nam że polecenie terraform apply doda nasz projekt do digitalocean. Akceptujemy naszą zmianę i po chwili widzimy jak wszystko mamy już zaimplementowane przez naszego terraforma Zmiana została dodan. Możemy to zweryfikować wzrokowo w naszym Digital Ocean przechodząc na nasze konto i sprawdzając czy nasz projekt widnieje na liście projektów To wszystko w tym wpisie. A konfiguracja dalsza naszych aplikacji, maszyn wirtualnych i firewall to już inna do której zajrzymy w kolejnym moim wpisie. Pozdrawiam.

W poprzedniej części - Infrastruktura jako kod (IaaC) - cześć 1 zaczeliśmy zabawę z IaC czyli z naszą infrastrukturą w kodzie i dodalismy obsługę naszego OVH w terreform. Spróbuje moją obecna konfigurację przerobic na moduł, dzięki któremu będę mógł lepiej zarządzać moją infrastrukturą i połączyć OVH i Digital Ocean. Na początek przybliżymy sobie kilka pojęć: - Artykuł możesz przeczytać lub posłuchać - materiał dostępny na youtube. Co tu się odterraformowało... Na początek by móc dodać moduły do mojej konfiguracji i go obsłużyć, muszę usunąć obecny stan konfiguracji. Dlaczego muszę to zrobić - już wyjaśniam. Gdybym pozostawił stan terraforma i obecna konfigurację przeniósł do modułu czyli do podkatalogu modules i do mojego podkatalogów (./modules/myovh) - to terreform tą zmianę wykryłby jako nowe rekordy które, chcę dodać - a mi zależy na tym by one zostały wciągnięte bez zmiany mojego stanu w OVH. Nie chcę robić żadnej modyfikacji. Co zatem powinienem zrobić? Może przykład lepiej to zademonstruje: Mój obecny stan z poprzedniego materiału wywołujemy go po przez polecenie terraform state list - jest to polecenie które pokaże Ci aktualny stan w backendzie - czytaj w pliku ze stanem. Backendów możemy mieć kilka rodzaji, ja osobiście mam w bazie danych postgreSQL. terraform state list Polecenie terraform plan, mówi mi że wszystko jest okej i mój stan trzymany w backend zgadza się z tym w plikach konfiguracyjnych, a zatem nie dokonuje żadnej modyfikacji czy zmiany na plus lub minus. W samym terraform mamy zmiany rozróżniane jako: dodanie - jest to zawsze nowy zasób zmiana - jest to zmiana aktualnego zasobu usuwanie - jest to usunięcie zasobu - nie będzie on już istniał Jednak gdy przeniosę moja konfiguracje (plik .auto.ftvars i providers) terraforma do głównego folderu repo a folder ovh przerobie na moduł by tylko zawierał konfigurację OVH + skrypty do importu mój stan się zmieni. Co dokładnie przeniosłem i gdzie: Do głownego katalogu tylko pliki providers i .auto.tfvars resztę tak jak była pozostawiam w katalogu ovh (którego zmienią nazwę na myovh - by uniknąć tego by moduł nazywał sie tak samo jak provider czyli ovh), a i usunę katalog .terraform ponieważ nie będzie mi on już potrzebny. Jego lokalizacja się zmieni po przez wydanie polecenia terraform init. terraform init Wydanie teraz polecenia terraform init w głownym katalogu repozytorium jest potrzebne w celu zainicjalizowania naszego terraforma oraz pobrania odpowiednich modułów i providerów do naszej konfiguracji. Inicjalizuje się tez nasz backend - widzimy więc że jest to dość ważne polecenie i zalecam wydanie jego chociaż raz na samym początku pracy z naszym repo oraz zawsze gdy dokonamy modyfikacji naszego providera, backendu i modułu. Katalog .terraform też ten jest uwzględniony w .gitignore zatem nie ma go w repo więc jest tylko plikiem tymczasowym dla mnie. Teraz moje ułożenie plików i katalogów przedstawia się w następujący sposób. Jeszcze na tym etapie nie mamy naszego modułu, ale z racji tego że zmieniliśmy ścieżkę naszej konfiguracji i teraz nie mamy informacji o naszych plikach z konfiguracją. Nasz terraform plan sugeruje że chcemy lub zamierzamy usunąć wszystkie nasze rekordy. Jeżeli wydałbym terraform apply to usunąłbym moje rekordy z konfiguracja mojej zony w OVH. Terraform nie rozumie że chcem przerobic moje zabrane informacje na moduł - muszę mu o tym powiedzieć. Spróbujmy teraz to naprawić Przygotujmy zatem nasz moduł. Przyjmuje się że moduły, które chcę stworzyć i używać w moim terraformie umieszczamy w katalogu modules. Czyli nasza ścieżka będzie wyglądać teraz tak: ./modules/myovh Używanie modułu w terraform też jest proste. Tworzę plik main.tf w którym dam informacje o tym że chcę użyć tego modułu. Czyli zaciagne informacje o moich dodatkowych plikach konfiguracyjnych mojej infrastruktury. Dodanie później kolejnego modułu na przykład z inną konfiguracja jest analogiczne, modyfikujemy tylko wartość source i nazwę dla naszego modułu. module "myovh" { source = "./modules/myovh" } Jeszcze raz wydaję polecenie terraform init i przeanalizujmy błąd który mi się pokaże. By zrozumieć ten błąd należy pamiętać że, terraform używa modułu i ściąga do niego providera na bazie tego co opiszesz w pliku provider w module - tak moduły są niezależne i muszą mieć podanego providera. Choć dobrze on tu podpowiada jak widać na zrzucie ekranu wyżej to nie szuka go w ścieżce dostępnych providerów ovh/ovh tylko hashicorp/ovh i takiego providera po prostu nie ma. Nie pozostaje nam nic innego jak wskazać mu tego providera. Dodajemy informacje w pliku provider z poziomu katalogu modułu (w jego katalogu) - czyli ./modules/myovh terraform { required_providers { ovh = { source = "ovh/ovh" } } } Taka ciekawostka jeszcze taka - że informacje o samym provider możemy przekazać przez moduł w jego inicjalizacja w naszym pliku main.tf ale o tym w innym materiale. Teraz dzięki tym informacja polecenie terraform init wykona się bez problemu. Nasz moduł już funkcjonuje i działa o czym zaraz się przekonany wydając polecenie terraform plan. Dzieje się tak dlatego że nasze rekordy mają inną konfigurację w stanie a widać to dobrze na tych dwóch zrzutach ekranu poniżej. Widzimy że w naszym stanie nasze rekordy (zasoby), wpisy maja inna nazwę poczatkową - ovh_domin_zone_rekord.... - w stanie w naszym backend a te z modułu module.myovh.ovh_domain_zone_record... Mała różnica a jaka znacząca. I dlatego terraform plan chce byśmy 23 zasoby dodali i 23 usunęli. Można powiedzieć wszystko się zgadza ale nie do końca. Będzie to zmiana i nasze zony będą miały już inne ID. Plus takie majstrowanie mogłoby zaburzyć dobre rozpoznawanie naszego DNS przez inne DNS. I spowodować chwilowy down time naszych stron czy serwisów działających na konfigurowanej strefie DNS. Plus zależy nam na imporcie a nie usuwaniu i tworzeniu nowych rekordów. Dlatego musimy to naprawić. Usuwamy zatem nasz stan by nasza operacja usuwania zniknęła. I pozostanie nam tylko raz jeszcze zaimportować aktualny stan naszej zony do stanu poprzez nasz skrypt co robiliśmy w poprzednim materiale z mała delikatną zminą Jedyne co pewne w IT to zmiana terraform state rm $(terraform state list) Wydanie tego polecenia usunie nasze rekordy ze stanu z naszego backendu i będziemy mogli zaimportować nasz stan z naszego modułu i podmapować istniejącą konfigurację z naszej strefy DNS w OVH. Tak jak wspomniałem musimy lekko zmodyfikować nasz skrypt do importu istniejącej konfiguracji z OVH i przetłumaczyć go na terraforma. Drobne modyfikacje tylko w naszych plikach *.sh tak by kontekst w skryptach się zmienił i dalej dobrze importował nasz stan. Wywołanie teraz naszego skryptu bedzie w postaci ./modules//00_generate_tf.sh Uruchamiamy nasz skrypt i po zakończeniu jego działania wydajemy polecenie terraform plan. Ukazuje nam się informacja że nie ma zmian w naszej infrastrukturze. Jest to dla nas dobra informacja. Mamy konfigurację z OVH w pliku terraform i jest ona dobrze zaimportowana. Tak teraz przedstawia się wygląd mojej struktury katalogów i plików w repozytorium. Zakończenie W tym wpisie to wszystko - w następnym materiale dodamy sobie jeszcze coś z digitalocean i tchneimy bardziej namacalne życie w moja konfigurację. Daj znać co myslisz o wpisie. Pozdrawiam do usłyszenia.

Projekt KDE ogłosił dzisiaj wydanie pakietu oprogramowania KDE Gear 22.12 dla środowiska graficznego KDE Plasma i innych projektów z wieloma ulepszeniami dla różnych aplikacji. KDE Gear 22.12 zastępuje pakiet oprogramowania KDE Gear 22.08 i wprowadza ulepszenia do menedżera plików Dolphin z możliwością zdalnego zarządzania uprawnieniami, nową funkcją o nazwie Tryb wyboru, która ułatwia szybkie i łatwe wybieranie plików, z którymi chcesz pracować, wraz z nowym paskiem narzędzi u dołu widoku z różnymi opcjami tego, co możesz zrobić z wybranymi plikami. Aplikacja przeglądarki obrazów Gwenview otrzymała możliwość dostosowywania jasności, kontrastu i gamma obrazów podczas ich przeglądania oraz możliwość otwierania plików .xcf utworzonych za pomocą edytora obrazów GIMP, edytory tekstu Kate i KWrite mają teraz okno powitalne , które ułatwia tworzenie nowych plików lub otwieranie istniejących, a także nowe narzędzie Makro klawiatury, które można aktywować w Ustawienia > Konfiguruj Kate… > Wtyczki. Edytor wideo Kdenlive jest teraz wyposażony w ulepszony system przewodników/znaczników z niestandardowymi kategoriami i filtrami wyszukiwania, ulepszoną integrację z innymi aplikacjami wideo oraz możliwość wysyłania osi czasu Kdenlive jako tła do narzędzia animacji wektorowej Glaxnimate. Poza tym odtwarzacz muzyczny Elisa jest teraz wyposażony w prawdziwy tryb pełnoekranowy i monituje komunikatem wyjaśniającym, co nie zadziałało podczas przeciągania i upuszczania pliku innego niż audio na jego listę odtwarzania, widżet KDE Connect otrzymuje wbudowane pole tekstowe aby wygodniej było odbierać telefon podczas pracy na komputerze, a aplikacja Kalendar ma teraz nowy „podstawowy” tryb widoków. Ponadto emulator terminala Konsoli lepiej dostosowuje się teraz do rozdzielczości ekranu podczas uruchamiania aplikacji po zmianie układu ekranu, klient poczty e-mail Kmail ułatwia szyfrowanie wiadomości e-mail, menedżer archiwów Ark obsługuje teraz archiwa ARJ, narzędzie do zrzutów ekranu Spectacle zapamiętuje teraz domyślnie ostatnio wybrany prostokątny obszar regionu, a asystent podróży Kitinerary obsługuje teraz łodzie i promy. Oczywiście aktualizacja KDE Gear 22.12 zawiera wiele innych mniejszych zmian i poprawek błędów, więc zawsze możesz przestudiować pełny dziennik zmian , aby uzyskać więcej informacji. W międzyczasie miej oko na stabilne repozytoria oprogramowania swojej ulubionej dystrybucji GNU/Linux dla pakietów 22.12 i aktualizuj swoje instalacje do nowych wersji aplikacji KDE, aby uzyskać lepsze wrażenia. Pakiet oprogramowania KDE Gear 22.12 będzie obsługiwany do marca 2023 r. trzema aktualizacjami konserwacyjnymi. Pierwsza, KDE Gear 22.12.1, spodziewana jest w przyszłym roku 5 stycznia, druga, KDE Gear 22.12.2, pojawi się 2 lutego, a trzecia i ostatnia, KDE Gear 22.12.3, zaplanowana jest na marzec 2. 2023. Żródło: https://kde.org/pl/announcements/gear/22.12.0/

Projekt KDE wydał KDE Frameworks 5.101 jako nową comiesięczną aktualizację tej kolekcji open-source zawierającej ponad 80 bibliotek dodatków, zapewniających powszechnie potrzebną funkcjonalność środowiska graficznego KDE Plasma i powiązanych aplikacji. Depcząc po piętach KDE Gear 22.12 , wydanie KDE Frameworks 5.101 ułatwia tworzenie i konfigurowanie zmiennych środowiskowych dla aplikacji w oknie dialogowym właściwości i KMenuEdit, funkcji, która pojawi się również w nadchodzącej serii środowisk graficznych KDE Plasma 5.27, nowa ikona dla aplikacji SimpleScreenRecorder w motywie Breeze Icon, a także większy promień narożnika w wyskakujących okienkach plazmowych z motywem Breeze, aby dopasować promień narożnika okien. KDE Frameworks 5.101 aktualizuje również separator na różnych przewijanych stronach ustawień systemowych nad przyciskami stopki, aby pasował do separatora znajdującego się nad przyciskiem „Podświetl zmienione ustawienia” w stopce paska bocznego, poprawia wydajność i szybkość rysowania elementów interfejsu użytkownika na pulpicie Plazmy i QtQuick oparte na aplikacjach w celu zmniejszenia zużycia energii i usuwa sekcję „Wyszukaj” w panelu Dolphin's Places. The questionably useful “Search For” section in the Places panel has been removed by default to avoid presenting so much visual clutter by default. The functionality is still available and you can re-add these items if you like and use them, of course,” explains renowned KDE developer Nate Graham. Poza tym KDE Frameworks 5.101 poprawia sesję Plasma Wayland , dzięki czemu okna aplikacji natychmiast dostosowują się do prawidłowego wyświetlania bez rozmycia lub pikselizacji podczas przeciągania okna zawierającego elementy interfejsu użytkownika oparte na QtQuick na inny ekran (w konfiguracjach z wieloma monitorami) z innym współczynnikiem skali. Działa nawet wtedy, gdy okno przechodzi między ekranami. W wydaniu KDE Frameworks 5.101 uwzględniono ponad 180 zmian, więc sprawdź stronę ogłoszenia , jeśli szukasz konkretnej zmiany lub interesują Cię szczegóły techniczne. W międzyczasie upewnij się, że masz oko na stabilne repozytoria oprogramowania swojej dystrybucji GNU/Linux i aktualizuj do pakietów 5.101, zwłaszcza jeśli używasz aplikacji Plasma na komputer lub KDE.

Dostawca sprzętu Linux System76 ogłosił dziś nową generację konfigurowanej klawiatury Launch, Launch Heavy, która zawiera nowe funkcje i jest pełnowymiarowa. Siedem miesięcy po premierze klawiatury Launch i pięć miesięcy po premierze klawiatury Launch Lite , System76 przygotował dla nas wszystkich miły prezent świąteczny, klawiaturę Launch Heavy, nowy model w pełnym rozmiarze i z nowymi funkcjami. Oprócz pełnowymiarowej klawiatury, pierwszej w swojej generacji, klawiatura Launch Heavy jest wyposażona w 105 klawiszy, w tym rząd funkcji, a także dodatkowe klawisze, w tym z logo System76, logo Pop!_OS, rakietą i robotem jako alternatywny projekt dla klawisza Super lub innego wybranego przez ciebie klawisza. Klawiatura Launch Heavy jest również wyposażona w dzieloną spację, która obejmuje dwa klawisze 2U, Wreszcie, nowa klawiatura Launch jest w pełni open source, podobnie jak jej mniejsze rodzeństwo, co oznacza, że ​​użytkownicy mają bezpłatny dostęp online do schematów obudowy frezowanej w aluminium i niestandardowej płytki drukowanej, wraz z kodem źródłowym Konfiguratora klawiatury System76 (aplikacja), która umożliwia tworzenie mapowań dla klawiszy. Osoby zainteresowane zakupem w pełni konfigurowanej klawiatury typu open source mogą już teraz zakupić klawiaturę Launch Heavy ze strony internetowej System76 . Cena tego modelu zaczyna się od 299 USD i może wzrosnąć do 334 USD z 3-letnią gwarancją. Plus transport do Polski to 160 USD dodatkowe za przesyłkę DHL. - Drogi prezent <3.

Jak pisze Fortinet A heap-based buffer overflow vulnerability [CWE-122] in FortiOS SSL-VPN may allow a remote unauthenticated attacker to execute arbitrary code or commands via specifically crafted requests. Jak widać wykorzystanie luki nie wymaga uwierzytelnienia, a napastnik otrzymuje możliwość wykonywania poleceń na atakowanym urządzeniu. Fortinet is aware of an instance where this vulnerability was exploited in the wild, and recommends immediately validating your systems against the following indicators of compromise (…) Podatność jest aktywnie wykorzystywana, więc prawdopodobnie był to 0-day. Podatne wersje FortiOS: FortiOS version 7.2.0 through 7.2.2 FortiOS version 7.0.0 through 7.0.8 FortiOS version 6.4.0 through 6.4.10 FortiOS version 6.2.0 through 6.2.11 FortiOS-6K7K version 7.0.0 through 7.0.7 FortiOS-6K7K version 6.4.0 through 6.4.9 FortiOS-6K7K version 6.2.0 through 6.2.11 FortiOS-6K7K version 6.0.0 through 6.0.14

AWS Cloud Practitioner Essentials Day | Dec12 - tutaj rejestracja start już w poniedziałek trwa od 10:00 do 18:00 CET. i od MicroSoft - tutaj dostępne - wymagane konto MS - do założenia za darmo.

Offensive Security ogłosiło dzisiaj wydanie i powszechną dostępność Kali Linux 2022.4 jako najnowszej stabilnej aktualizacji tej opartej na Debianie dystrybucji GNU/Linux dla etycznych hakerów i testów penetracyjnych. Wydanie Kali Linux 2022.4, które pojawi się prawie cztery miesiące po wydaniu Kali Linux 2022.3 , jest pierwszym z serii Kali Linux 2022, które dodaje obsługę najnowszej i najlepszej serii jądra Linuksa 6.0. Oznacza to, że Kali Linux powinien teraz działać i obsługiwać więcej sprzętu, jeśli używasz najnowszych obrazów ISO. Podczas gdy Kali Linux trzyma się lekkiego środowiska graficznego Xfce jako domyślnej sesji graficznej dla żywych ISO, wersja Kali Linux 2022.4 zapewnia również obsługę najnowszych środowisk graficznych GNOME 43 i KDE Plasma 5.26 . Kolejną ekscytującą atrakcją tej nowej wersji Kali Linux jest oficjalne wsparcie dla smartfonów PinePhone i PinePhone Pro firmy Pine64 dzięki wprowadzeniu Kali NetHunter Pro, prostej instalacji Kali Linux zoptymalizowanej pod kątem urządzeń mobilnych i zawierającej oparte na GNOME środowisko graficzne Phosh firmy domyślna. Kali Linux to etyczna dystrybucja do hakowania i testów penetracyjnych, więc nowa wersja wprowadza kilka nowych narzędzi, w tym oparty na języku Python bloodhound.py moduł do pobierania dla BloodHound, narzędzie certipy do wyliczania i nadużyć certyfikatów w usłudze Active Directory, hak5-wifi-coconut user- space driver dla kart USB Wi-Fi NIC i Hak5 Wi-Fi Coconut, ldapdomaindump Active Directory - zrzutnik informacji za pośrednictwem LDAP, narzędzia do eskalacji uprawnień rizin-cutter platforma inżynierii wstecznej. Wśród innych godnych uwagi zmian, Kali Linux 2022.4 wprowadza wstępnie wygenerowany obraz QEMU dla tych, którzy używają samodzielnie hostowanych środowisk wirtualnych Proxmox (VE), virt-manager lub libvirt, ulepszona obsługa ARM z poprawkami dla USB Mk II, ODROID-C2 i Radxa Zero oraz wewnętrzną obsługę Bluetooth dla Kali NetHunter. Możesz pobrać Kali Linux 2022.4 już teraz z oficjalnej strony internetowej . Te nowe obrazy są tutaj głównie dla tych, którzy chcą wdrożyć Kali Linux na nowych komputerach lub ponownie zainstalować. Istniejący użytkownicy Kali Linux muszą jedynie zaktualizować swoje instalacje, uruchamiając polecenia sudo apt update && sudo apt full-upgrade.