Po1. Jak serwer nie ma klientów (requestów) spoza Polski - a mój tak nie ma w planach - to można spróbować zablokować.
Rozumiem oczywiście, że może być serwer, który ma requesty spoza Polski, ale nie zawsze tak jest.
Np. póki co nie mam nic wspólnego z Ruskimi, Koreańczykami i Chińczykami - więc na pewno pójdzie blokada po IP.
Atakują nie zwykli ludzie, ale bot-nety, które w tych krajach są rozwinięte. Np. w takich Chinach jest nadal kilkaset milionów komputerów z WindowsemXP - a WindowsXP to siedlisko bot-netu. Mimo wszystko mam zamiar dać te IP do .htaccess - głównie na Azję.
Dalej uważam to za zły pomysł, ale jak uważasz. Nie ma nic gorszego niż false positive i zablokowanie dostępu zwykłemu użytkownikowi. A jest masa powodów dla których polak może się łączyć z IP które Twój serwer rozpozna jako zagraniczne (np. rosyjskie).
Security to confidentiality, integrity, availability, accountability - blokując dostęp do całych zakresów IP sam sobie ograniczasz availability (do pewnego stopnia).
Ale jeśli faktycznie jesteś na to zdecydowany to ok, Twój serwer :P. Na pewno faktycznie zmniejszy zakres ataków botów, tylko ideologicznie uważam to za złe podejście do zabezpieczania.
Po2. Ogarniam teraz apparmor - taka dosyć ciekawa aplikacja, która ostro izoluje procesy od systemu. Mniej więcej jest to hardening procesu, a więc proces nagle nie może się wymknąć spod kontroli i ma prawa tylko jakie mu ustalimy. Wstępnie widać, że sporo z tym roboty, ale może gra warta jest świeczki - szczególnie, że są gotowe profile do blokowania tych procesów w necie. Np. sporo ma apache2, a inne usługi serwerowe również mają gotowe profile.
Polecam apparmor jeśli chcesz poważnie zabezpieczać serwer (a widzę że chcesz). Ogólnie im więcej czasu poświęcisz na konfigurowanie go tym lepiej będzie chronił (można każdemu programowi dać tylko to czego dokładnie potrzebuje). Przed sqli Cię nie ochroni (i tak całą bazę będzie można wykraść), ale zawsze może pomóc w zabezpieczaniu usług.
Po3. wiem właśnie, ze uprawnienia (ownership, permission) - nawet zobacz jakie dałem tematy ostatnio na 4p:
konfiguracja Apache2, wiele virtual hostów, a zamknięcie portów
symfony2 LTS (lub 3): permissions, owner, ważne ścieżki/foldery
Co chwilę piszę o tych uprawnieniach, bo to trzeba mieć w małym palcu - ale właśnie nie jest to takie oczywiste, bo 1 luka i można przeoczyć jak jakieś uprawnienia są źle ustawione. Co chwilę zastanawiam się czy jeszcze jakiegoś nie poprawić w tym wszystkim co jest, czy nie zejść gdzieś niżej w chmod.
A faktycznie.
Swoją drogą, odnośnie drugiego tematu:
owner http://serverfault.com/questiolko root-folder?
przy prawach 770 osoby z zewnątrz będą mogły to odczytać? na forach polecają wejście aż na 775:
http://serverfault.com/questio[...]s-chmod-775-safe-to-use/144195
Rany, po co 775. Nie mówię że to złe uprawnienie, ale jeśli chcesz jak najbezpieczniej:
Wszystkie foldery do których aplikacja powinna pisać (sesja, cache, logi, etc): 770 (albo 700)
W zasadzie wszystkie pozostałe pliki (w szczególności pliki .php): 440 (albo 400). Serwer www nie powinien mieć praw do nadpisywania plików php, to ważne.
Po4. OPRÓCZ KODU PHP, na Linuxie jest pełno sposobów zabezpieczenia serwera - to pojęcia nazywa się hardening; można tłumaczyć jako "utrudnienie". Np. tutaj wskazówki : http://fm4dd.com/security/apache-hardening-top-ten.htm
Pełno jest tego, każda zastosowana wskazówka "utrudnia" nasz system w płynnej konfiguracji, ale też wzmacnia bezpieczeństwo
WIem co to hardening :P. Ja bym przetłumaczył jako "hartowanie" jednak.
Jak już przy tym jesteśmy, to możesz jakiś WAF postawić przy okazji - czyli takie coś co automatycznie wykrywa podejrzane requesty i zablokuje je. Też się mu zdarzają false positivy czasami teoretycznie (ale i tak lepszy sposób niż odgórne blokowanie zakresów IP), ale to można monitorować.
Po5. Code review PHP, oddzielna bajka. Ale też samo ulepszanie pakietów na serwerze to za mało, bo prawdopodobnie jak kod niebezpiecznie jest napisany, to ulepszenie pakietów np. PHP nic nie da (wypadałoby przetestować konkretne przypadki)
Nie no, update PHP nic nie da jak będzie SQLi albo inny vuln w kodzie - PHP tylko robi to co się mu każe.
Po prostu instalowanie regularnie security updates to dobry pomysł (nigdy nie wiadomo kiedy wyjdzie vuln na jakąś usługę).
Po6. Generalnie nie do końca wiadomo co jest w tym całym bot-necie chińsko-koreańskim. Biorąc pod uwagę, że Azjaci mają łeb do hackingu, to może nagle przyjść jakiś bot, który exploituje nam usługę - trzeba się "zabezpieczać" na ile się da, ale nie unikać problemu.
Albo inaczej - trzeba sie pogodzić że ktoś w końcu znajdzie lukę gdzieś, i pomyślec co zrobić żeby straty były jak najmniejsze.