Cédric Walter | Oct 8, 2020 | 0
Sorry for the instability of my homepage
My Homepage is highly instable, I need to reboot the server manually 2 times a day, it has run monthly without any issues, the last reboot was 2 weeks ago, but things get worse.
I have frequently mos_sessions corrupted, mysql die sometimes, my plesk panel is no more available and so on…
While I am still looking in logs file what it could be (ports scan? root kit? denial of service), here is what I plan to do in the next days (I will be in holidays).
The load is huge 100.000 users per months compare to january (4000 users per months) but it should not bring an opteron 1GB down… (Server MR2 from Strato.de)
- MySQL is already using an optimized my.ini for the SEO openSEF.org engine
# The following options will be passed to all MySQL clients
port = 3306
socket = /var/lib/mysql/mysql.sock
# The MySQL server
port = 3306
#socket = /var/lib/mysql/mysql.sock
max_connections = 500
key_buffer = 150M
max_allowed_packet = 16M
table_cache = 1500
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 64M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 1M
thread_cache_size = 128
wait_timeout = 14400
connect_timeout = 10
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 32M
query_cache_type = 1
server-id = 1
# The safe_mysqld script
open_files_limit = 8192
max_allowed_packet = 16M
local = 1
# Remove the next comment character if you are not familiar with SQL
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M
- I switch the SEO OpenSEF.org engine OFF 5 minutes ago (I was having 9500 DB based rewriting rules), the site is now lightning fast…
- I am looking in logs files, hacker are not all so smarter and I should see something there… (or at least now anyone can run a botnet and use penetration software without knowing how it works)
- I may deactivate some subdomains to better determine if it is a software bug or an attack on one of my subdomains: my Wiki, Forums, Demo, Demo2, Shop
- Server hardening #1: I will update the server with Yast (Package manager of SuSE) and set auto update
- Server hardening #2: I will launch one more time chkrootkit
chkrootkit is a tool to locally check for signs of a rootkit (“Root Kits” is the art of hiding files/directories/processes after a server/desktop break-in….)
rkhunter: Open-source GPL rootkit scanner for Unix-like systems. Scans for rootkits, trojans, backdoors and local exploits.
- Server hardening #3: either install SELinux (Security-enhanced #Linux)
Security-enhanced #Linux is a research prototype of the #Linux® kernel and a number of utilities with enhanced security functionality designed simply to demonstrate the value of mandatory access controls to the #Linux community and how such controls could be added to #Linux. The Security-enhanced #Linux kernel contains new architectural components originally developed to improve the security of the Flask operating system. These architectural components provide general support for the enforcement of many kinds of mandatory access control policies, including those based on the concepts of Type Enforcement®, Role-based Access Control, and Multi-level Security.
AppArmor gives you network application security via mandatory access control for programs, protecting against the exploitation of software flaws and compromised systems. AppArmor includes everything you need to provide effective containment for programs (including those that run as root) to thwart attempted exploits and even zero-day attacks.
But both will be rather difficult to install because the server is using SuSE 9.3 and this may also interfere with Plesk….
- Server hardening #4:I will add mod_security
ModSecurityTM is an open source intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks.
and eventually document it in an article.
- Server hardening #5:I will monitor the number of login ssh attempts to avoid sshd logins using simple username-password combinationsor dictionary based attacks.
from http://www.linuxquestions.org/questions/showthread.php?t=340366Several reports indicate that the malicious code is a scanner designed to identify systems with weak username/passwords. Once a weak system is identified, its IP address is appended to a list for manually exploitation later on. However, the possibility of a unknown exploit has not been ruled-out.
All Linux users are recommended to implement a sensible username and password policy in order to avoid being compromised by this tool. An example of a sensible policy would be at least the use of non-dictionary, alpha-numeric+punctuation characters. Restricting sshd access to only those systems necessary will further reduce the possiblity of compromise. Access restriction can be done using iptables or tcp_wrappers (hosts.allow/deny)
Further information about this tool and failed sshd logins can be found here:
Holidays are not starting as nice as expected ;-(