Bekijk Volledige Versie : Beveiliging van Linux server
Ik zia via apache status telkens zulke regels:
2-0 2174 0/2/2 _ 0.04 3 19 0.0 0.00 0.00 133.28.19.12 localhost GET /d2/i/00146/1drdduvx0zmb.jpg HTTP/1.1
3-0 2177 0/2/2 _ 0.03 1 19 0.0 0.00 0.00 124.208.206.59 localhost GET /d2/i/00146/e4dv70yk5bwg.jpg HTTP/1.1
Terwijl zo'n bestand absoluut niet op mijn server zit, zijn telkens mensen bezig met verschillende ip's.
Ik heb vele landen zoals China, Japan enz met iptables geband via mijn server, zeker niet alles maar best veel ip's.
Weet iemand wat ik hieraan kan doen?
Ik heb BFD en APF Firewall geinstalleerd, root port op een andere port ingesteld maar toch wil ik meer weten hoe ik mijn server beter kan beveiligen.
Kunnen jullie hierover wat tips geven?
Ik heb BFD en APF Firewall geinstalleerd, root port op een andere port ingesteld maar toch wil ik meer weten hoe ik mijn server beter kan beveiligen.
Kunnen jullie hierover wat tips geven?
Is dat iets nieuw die root poort, want dat komt mij niet bekend voor tenzij je ssh protocol bedoeld ;)
Om te antwoorden op je vraag hoe je je server beter kan beveiligen, installeer een IPS/IDS zoals bvb snort dat houdt al redelijk veel bekende exploits tegen.
Moet je wel zelf weer libcap gaan compileren als je Centos 5.x draait:
Unfortunately for people using RHEL 5 (and below), CentOS 5.5 (and below), and Fedora Core 13 (and below), there is not an official RPM for libpcap 1.0.
Tenzij dat geen probleem is.
Ik zou sowieso beginnen met m'n /tmp directory te beveiligen just to be sure, maar wel iets doen als The-Boss aangeeft. Voor een beginner is dan CSF/LFD misschien een wat fijnere keuze, gezien de mogelijke integratie in webmin. In elk geval is die beter dan BFD/APF en een stuk eenvoudiger te configgen.
SSH op een andere poort zetten is leuk, werken met SSH key is beter. Rechten van bepaalde gevoelige executables wat wijzigen, daar waar dat kan is ook geen slecht idee.
De beste beveiliging begint met het zorgen dat ALLE software op de server up-2-date is en blijft. De rest is vrijwel zinloos als je het eerste niet doet.
avanmessen
05/04/11, 09:43
http://bastille-linux.sourceforge.net/
Bekijk dit even ? :thumbup:
Zou ook helemaal niets kunnen zijn (alleen vissen naar een exploit die er niet is).
Kijk ook eens naar http://www.hardened-php.net/suhosin/
Zou ook helemaal niets kunnen zijn (alleen vissen naar een exploit die er niet is).
Kijk ook eens naar http://www.hardened-php.net/suhosin/
We hebben het hier over HTTP-aanvragen die niet eens tot de PHP-parser komen. En voor je met Sohosin aan de slag gaat, valt er aanzienlijk meer winst in de php.ini te halen door ranzigheden als llow_url_fopen, enable_dl, passthru etc. te verbieden.
@Arto: Als het altijd GET aanvragen zijn die beginnen met /d2/i/00146/* is het makkelijker om hier gewoon een 500-error op te geven?
@Randy: ik dacht dat TS wat meer wilde weten over beveiliging van servers. Dat het niets met PHP te maken heeft ben ik mij gelukkig van bewust.
maar toch wil ik meer weten hoe ik mijn server beter kan beveiligen.
Als we dan toch bezig zijn op patch level dan is grsecurity (http://grsecurity.net/) ook een leuke aanvulling, vooral als je klanten shell access geeft of php system, passthru, etc.
We hebben het hier over HTTP-aanvragen die niet eens tot de PHP-parser komen. En voor je met Sohosin aan de slag gaat, valt er aanzienlijk meer winst in de php.ini te halen door ranzigheden als llow_url_fopen, enable_dl, passthru etc. te verbieden.
@Arto: Als het altijd GET aanvragen zijn die beginnen met /d2/i/00146/* is het makkelijker om hier gewoon een 500-error op te geven?
Ik heb deze functies al verboden via php.ini
exec,passthru,shell_exec,system,proc_open,popen,cu rl_exec,curl_multi_exec,parse_ini_file,show_source
Aanvragen beginnen niet alleen met /d2/i/00146/ ook zoals /i/00178/*
Hoe kan ik hier een error voor geven?