Select Page

PART 1: Dedicated internet server are not secure out of the box… server are not delivered secure out of the box, I’ve found a lot of problem on our dedicated server MR2,,,,
Strato is of course not responsible for that, but what I do not understand is why SuSE do not renforce their default settings. Even if #Linux is all about freedom, why letting so much settings by default, while everyone know that they will lead to securities issues????

First SSH is not correctly configured

X11Forwarding yes  a non sense for a server -> ive change it to no
PasswordAuthentication yes   a non sense for a server -> ive change it to yes to allow only strong logging with RSA public private keys.
i’ve change some other values according to the table below:

The /etc/ssh/sshd_config file is the system-wide configuration file for OpenSSH which allows you to set options that modify the operation of the daemon. This file contains keyword-value pairs, one per line, with keywords being case insensitive.

Port 22 The option Port specifies on which port number ssh daemon listens for incoming connections. The default port is 22.
ListenAddress The option ListenAddress specifies the IP address of the interface network on which the ssh daemon server socket is bind. The default is; to improve security you may specify only the required ones to limit possible addresses.
HostKey /etc/ssh/ssh_host_key The option HostKey specifies the location containing the private host key.
ServerKeyBits 1024 The option ServerKeyBits specifies how many bits to use in the server key. These bits are used when the daemon starts to generate its RSA key.
LoginGraceTime 600 The option LoginGraceTime specifies how long in seconds after a connection request the server will wait before disconnecting if the user has not successfully logged in.
KeyRegenerationInterval 3600 The option KeyRegenerationInterval specifies how long in seconds the server should wait before automatically regenerated its key. This is a security feature to prevent decrypting captured sessions.
PermitRootLogin no The option PermitRootLogin specifies whether root can log in using ssh. Never say yes to this option.
IgnoreRhosts yes The option IgnoreRhosts specifies whether rhosts or shosts files should not be used in authentication. For security reasons it is recommended to no use rhosts or shosts files for authentication.
IgnoreUserKnownHosts yes The option IgnoreUserKnownHosts specifies whether the ssh daemon should ignore the user’s $HOME/.ssh/known_hosts during RhostsRSAAuthentication.
StrictModes yes The option StrictModes specifies whether ssh should check user’s permissions in their home directory and rhosts files before accepting login. This option must always be set to yes because sometimes users may accidentally leave their directory or files world-writable.
X11Forwarding no The option X11Forwarding specifies whether X11 forwarding should be enabled or not on this server. Since we setup a server without GUI installed on it, we can safely turn this option off.
PrintMotd yes The option PrintMotd specifies whether the ssh daemon should print the contents of the /etc/motd file when a user logs in interactively. The /etc/motd file is also known as the message of the day.
SyslogFacility AUTH The option SyslogFacility specifies the facility code used when logging messages from sshd. The facility specifies the subsystem that produced the message–in our case, AUTH.
LogLevel INFO The option LogLevel specifies the level that is used when logging messages from sshd. INFO is a good choice. See the man page for sshd for more information on other possibilities.
RhostsAuthentication no The option RhostsAuthentication specifies whether sshd can try to use rhosts based authentication. Because rhosts authentication is insecure you shouldn’t use this option.
RhostsRSAAuthentication no The option RhostsRSAAuthentication specifies whether to try rhosts authentication in concert with RSA host authentication.
RSAAuthentication yes The option RSAAuthentication specifies whether to try RSA authentication. This option must be set to yes for better security in your sessions. RSA use public and private key pairs created with the ssh-keygen1utility for authentication purposes.
PasswordAuthentication yes The option PasswordAuthentication specifies whether we should use password-based authentication. For strong security, this option must always be set to yes.
PermitEmptyPasswords no The option PermitEmptyPasswords specifies whether the server allows logging in to accounts with a null password. If you intend to use the scp utility to make automatic backups over the network, you must set this option to yes.
AllowUsers admin The option AllowUsers specifies and controls which users can access ssh services. Multiple users can be specified, separated by spaces.
to restart the ssh daemon, just execute:
# /etc/init.d/sshd restart

I’ve create some new public/private keys pair (# ssh-keygen -t rsa) and copied the public part id_pub.rsa into ~/.ssh/authorized_keys2 and  found that tutorial very interesting SSH User Identities

I provide here both files (I supress all comments for clarity)

Host *
ForwardX11Trusted  no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication  no
KeyRegenerationInterval 3600
LoginGraceTime 10m
StrictModes yes
MaxAuthTries 3
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  /root/.ssh/authorized_keys2
HostbasedAuthentication no
IgnoreUserKnownHosts no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
X11Forwarding no
UseLogin no

2. PHP settings
Then I’ve looked at /etc/php.ini and change the following values:

; You should do your best to write your scripts so that they do not require
; register_globals to be on;  Using form variables as globals can easily lead
; to possible security problems, if the code is not very well thought of.
register_globals = Off

; Whether to allow the treatment of URLs (like http:// or ftp://) as files.
allow_url_fopen = Off

3. YaST

Autoupdate of paches and antivirus update was not set to automatic

to be continued… 

About The Author

I worked with various Insurances companies across Switzerland on online applications handling billion premium volumes. I love to continuously spark my creativity in many different and challenging open-source projects fueled by my great passion for innovation and blockchain technology.In my technical role as a senior software engineer and Blockchain consultant, I help to define and implement innovative solutions in the scope of both blockchain and traditional products, solutions, and services. I can support the full spectrum of software development activities, starting from analyzing ideas and business cases and up to the production deployment of the solutions.I'm the Founder and CEO of Disruptr GmbH.