CCIE.pl

Ja to tylko tutaj zostawie...

https://www.linkedin.com/pulse/heres-ho ... title-like

a ktos na tym forum krzyczał jaki to Juniper jest dziurawy ...

pk pisze:a ktos na tym forum krzyczał jaki to Juniper jest dziurawy ...

Jedna uwaga. Jak sam zauważyłeś "Juniper jest", natomiast PIX "był" bo to technologia sprzed dekady. To, że ktoś jeszcze tego używa, to już inna historia.

Śmiem twierdzić, że oni mają exploity dla urządzeń na niemalże każdego dostawcy. A to co wyciekło to tylko jakieś stare rzeczy. Zwłascza, że proces produkcji oprogramowania znacznie przyspieszył, ale wcale nie poprawiło to jego jakości i bezpieczeństwa przez to.

Kyniu pisze: Jedna uwaga. Jak sam zauważyłeś "Juniper jest", natomiast PIX "był" bo to technologia sprzed dekady. To, że ktoś jeszcze tego używa, to już inna historia.

no wlasnie, jest i bedzie dziurawy i jeszcze zupelnie nic z tym nie robia, kurcze, taka firma ehh

pk pisze:a ktos na tym forum krzyczał jaki to Juniper jest dziurawy ;) ...

Co innego dac sobie wsadzic szpiega(-ów?) do firmy, ktory wstawia backdoory (ile ich jeszcze jest w Juniperze? skoro w krotkim odstepie czasu wyszly takie rzeczy?) a co innego exploitowac roznego rodzaju bledy. To roznica miedzy bledem systemowym, w ktorym firma nie panuje nad swoim kodem i bledem typowym, ktory po prostu sie zdarza - wszystkim.

Od czasow wczesnego kodu PIXa z kazdym wydaniem proces badania jakosci kodu byl u nas udoskonalany do badania roznego rodzaju technikami. Od paru lat wspolpracujemy z paroma znajacymi sie na rzeczy ludzmi od testow hardeningowych i penetracyjnych w procesie CSDL - w tym co najmniej z dwoma z Polski. To nie jest prosty biznes a mniejsze firmy po prostu często na to nie stać - porównajcie łączny obrót wspomnianego Junipera vs samą działkę bezpieczeństwa u nas.

Wiec troche to inna bajka - a o tych exploitach bylo juz wiadomo pare lat temu po wyciekach Snowdena. Tylko nikt nie widzial kodu. No wiec kod juz jest, dotykal rowniez starych wersji ASA (7.x i 8.x). AFAIK nie ma niczego dotykajacego linii 9.x, glownie rzeczy zwiazane z SNMP i ASN.1.

Pełne advisory jest tutaj: http://tools.cisco.com/security/center/ ... =ERP-56516

Cisco, Fortinet, Juniper... jeden grzyb
https://niebezpiecznik.pl/post/nsa-zhac ... ka-rosjan/
W zasadzie to najbezpieczniej czuję się gdy stawiam jakieś rzadziej używane narzęcie na Linux-ie. Fakt narobię się przy tym, nie mam wsparcia, ale jest mniejsza szansa, że ktoś użyje gotowego exploita, że moje zabezpieczenia są typowe a i sam lepiej je znam, bo się nadziobałem przy ich konfiguracji
Choć wiadomo, to tylko łechtanie samego siebie - jak będą chcieli to znajdą sposób

Kyniu pisze:

pk pisze:a ktos na tym forum krzyczał jaki to Juniper jest dziurawy ...

Jedna uwaga. Jak sam zauważyłeś "Juniper jest", natomiast PIX "był" bo to technologia sprzed dekady. To, że ktoś jeszcze tego używa, to już inna historia.

Szczególnie, że w tamtej dyskusji poruszano problem urządzeń ze ScreenOS (poszukaj sobie kiedy dokładnie je zaprzestano produkować).

lbromirs pisze:
Co innego dac sobie wsadzic szpiega(-ów?)...

Akurat tutaj fakt wielkosci nie jest atutem, bo po co eksplojtowac jakiegos malego vendora, skoro wszyscy uzywaja tego duzego, powszechnego. Druga sprawa, to wsadzenie szpiega do malej firmy jest o wiele trudniejsze, niz gdzies gdzie sa cale tabuny inzynierow programistow. Tam moze i nawet caly team jest latwiej wprowadzic. Co do badania jakosci kodu, to zapewne jest to kosztowne, lecz nie zawsze gwarantuje sukces. Najbezpieczniejsi jestesmy wtedy kiedy korzystamy ze sprzetu zaprzyjaznionego producenta, w ktorym siedza nasze 'implanty', dlatego Chiny maja swojego vendora, a Korea swojego etc. Trzeba mocno sie napracowac zeby te furtki ukryc i ktos niepowolany ich nie znalazl. A jak czasem cos znajda, to sie oglasza, ze to normalny bug/security advisory, kazdemu moze sie zdarzyc. Taka jest moja teoria spiskowa

rysic pisze:Cisco, Fortinet, Juniper... jeden grzyb ;-)
https://niebezpiecznik.pl/post/nsa-zhac ... ka-rosjan/
W zasadzie to najbezpieczniej czuję się gdy stawiam jakieś rzadziej używane narzęcie na Linux-ie. Fakt narobię się przy tym, nie mam wsparcia, ale jest mniejsza szansa, że ktoś użyje gotowego exploita, że moje zabezpieczenia są typowe a i sam lepiej je znam, bo się nadziobałem przy ich konfiguracji :-)

Nie wiem czy tak Ci wygodnie, czy jest to związane z niewiedzą, ale Linux (nad czym ubolewam) to nie jest już system sprzed 20 lat, o którym wiedziało parę osób, a potrafiło coś zrobić poza kompilowaniem w kółko jądra jeszcze mniej. Bardzo dużo różnego malware'u roznosi się przez zarażone maszyny Linuksowe, więc koncepcje w ramach których "security by obscurity bo przecież nikt za mną nie trafi" zapewniają Ci jakieś szczególne bezpieczeństwo, są lekko rozjechane z rzeczywistością.

Swoją drogą, do Linuxa też NSA próbowała dobrać się przez samego Linusa, co ostatnio potwierdził. Ile mają obecnie linii kody źródłowe do samego kernela? 16.7M. Ogromna powierzchnia ataku. A do tego dochodzą dziury w słuchających (i nie słuchających) demonach, syfie typu PHP, czy też w firmware (jak to ostatnio z ARMem było). Musiałbyś być naprawdę cennym celem, żeby komuś chciało się pisać coś specjalnie dla Ciebie. Załatwi Cię (najprawdopodobniej) automat i jest duża szansa, że nawet o tym nie będziesz wiedział przez długi czas. Firmy w Polsce zatrudniające wielu specjalistów, budujące NOCi i dłubiące w logach są zaskoczone, gdy wyciągamy im robaka sprzed paru/parunastu miesięcy i pokazujemy co zrobił. Wstyd o tym mówić publicznie i opisywać własne potknięcia - ale bezpieczeńswo to już od dawna nie jest piaskownica z iptables, ssh na wysokim porcie i demonem obsługującym port knocking.

Oczywiście, prywatne odczucia są bardzo ważne, ale jeśli robisz to dla kogoś w ramach pracy, warto żeby znał ryzyko i Twoje założenia przyjęte w trakcie budowy takich systemów. Każdy z nas ma przecież prawo do własnego szaleństwa :)

Co nie znaczy oczywiście, że to gorzej/lepiej niż sytuacja w której znajduje się backdoory czy dziury w rozwiązaniach komercyjnych (też czasem na bazie Linuxa budowanymi). Odnoszę się tylko do Twojego niebezpiecznego założenia, że skoro sam dłubiesz, to będzie bezpieczniej. Nie będzie.

Miałem raczej na myśli narzędzia oparte na Linuchu - jak np. OpenVPN. Generalnie jeśli wszystko robisz z głową, to moim zdaniem jesteś w stanie lepiej to zabezpieczyć niż w rozwiązaniach gotowych - zamkniętych lśniących pudełkach od wielkich producentów.

Aczkolwiek przyznaję - nie robię tak w środowiskach produkcyjnych. Nie ze względu na poziom bezpieczeństwa, ale ze względu na poziom odpowiedzialności. Gdy ktoś złamie zabezpieczenia, które sam od dłuższego czasu opracowywałem i wdrażałem, to ja jestem winny, ja szukam rozwiązań i ja dostaję po głowie. Gdy ktoś złamie systemy dostarczone od producenta, który dostarcza nam gotowe rozwiązania a najlepiej sam lub przez partnera świadczy wsparcie, to ja zwalam wszystko na nich i dodatkowo oni wspierają mnie i moją firmę w dochodzeniu jak cały atak przebiegał, jak to załatać, jak na przyszłość uniknąć, przygotowują gotowe raporty, które przedstawiam szefom

Fakt, Linux ma sporo linii kodu, ale zobacz też ile osób go codziennie przegląda czyta i poprawia.

A swoją drogą, jeśli nie popełnisz jakiegoś ewidentnego błędu, to czy rzeczywiście wystawienie OpenSSH na świat jest rzeczywiście niebezpieczne? Nawet bez port knockingu.

rysic pisze:Miałem raczej na myśli narzędzia oparte na Linuchu - jak np. OpenVPN. Generalnie jeśli wszystko robisz z głową, to moim zdaniem jesteś w stanie lepiej to zabezpieczyć niż w rozwiązaniach gotowych - zamkniętych lśniących pudełkach od wielkich producentów.

Ulegasz niebezpiecznym iluzjom.

rysic pisze:Fakt, Linux ma sporo linii kodu, ale zobacz też ile osób go codziennie przegląda czyta i poprawia.

Ulegasz niebezpiecznym iluzjom i w dodatku mitom.

rysic pisze:A swoją drogą, jeśli nie popełnisz jakiegoś ewidentnego błędu, to czy rzeczywiście wystawienie OpenSSH na świat jest rzeczywiście niebezpieczne? Nawet bez port knockingu.

Oczywiście. Wystarczy wrzucić do Google'a "openssh remote exploit" i zobaczyć jak bardzo jest bezpieczny.

Polecam ten rysunek. Naprawdę warto czasem pochylić głowę w pokorze i dobrze zastanowić się nad fundamentami swoich głębokich przekonań :)

No dobrze, to jakie rozwiązanie byś polecił jako w pełni bezpieczne i zabezpieczające? Przypuszczam, że możesz polecić lepsze i gorsze, ale nigdy nie będziesz miał 100% pewności.

Możemy tylko dążyć do doskonałości i zabezpieczać się z każdej strony tak aby w razie kuku mieć wytłumaczenie przed sądem Generalnie w ramach budżetu i czasu którym dysponujemy dążymy do granicy w której łatwiej/taniej kogoś przekupić niż hackować naszą sieć

"openssh remote exploir" - not to przecież napisałem, że nie robiąc fundamentalnych błędów i nie aktualizując systemu

Naprawdę warto czasem pochylić głowę w pokorze i dobrze zastanowić się nad fundamentami swoich głębokich przekonań

To nie jest tak, że ja ślepo wierzę w bezpieczeństwo tego czy tamtego. Tak samo jak przy każdym innym rozwiązaniu - trzeba zastosować wiele różnych podejść do bezpieczeństwa i wdrożyć go czasem nawet kilkukrotnie dla jednej usługi, żeby podwyższyć swoją pewność... a później dotkliwiej się rozczarować Życie...

rysic pisze:No dobrze, to jakie rozwiązanie byś polecił jako w pełni bezpieczne i zabezpieczające?

Nie ma czegoś takiego.

rysic pisze:Przypuszczam, że możesz polecić lepsze i gorsze, ale nigdy nie będziesz miał 100% pewności.

Dzisiaj jedynym sposobem na zwiększenie bezpieczeństwa po zbudowaniu z tradycyjnych firewallowo/IPSowych/AMPowych/VPNowych rozwiązań jest oparcie się o chmurę i analitykę/badania prowadzone w prawie czasie rzeczywistym - najczęściej poza własną firmą przez wszechstronne zespoły specjalistów - od malware'u na x86, na Windowsy, na Androida, na iOSa... specjalizacja jest konieczna i bardzo głęboka. Po prostu bezpieczeństwo to już nie zabawa dla pojedynczych badaczy tylko wielkich społeczności. Czym więcej producent ma dzisiaj dostępu do danych oraz czym więcej może zainwestować w duże zespoły ludzkie tym większą masz szansę, że zatrzyma Ci atak przed nosem, lub w rozsądnym czasie po jego rozpoczęciu.

Cisco ma dzisiaj największy zespół (a właściwie cztery różne zespoły nie licząc Ciscowego SOCa w Krakowie prowadzonego przez Gawła), najwięcej danych zbieramy i najwszechstronniej je analizujemy. To powinno dawać najlepsze rezultaty - ale to zawsze gra w prawdopodobieństwa - czasem bardzo kosztowna. Podobnie budują swoje zespoły konkurenci - FireEye czy Palo Alto, pozostali dostawcy 'appliance' powoli znikają z obrazka. To jednak nieporównywalnie mniejsza skala, choć czasem zdarza się, że coś bardziej specjalizowanego wydłubią i oznaczą inne zespoły (choćby McAfee czy Kaspersky) - warto mieć otwartą główę, rozglądać się szeroko - w szczególności jeśli to Twoja praca. A specjalizować się w tym, co Twojej firmy ma szansę dotknąć z największym prawdopodobieństwem, unikając fałszywego przekonania, że skoro widziałeś jeden malware na Windowsy, wiesz już wszystko.

Ja np. w ogóle mam mgliste pojęcie o atakach na aplikacje dzisiaj mimo tego, że znam dobrze assembler x86, C i radzę sobie z debuggingiem. To dramatycznie głęboka i szeroka działka. To samo - serwisy WWW. W polskich firmach bardzo często całość ogromnego spektrum wektorów ataku próbuje ogarnąć zespół dwóch-trzech specjalistów. I choćby nie wiem jak się trudzili... no właśnie.

Jeśli to Cię interesuje - warto zajrzeć na blogi naszych rodaków dłubiących dla Google'a w Szwajcarii, j00ru czy też Travisa Normandy, który ostatnio zaczął zabierać się za 'appliance' bezpieczeństwa, ale raczej w kontekście ich hardeningu niż całościowej oceny danej platformy. Prawdopodobnie oznacza to, że Google też pracuje nad swoim rozwiązaniem.

No tak, byłem na prezentacjach wszystkich trzech graczy. Każdy zwie to firewallem nowej generacji Każdy uważa, że więcej wykrywa w swojej chmurze a konkurencja czegoś tam nie wykryła
A co do badań w prawie czasie rzeczywistym - to jeśli dobrze zrozumiałem polega raczej na tym, że analizujemy i szukamy sygnatur, które już znamy, ale też wysyłamy do chmury i w razie czego staramy się odkręcić co szkodnik już narobił. Zabawne jest jednak to, że szkodniki już ewoluowały to sprawdzenia przed działaniem, czy przypadkiem nie zostały wysłane gdzieś do chmury
Ciekawy blog, dzięki!