Disabling Services Not Needed

[EverydayDiesel]

Im curious what services/daemons I can turn off for extra security. I am new to bsd and use it only for pf and routing. Everything else, thats not required for this to function, I would like to turn off if it has any added benefits.

On the default install I did not enable ssh since I will always be at the console and never telnet.

[BSDfan666]

I just responded in your other topic, if you're always at the console.. then those BSD flags are quite redundant, they do not protect against physical compromise.. paranoid file encryption and expensive locks on doors are the only way to do that.

There is no reason to disable services that are running by default, the ones that are running are critical to the functionality of the system.

If you're concerned about the reliability, make sure your firewall rules are sane.

[jggimi]

You -need- turn nothing off. The basic services included in the install are "secure by default." You will got no -extra security- from disabling any running services, and, you may even cause yourself harm. Example: disabling the built-in sendmail server because you think that will make your system more secure, will actually disable daily security testing results, see the security(8) man page. The default configuration of the sendmail server only accepts loopback connections.

OpenBSD is not Linux, Windows, Unix, or, even any other BSD.

Should you ever enable SSH, you will likely want to disable root access and perhaps password authentication as well.

[There0]

Should you ever enable SSH, you will likely want to disable root access and perhaps password authentication as well.

Yes those to options (disabled root via ssh login, and using preshared instead of passwords) REALLY help. I also specify ONLY which user can login with AllowUsers username (sshd_config) and you can spice up your pf.conf with something like this below to limit connections and from what IP you want to allow access from and of course a NON standard port

block drop log quick from { <bruteforce>, <noroute> }

pass in log quick on { $EXT, $INT } inet proto tcp from IP.ADDR.ALLOWED.ACCESS to { $EXT } port 32009 flags S/SA modulate state (max-src-conn 10, max-src-conn-rate3/3, overload <bruteforce> flush global)

[There0]

Example: disabling the built-in sendmail server because you think that will make your system more secure, will actually disable daily security testing results, see the security(8) man page

Agreed, and yes helpful, i assume you saw my sendmail=no in my rc.conf.local and brought this up, i do this for other reasons though.

[ai-danno]

Originally Posted by There0

and of course a NON standard port

I only mention this because I think the rest was sane. But for those truly serious threats that are actually looking to infiltrate via some means of surveillance or probing, putting services on non-standard ports does nothing. If you have SSH running on something other than 22... they're going to find it.

I would therefore recommend you leave it on 22.

[DraconianTimes]

Originally Posted by ai-danno

I only mention this because I think the rest was sane. But for those truly serious threats that are actually looking to infiltrate via some means of surveillance or probing, putting services on non-standard ports does nothing. If you have SSH running on something other than 22... they're going to find it.

I would therefore recommend you leave it on 22.

Moving SSH to a different port may not offer any additional security, but it does reduce the number of log entries from random kiddies scanning/bruting etc on 22/tcp.

[Carpetsmoker]

Originally Posted by ai-danno

I only mention this because I think the rest was sane. But for those truly serious threats that are actually looking to infiltrate via some means of surveillance or probing, putting services on non-standard ports does nothing. If you have SSH running on something other than 22... they're going to find it.

I would therefore recommend you leave it on 22.

I fear this depends on your userbase. if you have a large userbase with ssh access and are not enforcing password complexity rules strictly, then running ssh on a different port will greatly decrease the chance of some bot bruteforcing it's way in by automated scans ...

I know your reply already, it's not protecting the front door but putting the front door on the side of the house.
Enforcing proper passwords, or better, use RSA keys exclusively is the real solution. But in the real world things do not always work this way ...

[ai-danno]

You guys are right:

• Keeps script kiddies away and out of your logs
  But there are other obvious measures you can take to limit this (i.e., acceptable addresses, acceptable login names, version type, time-expiring attempt limits based on address or block, etc.), so if you are just looking to keep your log files down, it might be better to constrain things and then still keep a keen eye on the attempts. Personally, from a security perspective, I like keeping track of failed attempts- it helps complete the security picture.
  
• It depends on your environment
  It certainly does- if you are operating a publicly accessible ssh server that will see legitimate logins from the wild on a regular basis, then your environment may lend itself to a port change. If you know who should be coming in (and more importantly, from where), then see above.
  
• Keys would be even better
  Wouldn't they?
  
  Sigh, oh well. Someday
  
• I know we live in the real world heheh.
  I realize that you have to do what works in your life, but security is about not trusting assumptions, reassessing concrete security models, and systematic thorough reviews of the mechanics.

Sometimes I read about people's thoughts on security, and it chocks up to, If I do such-n-such, I can wipe my hands and walk away and not worry about this security problem ever again. I was not intending this for anyone in this discussion, mind you, but I think what separates "us" from "the rest of them" is the ability to not take these kinds of things for granted. So forgive me if I picked things apart there heheh .

[There0]

So forgive me if I picked things apart there heheh

Nothing to forgive, this is probably the best way for you to understand what everybody else here is offering, EVERY little bit helps and of course is up to you to decide on implementing or not.

Wether some script kiddi finds what port your only service may be on is only 1 layer of "security" for lack of a better word. Even NOT using passwords may still be "hacked" because of the daemon itself possesing vulnerabilities, thus i prefer a full layered, as much as i can approach to keeping mofo's out of my stuff

P.S. The REALLY skilled persons WILL find a way, i would rather at least try and deter them with more than 1 thing to have to get to.

[jggimi]

Wether some script kiddi finds what port your only service may be on is only 1 layer of "security" for lack of a better word.

The word is "obscurity". The OpenBSD Project historically frowns on using it, and they suggest people never confuse one with the other.