Re: /usr/share/pf/ suggestion

2005-08-24 Thread Timothy Donahue
On Tuesday 23 August 2005 11:58 pm, eric wrote:
 On Tue, 2005-08-23 at 16:53:25 -0600, Theo de Raadt proclaimed...

  It is plain simple bad advice.  And totally ridiculous.

 And plus, with ipv6, it's imperative that the filters be pushed down to the
 end-host so we can quit relying on stupid firewalls and NAT bullshit to
 break networks and slow progress. Itojun mentioned the fact that each host
 should have a firesuit in the ipv6 world.  It's quite good advice.

Well, lets not get ahead of ourselves here.  Filtering at the network edge is 
A Good Thing(TM) when done correctly, it is NAT that is not necessarily a 
good thing.  Filtering incoming (and possibly outgoing traffic) helps do 
several things, first it decreases the burden on your hosts.  It also allows 
you a place to stop traffic that should never leave your network, for 
example, only your mail servers should be allowed to send traffic on port 25.

I'm not saying that we should ignore host based firewalls, because that isn't 
the case, I'm just recommending that you not be so quick to dismiss the value 
of having a filter beyond the host.



Re: /usr/share/pf/ suggestion

2005-08-24 Thread Will H. Backman
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
 Bryan Irvine
 Sent: Wednesday, August 24, 2005 10:11 AM
 To: Misc OpenBSD
 Subject: Re: /usr/share/pf/ suggestion
 
  I personally like to 'pass keep state' with a 'scrub all' rule. This
  at least gives me some interesting statistics to poke at when I'm
  bored. Plus, I can firewall who gets to ssh into my machine.
 
 Another good use is {max-src-states  ##} for webservers and the like.
 I have a webserver that would crash at 9am every morning when a few
 bots (2 in particaular) would crawl the site.  They are poorly
 configured and open roughly 120 simlutaneous connections.  They were
 very low bandwidth, but there went all available connections.
 
 To quote Theo it's Horse-shit to say you don't need to filter single
 hosts.
 
 --Bryan

What crashed?  Apache or OpenBSD?



Re: /usr/share/pf/ suggestion

2005-08-24 Thread Bryan Irvine
 I personally like to 'pass keep state' with a 'scrub all' rule. This
 at least gives me some interesting statistics to poke at when I'm
 bored. Plus, I can firewall who gets to ssh into my machine.

Another good use is {max-src-states  ##} for webservers and the like. 
I have a webserver that would crash at 9am every morning when a few
bots (2 in particaular) would crawl the site.  They are poorly
configured and open roughly 120 simlutaneous connections.  They were
very low bandwidth, but there went all available connections.

To quote Theo it's Horse-shit to say you don't need to filter single hosts.

--Bryan



Re: /usr/share/pf/ suggestion

2005-08-24 Thread Ray Percival
On Wed, Aug 24, 2005 at 09:15:48AM -0400, Timothy Donahue wrote:
 On Tuesday 23 August 2005 11:58 pm, eric wrote:
  On Tue, 2005-08-23 at 16:53:25 -0600, Theo de Raadt proclaimed...
 
   It is plain simple bad advice.  And totally ridiculous.
 
  And plus, with ipv6, it's imperative that the filters be pushed down to the
  end-host so we can quit relying on stupid firewalls and NAT bullshit to
  break networks and slow progress. Itojun mentioned the fact that each host
  should have a firesuit in the ipv6 world.  It's quite good advice.
 
 Well, lets not get ahead of ourselves here.  Filtering at the network edge is 
 A Good Thing(TM) when done correctly, it is NAT that is not necessarily a 
 good thing. 
Speaking as a network guy NAT is A Good Thing granted it breaks some outdated 
notion of end to end commo. But if more people payed strict attention to the 
OSI model that would not matter. Simply put if an application puts a IP addy 
someplace my NAT box can't touch it the application is broken. And in today's 
world anything that puts one more layer between my network and the net is good. 
Other than that I agree with everything else you've said. 
 Filtering incoming (and possibly outgoing traffic) helps do 
 several things, first it decreases the burden on your hosts.  It also allows 
 you a place to stop traffic that should never leave your network, for 
 example, only your mail servers should be allowed to send traffic on port 25.
 
 I'm not saying that we should ignore host based firewalls, because that isn't 
 the case, I'm just recommending that you not be so quick to dismiss the value 
 of having a filter beyond the host.
 

-- 
BOFH excuse #381:

Robotic tape changer mistook operator's tie for a backup tape.



Re: /usr/share/pf/ suggestion

2005-08-24 Thread Jason Crawford
On 8/24/05, Bryan Irvine [EMAIL PROTECTED] wrote:
  I personally like to 'pass keep state' with a 'scrub all' rule. This
  at least gives me some interesting statistics to poke at when I'm
  bored. Plus, I can firewall who gets to ssh into my machine.
 
 Another good use is {max-src-states  ##} for webservers and the like.
 I have a webserver that would crash at 9am every morning when a few
 bots (2 in particaular) would crawl the site.  They are poorly
 configured and open roughly 120 simlutaneous connections.  They were
 very low bandwidth, but there went all available connections.
 
 To quote Theo it's Horse-shit to say you don't need to filter single hosts.
 

I left out a lot of my reasoning for feeling the way I do in my first
mail about not needing a packet filter on single hosts, and it's more
a personal preference, not telling everyone that you're all idiots for
wanting to. If your web server crashes because it has 240 connections
open (I'm assuming 120 per bot) then there seems to be something else
wrong with it, and shouldn't be ignored by just throwing up pf. It was
more that for me, if I throw up pf to protect a single host, I tend to
get lazy in the administration of it, and start ignoring things that
should really be looked at (like applications opening up random ports,
in reference to an earlier KDE post). I really don't think that a
desktop environment should be opening up anything at all, and so I'd
rather just not run it instead of run a desktop environment that I
have no idea what it's doing on the network. If anyone is interested
any further as to why I feel the way I do, email me privately, since
this is getting way off topic and doesn't belong on the openbsd-misc
mailing list anyways.

Jason



Re: /usr/share/pf/ suggestion

2005-08-24 Thread eric
On Wed, 2005-08-24 at 09:15:48 -0400, Timothy Donahue proclaimed...

 A Good Thing(TM) when done correctly, it is NAT that is not necessarily a 
 good thing.  Filtering incoming (and possibly outgoing traffic) helps do 
 several things, first it decreases the burden on your hosts.  It also allows 
 you a place to stop traffic that should never leave your network, for 
 example, only your mail servers should be allowed to send traffic on port 25.

Ha, sure. Now get a job outside your little corporate entity and see how
that goes over. Then let us decide on our own policies.



Re: /usr/share/pf/ suggestion

2005-08-24 Thread Bryan Irvine
 What crashed?  Apache or OpenBSD?
 

Apache of course! ;)



/usr/share/pf/ suggestion

2005-08-23 Thread Will H. Backman
Would it be useful to add an example pf rule set for just a simple host?
All of the examples assume a router.

--
Will Backman - Network Administrator
Coastal Enterprises, Inc.
http://www.ceimaine.org



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Will H. Backman
 -Original Message-
 From: j knight [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, August 23, 2005 4:47 PM
 To: Will H. Backman
 Subject: Re: /usr/share/pf/ suggestion
 
 --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400:
 
  Would it be useful to add an example pf rule set for just a simple
host?
  All of the examples assume a router.
 
 
 This would be more useful in the faq. Please send what you've written.
 
 :-)
 
 
 
 .joel

# pf rules for a stand alone machine.

#Change external interface to match yours
ext_if=xl0

scrub in all

block in all

pass out keep state

pass quick on lo all



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Will H. Backman
 -Original Message-
 From: Jason Crawford [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, August 23, 2005 5:25 PM
 To: Will H. Backman
 Cc: j knight; Misc OpenBSD
 Subject: Re: /usr/share/pf/ suggestion
 
 On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote:
   -Original Message-
   From: j knight [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, August 23, 2005 4:47 PM
   To: Will H. Backman
   Subject: Re: /usr/share/pf/ suggestion
  
   --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400:
  
Would it be useful to add an example pf rule set for just a
simple
  host?
All of the examples assume a router.
   
  
   This would be more useful in the faq. Please send what you've
written.
  
   :-)
  
  
  
   .joel
 
  # pf rules for a stand alone machine.
 
  #Change external interface to match yours
  ext_if=xl0
 
  scrub in all
 
  block in all
 
  pass out keep state
 
  pass quick on lo all
 
 
 First off, it should be, set skip on lo0 (or lo, but by default
 there's only one lo interface anyways). Secondly, it seems pretty
 pointless to setup pf on a single host. Instead of worrying about the
 firewall, which takes up more memory and cpu and all that, just shut
 off services that you don't need and be done with it. If the attacker
 can hurt your OpenBSD machine, then your firewall is vulnerable as
 well, and it won't protect any applications that need open ports
 listening. Turning off services is always much better than turning on
 services (pf) if you need protection. And the way OpenBSD is setup by
 default, nothing is listening except a couple inetd services (which I
 always turn off), and sshd if you said y in install, that's it.
 
 Jason

I agree in general, but then start adding the gnome or kde desktop or
other applications and you never know what is listening.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Jason Crawford
On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote:
  -Original Message-
  From: j knight [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, August 23, 2005 4:47 PM
  To: Will H. Backman
  Subject: Re: /usr/share/pf/ suggestion
 
  --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400:
 
   Would it be useful to add an example pf rule set for just a simple
 host?
   All of the examples assume a router.
  
 
  This would be more useful in the faq. Please send what you've written.
 
  :-)
 
 
 
  .joel
 
 # pf rules for a stand alone machine.
 
 #Change external interface to match yours
 ext_if=xl0
 
 scrub in all
 
 block in all
 
 pass out keep state
 
 pass quick on lo all
 

First off, it should be, set skip on lo0 (or lo, but by default
there's only one lo interface anyways). Secondly, it seems pretty
pointless to setup pf on a single host. Instead of worrying about the
firewall, which takes up more memory and cpu and all that, just shut
off services that you don't need and be done with it. If the attacker
can hurt your OpenBSD machine, then your firewall is vulnerable as
well, and it won't protect any applications that need open ports
listening. Turning off services is always much better than turning on
services (pf) if you need protection. And the way OpenBSD is setup by
default, nothing is listening except a couple inetd services (which I
always turn off), and sshd if you said y in install, that's it.

Jason



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Theo de Raadt
 Secondly, it seems pretty pointless to setup pf on a single host.

  

That is the most ridiculous thing I've heard all day.  Lots of people
run servers and must block them, on the same machine.  Probably every
single one of us.

 Instead of worrying about the
 firewall, which takes up more memory and cpu and all that, just shut
 off services that you don't need and be done with it. If the attacker
 can hurt your OpenBSD machine, then your firewall is vulnerable as
 well, and it won't protect any applications that need open ports
 listening. Turning off services is always much better than turning on
 services (pf) if you need protection. And the way OpenBSD is setup by
 default, nothing is listening except a couple inetd services (which I
 always turn off), and sshd if you said y in install, that's it.

Anyone who says I only need to block packets in my firewall has got
it all wrong.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Stuart Henderson

--On 23 August 2005 17:25 -0400, Jason Crawford wrote:


Secondly, it seems pretty pointless to setup pf on a single host.


It has it's uses - spamd, for one...



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Theo de Raadt
  That is the most ridiculous thing I've heard all day.  Lots of people
  run servers and must block them, on the same machine.  Probably every
  single one of us.
 
 I'm not sure I understand what you mean. If you're going to run a
 server, what's the point of blocking it? Might as well turn it off.

My laptops filter port 6000 and up, thank you very much.

I will not stop running X.

You must just just plain not understand what you are saying.

Your statements are beyond ridiculous.  You are saying If you need
to filter it, you should not be running it.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Theo de Raadt
 I never said that. PF isn't the only way to block packets, like TCP
 wrappers or ACL's within the server itself.

That is horse shit, and shows that you don't know how actual code works.
I prefer to filter problems BEFORE THE ACTUAL CODE RUNS.  Perhaps you
don't know what a pre-authentication bug is.

 It seems that adding
 another layer to the mix takes up more CPU and RAM than needed, since
 most servers have some sort of ACL list for acceptable hosts, and tcp
 wrappers does a good job too.

More horshit.  It uses LESS memory and cpu than all that TCP filters,
and actually making the application wake up and decide that it does
not want a connection.

You are 100% wrong.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Jason Crawford
On 8/23/05, Stuart Henderson [EMAIL PROTECTED] wrote:
 --On 23 August 2005 17:25 -0400, Jason Crawford wrote:
 
  Secondly, it seems pretty pointless to setup pf on a single host.
 
 It has it's uses - spamd, for one...
 
Which is already covered in the spamd man page and doesn't need
another entry in the FAQ.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Jason Crawford
On 8/23/05, Theo de Raadt [EMAIL PROTECTED] wrote:
  Secondly, it seems pretty pointless to setup pf on a single host.
 
   
 
 That is the most ridiculous thing I've heard all day.  Lots of people
 run servers and must block them, on the same machine.  Probably every
 single one of us.

I'm not sure I understand what you mean. If you're going to run a
server, what's the point of blocking it? Might as well turn it off.

 
  Instead of worrying about the
  firewall, which takes up more memory and cpu and all that, just shut
  off services that you don't need and be done with it. If the attacker
  can hurt your OpenBSD machine, then your firewall is vulnerable as
  well, and it won't protect any applications that need open ports
  listening. Turning off services is always much better than turning on
  services (pf) if you need protection. And the way OpenBSD is setup by
  default, nothing is listening except a couple inetd services (which I
  always turn off), and sshd if you said y in install, that's it.
 
 Anyone who says I only need to block packets in my firewall has got
 it all wrong.

I never said that. PF isn't the only way to block packets, like TCP
wrappers or ACL's within the server itself. It seems that adding
another layer to the mix takes up more CPU and RAM than needed, since
most servers have some sort of ACL list for acceptable hosts, and tcp
wrappers does a good job too.

Jason



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Theo de Raadt
  Your statements are beyond ridiculous.  You are saying If you need
  to filter it, you should not be running it.
 
 X doesn't have to listen on TCP 6000, you can setup a unix socket, and
 it's no longer reachable from the network, and you still have full
 functionality (I know, I do just that).

And I don't have the TIME OF DAY to do that, it is EASIER to filter!

AND IT USES LESS PROCESSOR!

AND IT USES LESS MEMORY!

 There's more than one way to
 do anything. If something needs to only be locally accessable, only
 have it listen locally, or use unix sockets instead of tcp/udp sockets
 completely.

No, that is not what you said:  You did not say there are many ways
to do this.

Instead, you very specifically suggested that people NOT filter using
the packet filter, but to instead configure applications, or to NOT
run the servers in those locations then.

And THAT is what is utterly ridiculous.

It is plain simple bad advice.  And totally ridiculous.

You're wrong.  People should run packet filters wherever they want,
since in many cases it is EASIER than thousands of lines of later
code running and having a pre-authentication bug.

Telling people to go tune their applications, tune tune tune tune,
that is the mantra of Linux people who then run out of time and
expertise, and then leave their machines open.

People will NOT avoid running kde which opens half a thousand stupid
ports, and they will NOT go and learn to configure those applications
with a thousand buttons, because they don't have the TIME OF DAY to
follow your ridiculous push more buttons you don't know advice.

You're wrong.  Everyone -- run pf wherever you find it easier.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Jason Crawford
On 8/23/05, Theo de Raadt [EMAIL PROTECTED] wrote:
   That is the most ridiculous thing I've heard all day.  Lots of people
   run servers and must block them, on the same machine.  Probably every
   single one of us.
 
  I'm not sure I understand what you mean. If you're going to run a
  server, what's the point of blocking it? Might as well turn it off.
 
 My laptops filter port 6000 and up, thank you very much.
 
 I will not stop running X.
 
 You must just just plain not understand what you are saying.
 
 Your statements are beyond ridiculous.  You are saying If you need
 to filter it, you should not be running it.

X doesn't have to listen on TCP 6000, you can setup a unix socket, and
it's no longer reachable from the network, and you still have full
functionality (I know, I do just that). There's more than one way to
do anything. If something needs to only be locally accessable, only
have it listen locally, or use unix sockets instead of tcp/udp sockets
completely.

Jason



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Shawn K. Quinn
On Tue, 2005-08-23 at 17:25 -0400, Jason Crawford wrote:
 Secondly, it seems pretty pointless to setup pf on a single host.

I beg to differ. man pf.conf, and look at the user and group
keywords.

-- 
Shawn K. Quinn [EMAIL PROTECTED]



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Aaron Glenn
On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote:
 
 I agree in general, but then start adding the gnome or kde desktop or
 other applications and you never know what is listening.
 

what the hell?



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Ray Percival
On Tue, Aug 23, 2005 at 06:57:43PM -0400, Will H. Backman wrote:
  -Original Message-
  From: Theo de Raadt [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, August 23, 2005 6:53 PM
  To: Jason Crawford
  Cc: Will H. Backman; j knight; Misc OpenBSD
  Subject: Re: /usr/share/pf/ suggestion
  
snip 
 (Crawling out of my protective hole)
 So does it make sense to include a basic pf rule set for a basic
 end-user host that blocks everything by default?
 I've done it using the example I gave.  Don't know if my way has some
 errors or not.
I'd say punch a hole for SSH. This is because I consider a *NIX box that can 
not be managed via SSH to be borken.

 And, of course, we are only talking about having this as an example and maybe 
mentioned in a FAQ someplace and not turned on by defualt, right?
 

-- 
BOFH excuse #394:

Jupiter is aligned with Mars.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Nigel Wohlers

There is an example:

set pf=YES in /etc/rc.conf.local reboot

pfctl -sr will give you:

block drop all
pass on lo0 all
pass in proto tcp from any to any port = ssh keep state
pass out proto tcp from any to any port = domain keep state
pass out proto udp from any to any port = domain keep state
pass out inet proto icmp all icmp-type echoreq keep state
pass proto pfsync all
pass proto carp all


i.e Invoked from /etc/rc

if [ X${pf} != XNO ]; then
RULES=block all
RULES=$RULES\npass on lo0
RULES=$RULES\npass in proto tcp from any to any port 22 keep state
RULES=$RULES\npass out proto { tcp, udp } from any to any port 53 keep 
state
RULES=$RULES\npass out inet proto icmp all icmp-type echoreq keep 
state
RULES=$RULES\npass proto { pfsync, carp }
case `sysctl vfs.mounts.nfs 2/dev/null` in
*[1-9]*)
# don't kill NFS
RULES=scrub in all no-df\n$RULES
RULES=$RULES\npass in proto udp from any port { 111, 2049 } to 
any
RULES=$RULES\npass out proto udp from any to any port { 111, 2049 
}
;;
esac
echo $RULES | pfctl -f - -e
fi




On Tue, Aug 23, 2005 at 06:57:43PM -0400, Will H. Backman wrote:


I'd say punch a hole for SSH. This is because I consider a *NIX box that can 
not be managed via SSH to be borken.

 And, of course, we are only talking about having this as an example and maybe 
mentioned in a FAQ someplace and not turned on by defualt, right?




Re: /usr/share/pf/ suggestion

2005-08-23 Thread eric
On Tue, 2005-08-23 at 16:53:25 -0600, Theo de Raadt proclaimed...

 It is plain simple bad advice.  And totally ridiculous.

And plus, with ipv6, it's imperative that the filters be pushed down to the
end-host so we can quit relying on stupid firewalls and NAT bullshit to
break networks and slow progress. Itojun mentioned the fact that each host
should have a firesuit in the ipv6 world.  It's quite good advice.



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Uwe Dippel
On Tue, 23 Aug 2005 16:53:25 -0600, Theo de Raadt wrote:

 You're wrong.  Everyone -- run pf wherever you find it easier.

Followed this discussion with interest.
Doing the same thing (running pf) on my single-ended boxes; I actually
questioned myself why all of this is not part of the base install. Would
make my life easier; with pf turned on instead of me turning it on; and a
default pf.conf that opens 22 only and only in case I had decided to run
sshd during install. 
With the macros in PF it is much much easier to simply add service 
identifiers if I wanted more. And pfstat being in the base as well !
Would simplify my installs even more: vi /etc/pf.conf, add / remove
services there. Over. Browse newbox.mydomain.com/usage/pfstat.png (because
I'd add httpd-flags, and http in pf.conf), and I'd be knowing what is
going on two minutes after reboot. 
Plus, I'd feel even safer out of the box.

Uwe



Re: /usr/share/pf/ suggestion

2005-08-23 Thread Siju George
On 8/24/05, Jason Crawford [EMAIL PROTECTED] wrote:
 On 8/23/05, Will H. Backman [EMAIL PROTECTED] wrote:
   -Original Message-
   From: j knight [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, August 23, 2005 4:47 PM
   To: Will H. Backman
   Subject: Re: /usr/share/pf/ suggestion
  
   --- Quoting Will H. Backman on 2005/08/23 at 14:59 -0400:
  
Would it be useful to add an example pf rule set for just a simple
  host?
All of the examples assume a router.
   
  
   This would be more useful in the faq. Please send what you've written.
  
   :-)
  
  
  
   .joel
 
  # pf rules for a stand alone machine.
 
  #Change external interface to match yours
  ext_if=xl0
 
  scrub in all
 
  block in all
 
  pass out keep state
 
  pass quick on lo all
 
 
 First off, it should be, set skip on lo0 (or lo, but by default
 there's only one lo interface anyways). Secondly, it seems pretty
 pointless to setup pf on a single host. 


Actually you need not see PF as a tool that can be implemented only on
a firewall an so on.
For example. If you have a LAN that has webservers, ftpservers and so
on in it, Protecting the entire LAN and its Servers from the Internet
with an OpenBSD firewall and PF is good! but doing that alone would
put the systems on your LAN especially servers at risk from Internal
threats. You could enable PF on your servers and have appropriate
rules to allow only certain hosts or users to access certain services
on them. You could enable PF on your work stations and with
appropriate rules it will act as an excellent personal firewall. This
is especially true if you are directly connecting your servers,
computers, laptops directly to the internet.

Jacek Arymiak explains its importance in his book Building Firewalls
with OpenBSD and PF

Instead of worrying about the
 firewall, which takes up more memory and cpu and all that, just shut
 off services that you don't need and be done with it. If the attacker
 can hurt your OpenBSD machine, then your firewall is vulnerable as
 well, and it won't protect any applications that need open ports
 listening. Turning off services is always much better than turning on
 services (pf) if you need protection.


I think turning on PF and putting the right kind of rules in
/etc/pf.conf is the best thing you can do on any OpenBSD system if
your concern is security.

 And the way OpenBSD is setup by
 default, nothing is listening except a couple inetd services (which I
 always turn off),


If you enable PF and want FTP traffic to function properly with Active
ftp-servers then you must enable ftp-proxy in inetd.conf and should
not disable it.


and sshd if you said y in install, that's it.
 

Following the patches and applying them as soon as they are released
should keep you securely running the ssh service in your OpenBSD.
Ofcourse you should be careful not to allow direct root access and
follow best practices like not giving dictinary words as passwords etc
to your users.

Hope this helps :-)

kind regards

Siju