View Single Post
  #5   (View Single Post)  
Old 10th April 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,983
Default

I'll post this follow-up, scupper, since you haven't yet had the time or opportunity to post any further information. Based solely upon the information provided by your first post, I can make the following guesses. These are guesses, based upon your description of a newly installed OpenBSD system and with the assumption that no third party applications have yet been installed.

Immediately compromised OpenBSD systems are possible if:
  • You are running the OS as a guest virtual machine (VMWare, Qemu, Virtualbox, etc.) on a compromised host OS or hypervisor.
  • You enabled the SSH daemon upon install and chose an insecure superuser (root) password. The default SSH daemon configuration permits root login and passwords for authentication, for ease of remote provisioning of newly installed OpenBSD systems.
    • The recommended best practice is to configure PermitRootLogin to no for production SSH servers, and to set PasswordAuthentication to no once an alternative authentication schema has been configured.
That's basically it for the default installation. The default OpenBSD installation itself should not normally be vulnerable to external attacks from the network, even if the router you are using has been compromised.

Please note: it is unlikely that OpenBSD's audio system has been compromised via network attack. The sndiod(1) audio server does not use a network connection unless the admin configures it to do so (see the -L option). You are more likely the victim of social engineering and intimidation than a successful technical attack. At least, against a default OpenBSD installation.
This is why I asked about /var/log/authlog -- if you have permitted root access to others, your actions have compromised your system. Using the SSH daemon as an example -- once you start provisioning services and applications on OpenBSD, you could easily make mistakes through ignorance or inexperience and open your system to being compromised.
Physical access should also be considered. Anyone with physical access to your workstation has access to any unencrypted data stored on it. They do not need your root password. OpenBSD can be deployed with encrypted filesystems, but that is manual customization and not available as component of the installation script.

Last edited by jggimi; 10th April 2014 at 01:35 PM. Reason: fixed man page link, added physical access comment.
Reply With Quote