Wlasny dedyk a bezpieczenstwo

[Szo0k 0]

Witam!

 

Firma w ktorej pracuje zdecydowala sie na zakup serwera dedykowanego, ktory juz dziala, hostuje strone WWW firmy i kilku zaufanych klientow.

 

A ze wole dmuchac na zimne, mam kilka pytan odnoscie konfiguracji serwera.

 

Juz na poczatku, w WHM mamy zakladke:

Main >> Server Setup >> Tweak Security

 

a w niej:

Php open_basedir Tweak

mod_userdir Tweak

Compilers Tweak

Traceroute Tweak

SMTP Tweak

 

Jak to skonfigurowac, zeby w przyszlosci nie bylo problemow?

Prosilbym tez o inne porady, ktore sa dla mnie cenne, szczegolnie w konfiguracji Apache i PHP - serwer dziala pod kontrola RedHat Enterprise 3

 

Wielkie dzieki za lopatologiczne wskazowki!

[Gość Fo]

witam,

 

jeżeli chodzi o Tweak Security, to tutaj troszeczke niewiem jakie masz konkretnie opcje w tych sekcjach, napewno ktoś kto na codzień ma pod sobą serwer postawiony na cpanelu będzie mógł Ci pomóc...

 

 

jeżeli natomiast chodzi o security Twojego php to polecam pare zmianek do php.ini takich jak :

 

disable_functions : system, exec, shell_exec, escapeshellcmd, escapeshellarg

 

ta linijka uniemożliwi Twoim Klientom i każdemu kto będzie mieć dostęp do dobrodziejstw php na Twoim serwerze, na wykonywanie komend stricte linuxowych z poziomu www, bo można sobie napisać skypcik, który będzie przy pomocy w/w funkcji służył za web-konsole do wykonywania poleceń linuxowych na Twoim serwerze. czyli wścibskim mówimy NIE

 

ponadto warto abyś wziął również małą poprawkę na upload_max_filesize = 2M

tę wartość powinieneś nastawić na tak coś namniej 20M - ponieważ, weś pod uwagę to, że ludzie będą mogli chcieć swoje backupy baz danych sql przeciskać przez takiego phpmyadmin'a

[Ranma_man 0]

Poradnik z WHT

[patS 0]

Kilka uwag tak z głowy :

- konfiguracja bazy danych - odpowiednia konfiguracja pozwala na odowoływanie się do bazy jedynie z sprawdzonych i wiarygodnych adresów IP (np. 127.0.0.1 )

- konfiguracja poczty - najważniejszą sprawą oprócz odpowiednich zabezpieczeń antyvirusowych i antyspamowych jest odpowiednia wydajność i odpowiednia struktura katalogów (plików), co do pierwszego - są lepsi spece na forum -> niech oni Ci doradzą , co do drugiego - bardzo ważna sprawa na dłuższą metę - odpowiednia konfiguracja zapewnia bezproblemową obsługę kopii zapasowych, przenoszenia kont itp.

- konfiguracja zabezpieczeń przed atakami typu DDOS - tutaj ogromne pole do popisu - wbrew pozorom nie jest to prosty temat, łamią się na nim najlepsi, ja sam znam go cieniutko ale wiem że należy tak naprawdę przy poważnych rozwiązaniach zacząć od niego (poza instalką OS-a i firewalla

- login root - zablokowany dostęp do niego - z zew logujemy się np na ADMIN i dopiero potem (np. po linuxem) su root

- odpowiednie zabezpieczenie przed scanowaniem portów (nmapem itp) - tutaj głównym problemem jest chmara domorosłych hakierów którzy potrafią czasem być upierdliwi, - odpowiednie zabezpieczenie wystawiające fałszywe porty i dające bana na wywołujący ipek są jak najbardziej porządane.

 

Co do php,

1. set_time_limit - funkcja która wbrew pozorom potrafi siać zamęt - proponuje ustawić rozsądny przedział czasowy i go kontrolować.

2. poziom wyświetlania i logowania błędów - ważna sprawa odpowiednio skonfigurowane pokazuje wiele

 

Tyle, tak z palca

 

Pozdrawiam patS

[ertcap 0]

- konfiguracja bazy danych - odpowiednia konfiguracja pozwala na odowoływanie się do bazy jedynie z sprawdzonych i wiarygodnych adresów IP (np. 127.0.0.1 )

Niestety ale czesc klientow wymaga dostepu do bazy z zewnatrz (sa jakies zabawki typu phpmyadmin odpalane z lokalnego kompa).

A jesli juz ciac dostep do mysqla to ciac go na firewallu a nie na poziomie konfiguracji bazy.

- konfiguracja zabezpieczeń przed atakami typu DDOS

A przed tym to raczej nie da sie do konca zabezpieczyc

- odpowiednie zabezpieczenie przed scanowaniem portów (nmapem itp)

imho nie ma sie co obawiac skanowania portow - to nic zlego (no chyba, ze uzywamy dziurawych uslug). Najlepiej pozmieniac jeszcze nazwy uslug w zrodlach (walnac sobie, ze apache to np. "idea web serwer" itd.).

dające bana na wywołujący ipek są jak najbardziej porządane.

Radze czegos takiego nie robic

1. set_time_limit - funkcja która wbrew pozorom potrafi siać zamęt - proponuje ustawić rozsądny przedział czasowy i go kontrolować.

A to to uzyszkodnik chyba raczej w kodzie php obejdzie (set_time_limit, ini_set). A blokowanie dostepu do tych funkcji spowduje tylko, ze polowa zabawek typu mambo przestanie dzialac.

2. poziom wyświetlania i logowania błędów - ważna sprawa odpowiednio skonfigurowane pokazuje wiele

Koniecznie wlaczyc logowanie mysqla i leciec do sklepu kupic porzadna macierz dyskowa A na serio to faktycznie logowac prawie wszystko co sie da i regularnie przegladac logi. Najlepiej to logi systemowe wywalac od razu na druga maszyne (na ktorej bedzie sluchalo dodatkowo tylko ssh).

 

pzdr.

[patS 0]

@ertcap, praktycznie ze wszystkim co powiedziałeś się zgodzę

Proszę nie traktować mnie jak specjalistę w tej dziedzinie i w żaden sposób nie kierować się moim zdaniem, wyrażam je jednak z uwagi na swoje kilkuletnie doświadczenie w branży IT w trakcie których przeżyłem kilka "kwiatków"

Nie jestem administratorem nie byłem i hehe raczej nie będę , znam się jednak na tej branży, wiem jak działa i wiem że każde zabezpieczenie adekwatne do potrzeb nie zaszkodzi

Jak dobrze zrozumiałem autora tematu, jest to serwer firmowy, więc nie ma tam raczej mowy o przechowywaniu nie znanych "stworzeń" na kontach użytkowników XYZ których rozpoznajemy jedynie po numerze na fakturze z tąd też moje sugestie w niektórych kwestiach.

 

Pozdrawiam patS

[ertcap 0]

wyrażam je jednak z uwagi na swoje kilkuletnie doświadczenie w branży IT w trakcie których przeżyłem kilka "kwiatków"

ok ok, ja Ci nic nie zarzucam przeciez. Po prostu dodalem imho kilka waznych rzeczy do Twojej wypowiedzi.

wiem że każde zabezpieczenie adekwatne do potrzeb nie zaszkodzi

Zdadza sie, ale pewne zabezpieczenia potrafia sie obrocic przeciwko nam Stad moja sugestia zeby nie wprowadzac tego banowania ip bo w wiekszosci przypadkow mozna latwo serwer zablokowac przy takim zabezpieczeniu.

Jak dobrze zrozumiałem autora tematu, jest to serwer firmowy, więc nie ma tam raczej mowy o przechowywaniu nie znanych "stworzeń" na kontach użytkowników XYZ

na to nie zwrocilem uwagi :oops:

 

pzdr.

[Gość Fo]

heja,

 

a mógłbyś nieco bardziej zdefiniować : "bo w wiekszosci przypadkow mozna latwo serwer zablokowac przy takim zabezpieczeniu" ?

 

rozumiem, że chodzi Ci tutaj o rozwiązanie typu : blokujemy wszystko oprócz tego co chodzi na serwerze ? tak to jest głupota bo zawsze przecież jak się ktoś mało zna to może stwierdzić że z portu 113(auth) tak naprawdę nic nie korzysta , natomiast o ile się nie myle z niektórych portów takich jak 4899 ( Radmin PORT => http://seclists.org/lists/incidents/2004/Apr/0018.html ) nikt raczej nie korzysta i nikt *nie powinien* korzystać - czyli stukać Ci do drzwi na tym piętrze

 

tak naprawde, najważniejsza jest dokładna analiza logów - z czasem wg. mnie (specem od bezpieczeństwa nie jestem), można wyłączać, na wszelkie sposoby to co nastukuje do maszyny na niektórych portach. wiadomo, zbyt duży flood na jakieś nieznane porty - a) wygląda podjeżliwie, kieruje do google'a to co jest blokowane a co nie, to już kwestia każdego z osobna... jak ktoś jest sado to może ciąć wszystko czego nie zna, ale tak... wtedy dokładnie zrównuje się to z zablokowaniem serwera... dlatego trzeba wiedzieć za co odrazu ścinać głowę a za co lać po tyłku

 

jest coś takiego jak /etc/services - a to chyba podstawa podstaw przy wycinaniu, czy też zabieraniu się do wycinania określonego portu... ?

[Gość patrick]

ja bym polecil ksiazke http://helion.pl/ksiazki/blinpa.htm

ps. dosyc fajna jest, zawarte sa w niej prawie wszystkie typy wlaman.

 

Wysłany Czw Cze 09, 2005 8:42 am:

 

macie przykladowy rozdzial ftp://ftp.helion.pl/online/blinpa/blinpa-5.pdf

ale ksiazka jest naprawde dobra.

[ertcap 0]

a mógłbyś nieco bardziej zdefiniować : "bo w wiekszosci przypadkow mozna latwo serwer zablokowac przy takim zabezpieczeniu" ?

Chodzi mi o rozwiazanie tego typu, ze blokujemy automatycznie na firewallu ip usera, ktory nam przeskanowal pare portow. Poczytaj o czyms takim co sie zwie spoofing (mozna sie przed tym probowac zabezpieczac ale to jest ogolnie bez sensu - generalnie: nie robic po prostu takiego zabezpieczenia).

 

pzdr.