Tammy Lyn <Tlyn@notformail.com> wrote:
> On Fri, 09 May 2008 02:35:49 +0200, Joachim Schipper wrote:
>> Tammy Lyn <Tlyn@notformail.com> wrote:
>>> 2...Xorg is listening on port 6000. I don't (...) want that.
>>
>> It doesn't (...) accept data (...). [It] is harmless.

> Cool.

> I'm behind a router and the "Shields Up" test show no open ports.

> Do I still need PF?

No, you almost never need pf unless you are building a firewall. (Not
a ZoneAlarm-style "host-based firewall" - a real firewall.)

>>> 3...'netstat -an' is showing my computer is listening on several ports
>>> by default. How to disable sendmail etc?
>>
>> sendmail(8) doesn't accept data (...) by default.
>
> So it's okay to run sendmail for security reports etc?
> What about syslogd?
> On FreeBSD
>
> syslogd_enable="YES"
> syslogd_program="/usr/sbin/syslogd"
> syslogd_flags="-ss"
>
> syslogd_flags="-ss" will stop outside connections.
> Does openbsd's syslog allow incoming connections?

Yes, you will need to run sendmail to receive security reports and cron
output and the like. You can configure it to send to an external
mailserver, called a "smarthost" in sendmail terminology, but you'll
have to look the details up yourself - I never used sendmail.
Configuration files are under /usr/share/sendmail/cf.

syslogd(8) will only accept data from outside if you add "-u" to
syslogd_flags in /etc/rc.conf.local. (By convention, /etc/rc.conf holds
the defaults and a little documentation, and /etc/rc.conf.local holds
any local settings. This is analogous to how /etc/rc is the default
start script and /etc/rc.local holds local additions.)

>> sshd(8) is also listening; make sure you either have a strong password
>> for all relevant accounts or disallow password logins altogether.
>
> I don't need sshd. How to disable? /etc/rc.conf sshd_enable=NO?

sshd_flags=NO in /etc/rc.conf.local.

>> The rest are run by inetd(8), see /etc/inetd.conf.
>
> Since this is a desktop system. I can disable inetd?
> I don't want any incoming connections to my computer from the outside. No telnet/sshd etc.
>
> A fresh OpenBSD install disable these incoming connection by default unless you allow them?

Yes, you can disable inetd without problems. inetd=NO in
/etc/rc.conf.local.

By default, OpenBSD enables three services in /etc/inetd.conf

$ grep '^[^\#]' /etc/inetd.conf
ident stream tcp nowait _identd /usr/libexec/identd identd -el
ident stream tcp6 nowait _identd /usr/libexec/identd identd -el
daytime stream tcp nowait root internal
daytime stream tcp6 nowait root internal
time stream tcp nowait root internal
time stream tcp6 nowait root internal

identd can be used by external services to request which user opened a
connection. It is an old protocol. A few mail servers require it if you
want to send them messages (directly; you can always send mail via your
ISP or another mail service). Additionally, it is used by IRC.

You can add -h or -H (which hide information) or disable identd
altogether. It is pretty much only used in the above two cases, so feel
free to disable it.

daytime and time simply report the time. They are harmless, and can be
disabled without harm.

>> Relax. OpenBSD is secure by default.
>
> Yes, that's why I chose it. My problem is that I don't know how to
> tweak the system to make it secure. Jails/ and mandatory access
> control etc.

Very little tweaking is required unless you install (a lot) of
additional packages. The system is well-audited, presents few surfaces
for attack, and most important daemons run in a jail by default. (Apache
httpd and named, for instance.)
If you do install external packages, try to select secure packages and
configure them accordingly.

If, at some point, you do need to jail something, ktrace(1) can be
useful if it doesn't work. It shows you all system calls (filesystem
interactions etc) and their results, which can help in finding out that
some program tries to read a file you hadn't thought of. It can be
pretty verbose - grep for file-like things or system calls like open.

OpenBSD does not have a functional mandatory access control framework at
this time: securelevel 2 (see securelevel(7)) works as documented, but
there are quite a few ways around the documented functionality, and
systrace(8) is mostly functional but there are some rare cases in which
it is possible to alter the parameters of a system call after the system
call has been allowed by the systrace ruleset. In short, either have a
lot of limitations.
This is not seen as a big problem by most of the community - OpenBSD has
a secure kernel running secure binaries, and all of the standard *nix
security:
- pretty much each daemon has its own uid
- chroot() is used where appropriate
- many daemons that both interact with the network and need (root)
privileges have been implemented as two parts, one of which has no
privileges and one of which does not talk to the network. (Look at "ps
ax | grep ntpd" for an example, if you are running ntpd(8).)
- the base system, including external packages like httpd and named, has
been audited and secured as appopriate.

In addition, OpenBSD has some tricks that make it harder to exploit
common vulnerabilities (W^X, ProPolice, etc).

This is not OpenBSD-specific, but you should consider using sudo(8) for
almost all system administration tasks, instead of logging in as root or
su(8). Other than that, you are already pretty secure. Even swap is
encrypted by default! (Useful to make sure passwords etc. never touch
the disk.)

> Sorry about the word wrap. I was using the default word wrap in PAN.
> Hope I got that fixed.

Yes, you did. Thanks! And good luck, let us know if you have any more
trouble.

Joachim