Forum Debian Users Gang

mrmarkos napisał(-a):

z określonych MAC adresów kart sieciowych

Uprzedzam: jestem laikiem, ale to może być niewykonalne.

Zdecydowanie łatwiej będzie określone IP (deny i allow w .htaccess).

Niewykonalne. I MAC jest tylko tam, gdzie masz IEEE 802.x i widoczny jest tylko w obrębie switch'a. I działa tylko na L2 (chyba, że zrobisz VPN :) albo inne cudo, gdzie jest Ethernet-over-IP).

Ale jak masz dostęp po ssh, to możesz zestawiać tunel po ssh*, do localhosta, zaś w konfiguracja Apacha (jeśli masz takie możliwości) ustawić, by dostęp do panelu (czyli pewnie jakiegoś katalogu) był możliwy tylko z localhosta.

A ci klienci bankowi to pewnie byli by podpięci bezpośrednio do switcha gdzie stał bank :)

* - o ile jest zgoda na robienie tuneli.

Ostatnio edytowany przez paoolo (2012-05-31 23:37:53)

@mrmarkos
MAC adres jest adresem dizycznym interfesju sieciowego - ta adresacja działa tylko w obrębie mostu lub switcha, za routerem.
Po stronie WAN routera działają adresy IP.
Wyjaśnienie warstw ISO/OSI masz na Wikipedii, wystarczy poszukać.

Co do CMSa, to napisz, jak to CMS, typu OSCommerce, Joomla, Drupal, PhpBB3, czy coś innego.

W większości można zmienić nazwę folderu Administrator  na inną,
i np pozostawienie lipnego folderu Administrator, dla skrypciarzy.

Jest też kontrola po IP w konfiguracji serwera (po IP), albo autoryzacja http, można też dostep do zaplecza schować na innym porcie (np przez ssl), i/lub chociażby dostęp do danego portu ustawić tylko przez tunel ssh/vpn.

Możliwości masz setkę, wszystko zależy od możliwości technicznych, i zawartości czaszki Administratora ;)
Prrzy okazji niestandardowe rozwiązania są dużo skuteczniejsze, od powszechnie stosowanych, ponieważ znacznie trudniej potencjalnemu skrypciarzowi odgadnać, co kryje nieszablonowa konfiguracja.

To by było na tyle
;-)

Ostatnio edytowany przez Jacekalex (2012-06-01 02:38:38)

Ale do czego właściwie ma to być zabezpieczenie i przed czym ma zabezpieczać?

Nie próbuj być świętszy od papieża. Szyfrowanie połączenia z panelem administracyjnym to już i tak więcej niż oferuje jakieś 80% mniejszych i większych stron.

Powinieneś:
1. Zmienić adres panelu administracyjnego
1a. Upewnić się, że nigdzie na stronie nie znajduje się odnośnik do panelu — wtedy 1. będzie pozbawione sensu.
2. Zmienić nazwę użytkownika z uprawnieniami administracyjnymi (z domyślnej na jakąkolwiek)

Te dwa proste zabiegi wykoszą zdecydowaną większość robotów, które mogłyby chcieć się włamać na stronę.

Idzie zrobić to poprzez htaccess albo bezpośrednio przez konfig apache'a. Zabraniasz najpierw wszystkim, później zezwalasz danym hostom. Tutaj przykładowo zezwalasz dla localhost ... możesz podać też ip itd.

<Directory "/sciezka/do/panelu/admina">
Order deny,allow
Deny from all
Allow from localhost  
</Directory>

1. ustawiłbym niestandardowy port SSL, lecz nie wiem jak to zrobić (w .htaccess ?)

Z taką wiedzą o serwerach www jeszcze duużżżżoo nauki przed Tobą.
Inny port z inną zawartością - to koniecznosć postawienia vhosta słuchającego na tym porcie, z osobną konfiguracją.
Żeby coś takiego zrobić, trzeba mieć własny serwer albo VPS.

Joonla, o ile pamiętam, ma jeden plik konfiguracyjny z danymi do bazy, więc trudniej coś sensownego wykombinować w porównaniu z Oscommerce-2.* - gdzie od razu Amdministrator może mieć inne parametry połączenia z bazą danych, niż część widoczna z netu.

Do Joomli zrobiłbym tak, żeby strona WWW miała w bazie SQL tylko uprawnienia SELECT, a częsć administracyjna pełne.

Biorąc pod uwagę, że jakieś ~40% dziur w Joomli opiera się na ataku SQL-Injection wymierzonym bezpośrednio w stronę i rozszerzenia, to jest najsensowniejsze rozwiązanie.

Folderu Administrator w ogóle możesz w tej Joomli nie mieć, możesz w strukturze folderów schować drugą Joomlę  (za autoryzacją http, innymi portamni, dostępem tylko po ssh, itp) z zapleczem administracyjnym, zapiąć ją do tej samej bazy, i zrobić dowiązaniami wspólne foldery z obrazkami, żeby przy dodawaniu artykułów wszystko się zgadzało.

W ogóle to trochę brakuje Ci doświadczenia z CMS'ami - weź trochę potestuj różne konfiguracje, pobaw się trochę narzędziami hakerskimi, typu SQLmap, nikto, skipfish, nessus.
I poczytaj trochę o atakach SQL czy XSS  na Wikipedii.

Joomla ma jeszcze jeden grzech śmiertelny, polegający na tym, że jak się wrzuci skrypt php w odpowiednią lokalizację, to jest automatycznie includowany przez całego CMS'a.

W rezultacie bardzo łatwo instalować dodatki, ale jak ktoś popieprzy uprawnienia, pozwalając samemu CMS'owi zapisywać pliki w foderach systemowych tego CMS'a, to za jakiś czas może się tam pojawić kilka dodatkowych skryptów "dopisanych" przez skrypciarzy.

Joomla jest bardzo łatwa w konfiguracji, (tak samo jak Windows 98) i przez to tak samo bezpieczna, jak Windows 98. ;)

Więc radzę się bardzo starannie dokształcić w zakresie serwerów WWW i skryptów CMS.

Pozdrawiam
;-)

Własny silnik CMS to jest to. A django Twoim przyjacielem :)

Co do wymyślnych konfiguracji zabezpieczenia połączenia - ostatnio natknąłem się na implementację RSA w JavaScript'cie :D dla hostingów współdzielonych jak znalazł :) i takich, co mają za dużo wolnego czasu :]

Jak już masz do hostingu dedykowane IP, możesz się logować po ssh (nawet bez dedykowanego IP), to spróbuj od tuneli po ssh. A jeśli już, to wspomniane VPN.

Sznurki:
http://openvpn.net/index.php/open-source/documentation/howto.html
http://wazniak.mimuw.edu.pl/index.php?title=Bezpiec … nux_i_Windows

Minio napisał(-a):

Ale do czego właściwie ma to być zabezpieczenie i przed czym ma zabezpieczać?

Nie próbuj być świętszy od papieża. Szyfrowanie połączenia z panelem administracyjnym to już i tak więcej niż oferuje jakieś 80% mniejszych i większych stron.

Powinieneś:
1. Zmienić adres panelu administracyjnego
1a. Upewnić się, że nigdzie na stronie nie znajduje się odnośnik do panelu — wtedy 1. będzie pozbawione sensu.
2. Zmienić nazwę użytkownika z uprawnieniami administracyjnymi (z domyślnej na jakąkolwiek)

Te dwa proste zabiegi wykoszą zdecydowaną większość robotów, które mogłyby chcieć się włamać na stronę.

Ma zabezpieczać przed nieautoryzowanym dostępem do panelu administracyjnego. Z tego co czytałem, to zmiana adresu panelu administracyjnego w Joomla jest kłopotliwa.

Jacekalex napisał(-a):

1. ustawiłbym niestandardowy port SSL, lecz nie wiem jak to zrobić (w .htaccess ?)

Z taką wiedzą o serwerach www jeszcze duużżżżoo nauki przed Tobą.
Inny port z inną zawartością - to koniecznosć postawienia vhosta słuchającego na tym porcie, z osobną konfiguracją.
Żeby coś takiego zrobić, trzeba mieć własny serwer albo VPS.

Dlatego wybrałem Shared Hosting w polskiej firmie z kilkunastoletnim doświadczeniem. Na VPS przyjdzie czas.

Jacekalex napisał(-a):

Joonla, o ile pamiętam, ma jeden plik konfiguracyjny z danymi do bazy, więc trudniej coś sensownego wykombinować w porównaniu z Oscommerce-2.* - gdzie od razu Amdministrator może mieć inne parametry połączenia z bazą danych, niż część widoczna z netu.

Do Joomli zrobiłbym tak, żeby strona WWW miała w bazie SQL tylko uprawnienia SELECT, a częsć administracyjna pełne.

Biorąc pod uwagę, że jakieś ~40% dziur w Joomli opiera się na ataku SQL-Injection wymierzonym bezpośrednio w stronę i rozszerzenia, to jest najsensowniejsze rozwiązanie.
Folderu Administrator w ogóle możesz w tej Joomli nie mieć, możesz w strukturze folderów schować drugą Joomlę  (za autoryzacją http, innymi portamni, dostępem tylko po ssh, itp) z zapleczem administracyjnym, zapiąć ją do tej samej bazy, i zrobić dowiązaniami wspólne foldery z obrazkami, żeby przy dodawaniu artykułów wszystko się zgadzało.
W ogóle to trochę brakuje Ci doświadczenia z CMS'ami - weź trochę potestuj różne konfiguracje, pobaw się trochę narzędziami hakerskimi, typu SQLmap, nikto, skipfish, nessus.
I poczytaj trochę o atakach SQL czy XSS  na Wikipedii.

Joomla ma jeszcze jeden grzech śmiertelny, polegający na tym, że jak się wrzuci skrypt php w odpowiednią lokalizację, to jest automatycznie includowany przez całego CMS'a.

W rezultacie bardzo łatwo instalować dodatki, ale jak ktoś popieprzy uprawnienia, pozwalając samemu CMS'owi zapisywać pliki w foderach systemowych tego CMS'a, to za jakiś czas może się tam pojawić kilka dodatkowych skryptów "dopisanych" przez skrypciarzy.

Joomla jest bardzo łatwa w konfiguracji, (tak samo jak Windows 98) i przez to tak samo bezpieczna, jak Windows 98. ;)

Więc radzę się bardzo starannie dokształcić w zakresie serwerów WWW i skryptów CMS.

Pozdrawiam
;-)

Dzięki za info i sznurki, dokształcam się właśnie, ale jak sam wiesz jest dużo wiedzy do przyswojenia, więc potrzeba czasu ;)

Piotr3ks napisał(-a):

Idzie zrobić to poprzez htaccess albo bezpośrednio przez konfig apache'a. Zabraniasz najpierw wszystkim, później zezwalasz danym hostom. Tutaj przykładowo zezwalasz dla localhost ... możesz podać też ip itd.

Kod:

<Directory "/sciezka/do/panelu/admina">
Order deny,allow
Deny from all
Allow from localhost  
</Directory>

torrentow napisał(-a):

Witam,
Zgadzam się z Towarzyszem powyższym i jeszcze musiałbyś dać tunel ssh aby przybić do localhosta np:

Kod:

ssh user@jakis.tld -D 9089

gdzie 9084 to jest port.
Wtedy wklepiesz proxy do przeglądarki na localhost i porcie 9094.
Dasz potem localhost:portpanelu i działa ;).
Pozdrawiam,
Towarzysz Torrentow

ssh user@jakis.tld -D 9089
bind: Cannot assign requested address

Zapytam hostingodawców czy da się coś zrobić w tej sprawie. Sprytne rozwiązanie, dzięki ;)

mer napisał(-a):

Nie te warstwa OSI żeby po macu szaleć, jednakowoż jak potrzebujesz bepzieczeństwa to sesje,cookie,,useragent,ip i jeszcze kilka metod jest do zabezpieczania cms'ów :)


a Joomla sama w sobie jest grzechem.

Tu muszę się dokształcić ;) Dlaczego Joomla jest grzechem ?

paoolo napisał(-a):

Własny silnik CMS to jest to. A django Twoim przyjacielem :)

Co do wymyślnych konfiguracji zabezpieczenia połączenia - ostatnio natknąłem się na implementację RSA w JavaScript'cie :D dla hostingów współdzielonych jak znalazł :) i takich, co mają za dużo wolnego czasu :]

Jak już masz do hostingu dedykowane IP, możesz się logować po ssh (nawet bez dedykowanego IP), to spróbuj od tuneli po ssh. A jeśli już, to wspomniane VPN.

Sznurki:
http://openvpn.net/index.php/open-source/documentation/howto.html
http://wazniak.mimuw.edu.pl/index.php?title=Bezpiec … nux_i_Windows

Dzięki za sznurki ;)

Jacekalex napisał(-a):

Tu muszę się dokształcić ;) Dlaczego Joomla jest grzechem ?

Dlatego, że autorzy chcieli zrobić ładny i łatwy CMS, i poszli po najmniejszej linii oporu.
Joomla w domyślnej konfiguracji w ogóle nie ma nic wspólnego z bezpieczeństwem, można ją bardzo łatwo zainstalować i skonfigurować, ale późniejsze zabezpieczanie jej, to kwadratura koła, właśnie z powodu tej początkowej łatwości.
Krótko pisząc, żeby Joomlę porządnie zabezpieczyć, trzeba ją czasami solidnie "wykastrować" bo niektóre "cudowne" funkcjonalności po prostu wykluczają bezpieczeństwo.

Tylko potem trzeba kogoś, kto się w tym "kastrowaniu", żeby na bierząco administrować stroną i np aktualizować skrypt i dodatki.

Okay, generalnie chcę opanować 3 CMSy: Drupal, Joomla, Wordress. Tak wiem, każdy to inna bajka inne możliwości. Który z nich jest najlepiej wykonany pod kątem bezpieczeństwa, jakości kodu?

Ostatnio edytowany przez mrmarkos (2012-06-02 14:14:04)

mrmarkos napisał(-a):

Ma zabezpieczać przed nieautoryzowanym dostępem do panelu administracyjnego. Z tego co czytałem, to zmiana adresu panelu administracyjnego w Joomla jest kłopotliwa.

I jesteś pewien, że potrafisz zrobić to lepiej niż twórcy danego CMS-a?
Nie mam na myśli obrażanie Ciebie czy negatywnego wypowiadania się o Twoich kompetencjach. Pytam zupełnie poważnie.
Każdy wystarczająco długo istniejący CMS jest zabezpieczony przed najbardziej banalnymi atakami. W każdym wystarczająco popularnym CMS-ie wykrywane są luki bezpieczeństwa o różnych stopniu zagrożenia.

Atak na portal może przybierać bardzo wiele różnych sposobów. Wcale nie trzeba znać adresu panelu administracyjnego. Wystarczy jeden wadliwy formularz, gdziekolwiek (logowanie zwykłych użytkowników, wysyłanie plików, komentowanie itp.). Ponadto można przypuścić atak na poziomie języka skryptowego, w którym został napisany portal, oprogramowania serwerowego, systemu operacyjnego serwera, samej sieci. Można też atak przeprowadzić z wykorzystaniem socjotechniki, co często jest o wiele łatwiejsze i skuteczniejsze niż wykorzystywanie luk w zabezpieczeniach technicznych.

Podstawowe zasady:
1. Zmień standardowe nazwy użytkowników oferowanych przez dany CMS. Po sieci krąży wiele robotów, które będą próbowały Ci się wbić na użytkownika „admin”, „administrator”, „root” czy jakkolwiek. Jeżeli taki użytkownik nie będzie istniał w systemie, to nic Ci nie zrobią.
2. Na bieżąco aktualizuj oprogramowanie. Opis wykrytych luk bezpieczeństwa często jest publikowany po wydaniu załatanej wersji oprogramowania. Aktualne oprogramowanie jest gwarancją tego, że zdecydowana większość robotów nic Ci nie zrobi.
3. Nigdy nie można być w pełni zabezpieczonym. Od razu zapomnij o osiągnięciu takiego poziomu bezpieczeństwa, w którym możesz przestać o nie dbać. Miej zaufanie do twórców oprogramowania, którego używasz — albo go nie używaj.

Naukę radziłbym zacząć od podstaw.

Bezpieczny CMS czy framework, jak Django?
Praktycznie nie ma czegoś takiego.
Twórcy takich systemów faktycznie dokładają sporo starań, żeby ich CMSy były bezpieczne, ale stoją pod ścianą społeczności użytkowników, dla których taki CMS będzie nie do użytku, jeśli np będzie trzeba z palca ustawiać uprawnienia po instalacji jakiegoś dodatku.

A ja np nie ufam CMSowi, który sam ustala uprawnienia do swoich modułów i plików systemowych.
I nie chodzi tu bynajmnije o nieprawidowe uprawenienia, tylko o możliwości hakera, który wie, że CMS oferuje takie opcje.

Np folder Administrator, domyślna akcja, jeśli następuje wywołanie skrypt XXX.php - jest sprawdzenie, czy user jest zalogowany, jeśli nie, wyświetlenie panelu logowania.

Kiedyśyś w starym Oscommerce był taki błąd, że można było specjalnym zapytaniem GET wejść na Admina bez logowania.
I bardzo ciekawie sie kończyło pozostawienie tego błędu.

Obecnie co prawda nie używa się już Register Globals - który był gigantyczną bzdurą, ale wszystkich mało znanych technik ataku nikt nie zna na bierząco, żeby wiedzieć, czego się w danym tygodniu można spodziewać.

Nie sugerowalbym sie też jakimś shared-hostingiem, ponieważ zawarte tam zabezpieczenia zazwyczaj chronią tylek administratora, a użyszkodnik ma tylko mod_rewrite do dyspozycji.

I nie radzę mylić bezpieczeństwa FreeBSD czy Debiana z bezpieczeństwem CMSa - bo gdyby FreeBSD był tak bezpieczny, jak Joomla, już by go nie było. Debiana także.

W dodatku Ciebie nie interesuje bezpieczeństwo  serwera, na którym stoi  system, tylko możliwości serwera WWW, interpretera PHP czy Pythona, i samego skryptu.

Dodatkowo sporo ataków typu SQL-Injestcion można znacząco utrudnić stosując dobrze dopasowane uprawnienia do bazy SQL, gdzie dla każdego użytkownika możesz zdefiniować, co może robić z daną tabelą w bazie.

W samym CMSie też są spore zabezpieczenia, ale jakoś nie pamiętam, żeby którakolwiek wersja Joomli nie miała dziur (podatności) na SQL-Injection wsamymy skrypcie lub dodatkach, także najwyraźniej domyślne zabezpieczenia nie zawsze wystarczają.

Na samym serwerze, przy Apachu można skonfigurowac mod_security, na Nginxie czy Lighttpd można dokladnie filtrować REGEXEM zapytania GET i POST, takze da sie to zrobić porządnie, ale przeważnie na cudzym hostingu masz te możliwości znacznie mniejsze.

Jeśli sprawdzasz konfigurację formularzy w Joomli, to zauważ, że czesć ataków  SQL-Injection używała nie formularzy, ale cookies lub zapytań GET.

Z resztą drobny przykład:
Debian vulnerable w Google -  723,000
Joomla vulnerable - 1,050,000
Tu masz mniej wiecej porównanie "popularności" tych 2 zagadnień. :D

To by było na tyle
;-)

W Joomli we wszystkich kanałach wprowadzania danych, GET,POST cookies i nawet  session_id były dziury pozwalajace na SQL-Injection.
Gdybym chciał te dziury liczyć, to chyba życia by mi zabrakło.

Kłopotem przy tym nie jest moim zdaniem w pomyłce jednego autora, ale w radosnej twórczości ogromnej liczby ochotników, wśród których brakuje kogoś, kto pilnuje całości kodu (core + dodatki), poza tym same sposoby ataków też ewoluują "w oczach", za czym nie nadążają ani moduły do Joomli, ani dodatki do Oscommerce.
Podobny problem jest praktycznie ze wszystkimi CMSami i frameworkami, Django też bynajmniej święte pod tym względem nie jest.

Ostatnio edytowany przez Jacekalex (2012-06-03 18:08:00)