Security question

S

stream

Hi,

Can the experts in the forum suggest best practices in hardening and making remote servers more secure.

I have PF firewall on, with basic rules to block all, but allow standard processes.
Am thinking SSH and Sendmail are main ways of attack?

I have sendmail_enable off, but still these messages appear all the time in one of the servers that was compromised recently.
sendmail[3456]: NOQUEUE: SYSERR(oeprator): can not chdir(/var/spool/clientmqueue): Permission denied.

There seems to be some process that is trying to send mail. I have no idea what it is.
I don't see any cron jobs either.

And previously I noticed a lot of users trying to guess password.
I have switched off SSH for now.

Thank you for your time.
 
I you have hard evidence that your install was hacked or accessed by persons without permission you should delete your partition.
The field of security very wide. Google "Freebsd hardening".
 
stream said:
Am thinking SSH and Sendmail are main ways of attack?
Click to expand...
Any port that's accessible from the internet is open to attacks. SSH and mail bruteforce attacks are common, that's certainly true, but your web applications for example are equally under attack.

stream said:
There seems to be some process that is trying to send mail. I have no idea what it is.
I don't see any cron jobs either.
Click to expand...
Keep in mind that periodic(8) will send daily, weekly and monthly reports too.

stream said:
And previously I noticed a lot of users trying to guess password.
I have switched off SSH for now.
Click to expand...
You can somewhat limit the extend of those attacks using blacklistd(8), security/sshguard or security/py-fail2ban. All these tools will automatically block IP addresses after a certain number of failed login attempts within a specified timeframe. That often helps a lot.

Another thing you can do is limit sshd(8) to only allow public/private key logins and never accept username/passwords. And while it's a bit of "security-through-obscurity", running sshd(8) on a different port will at least cull most of the automated scans.
 
You need syslog to be able to analyse problems. And you need ntp to synchronise time.
ntp is concidered secure.
For syslog you could probably configure it so it only binds to sockets or 127.0.0.1 to make it more secure.
 
Don't turn off syslogd(8). But you might want to add syslogd_flags="-ss" to rc.conf. That will prevent syslog from opening a network at all. By default it already ignores remote messages:
Code: 
     -s      Operate in secure mode.  Do not log messages from remote
             machines.  If specified twice, no network socket will be opened
             at all, which also disables logging to remote machines.

ntpd(8) should similarly be limited, the other process is likely sendmail. Just leave that at the default, it runs in a 'local-submit' only mode.
 
SirDice said:
Don't turn off syslogd(8). But you might want to add syslogd_flags="-ss" to rc.conf. That will prevent syslog from opening a network at all. By default it already ignores remote messages:
Code: 
     -s      Operate in secure mode.  Do not log messages from remote
             machines.  If specified twice, no network socket will be opened
             at all, which also disables logging to remote machines.

ntpd(8) should similarly be limited, the other process is likely sendmail. Just leave that at the default, it runs in a 'local-submit' only mode.
Click to expand...
thanks Sir. I will do that.
For ntp, are you suggesting ntp_logs="-ss" ? is this valid syntax.
 
For ntp there is little you can do according to my knowledge.
When time is not synchronized you have even browsing problems over https
 
I know you're not a beginner, but why don't you take a look at what I've already written toward the end of my tutorial:

forums.freebsd.org

Beginners Guide - How To Set Up A FreeBSD Desktop From Scratch

I'm going to guide you though the process of getting a fully functional FreeBSD 13.0-RELEASE desktop up and running, complete with system files and security settings, step-by-step as if you've never used UNIX or the command line. Now let's get started: Insert your boot media and at the Welcome...
forums.freebsd.org forums.freebsd.org

It has a full pf ruleset, configuration for /etc/rc.conf including syslog and ntp settings, /etc/ssh/sshd_config, etc.
Alain De Vos said:
For ntp there is little you can do according to my knowledge.
Click to expand...
This shows my pf ruleset and how it works, posted earlier today.

I block TCP port 25 and still get my daily mail through sendmail. I also block UDP and TCP ports 123 and my time is still updated because it initiates the traffic.
 
Trihexagonal said:
I know you're not a beginner, but why don't you take a look at what I've already written in my Tutorial;/url], stream.
It has a full pf ruleset, configuration for /etc/rc.conf including syslog and ntp settings, /etc/ssh/sshd_config, etc.
This shows [url="https://forums.freebsd.org/threads/a-seperate-forum-item-for-security.81080/#post-519682"]my pf ruleset and how it works, posted earlier today.

I block TCP port 25 and still get my daily mail through sendmail. I also block UDP and TCP ports 123 and my time is still updated because it initiates the traffic.
Click to expand...
Thank you for taking the time to create a tutorial. and also sharing pf rule set. I will go through it. V helpful.
 
It took me a bit to get my links right, but there should be something you can find of use toward the end of it.
 
SirDice said:
Another thing you can do is limit sshd(8) to only allow public/private key logins and never accept username/passwords.
Click to expand...
Additional sshd configuration:
  • If you've got a static IP address (your local machine - not the server), allow logins only from that IP.
  • Allow only one user to login (not root).
  • Use for this user a username f.e. like "jasGU7ZtdjdkfpQ810.hfzZKQY224Rdm". None bruteforce attack tries such usernames.
Analyzing hacked servers tells me: Of course attackers are forced to use primarily the tools on the server before starting to manipulate things. Even if a unwanted login occurs or a script was placed (f.e. if a software has an actual unfixed security issue) their sequences are trying to use tools they expect to be available on a server. I don't know why, but all I've seen used wget, none curl (or /usr/bin/fetch). And some kiddies already think that sudo is the traditional way to execute commands as root. So just don't install comfort tools like wget, sudo or even bash.
 
/etc/ssh/sshd_config
Code: 
IgnoreRhosts yes
AllowTcpForwarding no
PermitRootLogin no
Protocol 2
X11Forwarding no
PermitTTY no

That works.
 
jmos said:
Additional sshd configuration:
  • If you've got a static IP address (your local machine - not the server), allow logins only from that IP.
  • Allow only one user to login (not root).
  • Use for this user a username f.e. like "jasGU7ZtdjdkfpQ810.hfzZKQY224Rdm". None bruteforce attack tries such usernames.
Analyzing hacked servers tells me: Of course attackers are forced to use primarily the tools on the server before starting to manipulate things. Even if a unwanted login occurs or a script was placed (f.e. if a software has an actual unfixed security issue) their sequences are trying to use tools they expect to be available on a server. I don't know why, but all I've seen used wget, none curl (or /usr/bin/fetch). And some kiddies already think that sudo is the traditional way to execute commands as root. So just don't install comfort tools like wget, sudo or even bash.
Click to expand...
I'm not sure we can do anything useful a unix box without these. :)
 
SirDice said:
You can somewhat limit the extend of those attacks using blacklistd(8), security/sshguard or security/py-fail2ban. All these tools will automatically block IP addresses after a certain number of failed login attempts within a specified timeframe. That often helps a lot.

Another thing you can do is limit sshd(8) to only allow public/private key logins and never accept username/passwords. And while it's a bit of "security-through-obscurity", running sshd(8) on a different port will at least cull most of the automated scans.
Click to expand...
Sir. Thanks a lot for sharing this. If ssh already is limited to the latter - i.e. login via keys only and diff port, would it then make sense to add one of the tools you mentioned- e.g blacklistd ? or is it just overkill.
 
jmos said:
Of course attackers are forced to use primarily the tools on the server
Click to expand...
That is what I see in my webserver logs too. The use of bash and wget show the attackers are looking for Linux servers. PHP (wordpress) and Perl will be used too. The good news is that they are often friendly enough to use a full path, like /bin/bash, which means that it won't work on an ordinary FreeBSD installation.
It's for that reason I'd like to know which encryption tools are used by ransomware. If there is no need to encrypt files, it could make sense to restrict access to these tools.
 
By the way in case you are extra paranoid about SSH, or just want to keep your log files clean and tidy, you should use it with port knocking. This really helps a lot.
 
Make your application (SSH, sendmail, anything else) behave via their own .conf files first. PF comes after that. When trying to do anything security-related, I think that the OSI-RM model is important to know and creatively apply. You gotta be a tough nut to crack.
 
There's a lot of good points above, but my recommendation would be to decide first what ports you really need to have listening on the Internet. It's important to distinguish between "listening" and "outbound permitted" (e.g. dns, ntp, mail, etc). It's entirely possible that all you will need listening is sshd(8). Then use lsof(8) to make sure that nothing else is listening.

As SirDice suggested, moving the sshd port away from 22 makes a huge difference to drive-by attention (the script kiddies never get past trying port 22). Ssh login should be only by a quality key, and you must have these set in /etc/ssh/sshd_config:
Code: 
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

Best of all, use a separate dedicated professionally designed firewall. It will deal with the more esoteric things like managing ICMP sensibly, and all the other stuff you never thought of...

A tiny PC, with an Intel CPU, running pfSense or OPNsense would be my choice.
 
stream said:
If ssh already is limited to the latter - i.e. login via keys only and diff port, would it then make sense to add one of the tools you mentioned- e.g blacklistd ? or is it just overkill.
Click to expand...
Security is about layers. The more layers you can add the better.
 
You must log in or register to reply here.
Back
Top