Zauważyłem, że w niektórych bankach długość kodu jednorazowego (SMS) używanego do autoryzacji transakcji została wydłużona. Chętnie poznałbym uzasadnienie takiej decyzji – dlaczego 8 cyfr ma być bezpieczniejsze niż 6. W praktyce, a nie w jakiejś teorii. Bo jeśli chodzi o teorię...
Muszę przyznać, że dziwnie się czuję rozmawiając o arp poisoning i różnym zachowaniu Windows i Linux w kontekście komendy arp -s (swoją drogą muszę sprawdzić jak zachowują się w tym przypadku Windowsy nowsze niż XP), różnicami w reasemblacji pakietów albo manipulacji TTL w kontekście unikania IDS/IPS.
Ja uczyłem się od podstaw, z nieśmiertelnej Biblii TCP/IP. Ponieważ wiem (mniej więcej) jak to działa, te pomysły są dla mnie zrozumiałe (w zasadzie każdy mając taką wiedzę może na to wpaść). Mam jednak wrażenie, że w tej chwili dominuje podejście od drugiej strony, od strony narzędzi/rozwiązań. Ludzie są uczeni, że jeśli wydadzą takie magiczne polecenie, to są bezpieczni. Nie rozumieją jednak do końca na czym polega problem i jak jest w danym przypadku rozwiązywany. I właśnie to powoduje, że czuję się dziwnie.
PS: No dobra, może i z tej książki nie nauczysz się na czym polegają optymalizacje w obsłudze[arp who-has](http://en.wikipedia.org/wiki/AddressResolutionProtocol), ale z drugiej strony będziesz w stanie sam się domyślić dlaczego system otrzymujący takie zapytanie aktualizuje swoją tablicę arp.
By zobrazować to lepiej – dlaczego 172.16.0.6 odpowiedział 172.16.0.128 skoro wcześniej nie zapytał jaki jest adres MAC dla tego adresu?
30516 91.105464000 Microsofd1:3c:14 Broadcast ARP 60 Who has 172.16.0.6? Tell 172.16.0.128
30517 91.105507000 IntelCorca:c2:74 Microsof_d1:3c:14 ARP 42 172.16.0.6 is at 00:16:ea:ca:c2:74
30518 91.106570000 172.16.0.128 172.16.0.6 ICMP 98 Echo (ping) request id=0x2cc6, seq=1/256, ttl=64 (reply in 30519)
30519 91.106884000 172.16.0.6 172.16.0.128 ICMP 98 Echo (ping) reply id=0x2cc6, seq=1/256, ttl=128 (request in 30518)
Oryginał tego wpisu dostępny jest pod adresem Old School
Kontynuacja poprzedniego wpisu. Tym razem na temat jednego z typowych argumentów wykorzystywanych przez biznes: “a bo oni mają (...) i jakoś żyją”. Oczywiście wszystko dalej w kontekście bezpieczeństwa.
Jako wpływowy (sic!) blogger od czasu do czasu otrzymuję propozycje, nazwijmy to, “marketingowe”. Zwykle je ignoruje i nawet o nich nie wspominam, ale tym razem robię wyjątek od tej reguły. Tym razem chodzi o Sofort Banking.
Zbliża się 8 kwietnia. Dzień, w którym udostępniony zostanie pakiet Windows 8.1 Update 1. Patrząc na zapowiedzi można odnieść wrażenie, że najważniejszą zmianą będzie przywrócenie Start Menu. Cóż, mnie jakoś specjalnie go nie brakuje.
Różne obszary mózgu aktywują się w zależności od tego, czy słuchamy muzyki instrumentalnej, czy z wokalem. Jako tło do pracy preferuję muzykę instrumentalną lub dźwięki natury, tak by się odciąć od otoczenia. Ale... płyta Big CalmMorcheeby jakoś jest wyjątkiem od tej reguły i dobrze mi wchodzi.
P.S. Z tą muzyką instrumentalną to też różnie bywa. Na przykład Marty Friedman, takie Scenes lub Introduction są OK, ale już Draon's Kiss na tło się nie nadaje. Muszę też sprawdzić Bolero, Canon in D jest dla mnie chyba trochę za skomplikowany (w tym kontekście).
Oryginał tego wpisu dostępny jest pod adresem Muzyka do pracy
Właśnie wróciłem ze spotkania Infosec Kraków. Muszę przyznać, że spotkanie inauguracyjne wypadło wyjątkowo dobrze, oby tak dalej. Zaangażowanie i pomysły organizatorów pozwalają oczekiwać, że dalej będzie równie dobrze.
Bardzo podoba mi się pomysł warsztatów i hackathonów. Na taki warsztat z SELinuxa chętnie bym się wybrał :) Kto wie, może również jakiś warsztat sam bym przygotował?
Z innych wieści – nadchodzi SEConference 2014, też warto o tym wydarzeniu pamiętać.
W najbliższy czwartek (13 marca) odbędzie się pierwsze spotkanie InfoSec Kraków. Tak się zupełnie przypadkiem składa, że będę się na nim produkował. Mniej więcej już mam wizję tego, co chcę powiedzieć, teraz powoli będzie to musiało nabrać kształtów.
Oryginał tego wpisu dostępny jest pod adresem InfoSec Kraków