sollte funktionieren wenn du den loader in die /cli/php.ini
einträgst.
Posts by Cool
-
-
try to avoid .htaccess...i know it is very popular but it is(allways has been) a performance killer
-
i gave you allready the hint to iptables. there you can define rules to access ftp.
you can eaven work with hosts.deny and hosts.allow
but if i was your customer and could not reach my ftp from anywhere then i would be really p.....(a bad word)
found this one:
http://www.castaglia.org/proft…/internals/ftpaccess.html -
better use:
this redirect regardless www...port...ipas .htacces overall will slow down allways the best way is to
implement it to the v-host conf. file with a:
RedirectPermanent / https://example.com/ -
don´t trust to much on fail2ban it only can help to secure but not to 100%
a iptables based firewall will do a better jobmuch depending on how your server was compromized you never can be sure thru wich real ip it was done. so just block a ip or a ip-range can give a zero result.
contact the isp to the ip wich is under suspicion and ask them if they can find such connections to your server in theire logs.
but eaven then you don´t know how/why the usernames and passwords where accessable. so at the moment may your system is not secure at all.
-
the most common are unsecure passwords
old or not updated scripts on web-sites
unsecure ssh accessas long as you don´t know how the server was compromized take the server offline and analyse the log-files.
if your ssh-access was compromized then only a new server setup will be secure.
-
si vous suivez ceci ici : http://wiki.i-mscp.net/doku.php?id=start:installation:debian
exactement alors que vous répondez juste que les questions et le système effectueront tout le travail pour vous -
ich habe auch so einen test-server bei gleichem hoster und konnte den fehler nicht reproduzieren.
durch andere auffälligkeiten nehme ich an das das kvm-system noch nicht stabil läuft. -
org. = original (i-mscp rkhunter cron script/line)
i´m not sure about a ticket...wondering about that no other one had the same problem...may they never look at that log-file from cp.
-
this is how it works for me:
@daily root /usr/bin/rkhunter --cronjob -l /var/log/rkhunter.log; chmod 644 /var/log/rkhunter.logthe org. cron job don´t worked on any of my servers (rkhunter.log was not readable from cp)