View Full Version : obsd 4.3 secure ssh use
milo974
07-02-2008, 01:54 PM
Hello, i'm newbie in openbsd.
I ve installed Openbsd 4.3 with pf (with NAT)
I ve a user : admin (not in wheel group) ; in /etc/sudoers i ve put :
admin ALL=/usr/sbin/vi /etc/pf.conf
admin ALL=/usr/sbin/pfctl
I have ssh access(with admin)to this firewall and so, i can change rules.
It works perfect. is it enough in security?
In my config, what is best way : use chroot or systrace? (for pf use in ssh environment)
thank's
jggimi
07-02-2008, 03:04 PM
It works perfect.Then you may have used chmod(1) or chown(8), or both, in order to provide rw access to /dev/pf. It is filemode 600 and owned by wheel:root in the default install. ....is it enough in security?It depends what you mean by the word security. We don't know what you mean by the word, or what else you've done, or what you intend.
Example, if you allow password authentication, and SSH access is exposed to the Internet, then I would consider your solution insecure. Others might think strong passwords are sufficient. Still more might recommend using a non-default port number. I wouldn't. But then, I don't know what you mean by "security."In my config, what is best way : use chroot or systrace? I don't see how either would apply to shell commands.
First, ask yourself, "What is it I wish to accomplish?" Once you have the answer, then you can search for a technical solution, and ask for advice or best practice. Don't start with technical tools, and ask if they apply to an ill-defined solution.
milo974
07-02-2008, 07:36 PM
the ssh access is exposed to internet, and password authentification.
Root cant connect to ssh access.
admin account is restricted :cant use su command ; can use only sudo vi /etc/pf.conf or sudo pfctl -f /etc/pf.conf.
My system is a colander ? in security terms ?
what i wish is when admin is connected, i want to change system root (chroot) and have an access to modify pf.conf and reload it. How can i do that ?
jggimi
07-02-2008, 09:05 PM
Do you have a colander? Maybe, maybe not. Things to think about:
Password authentication
As I mentioned above, I don't think passwords are good security.
How strong is your "admin" password? Any 8-character password can be broken by brute-force in a matter of days; if a dictionary attack is used and the password contains words or word fragments, it can be broken in a weekend. That's not good.
My recommendation: disable password authentication, and use alternative authentication methods.
OpenBSD supports many authentication technologies (see login.conf for most), including Kerberos and physical token systems. For simplicity with SSH, I happen to like public key authentication when keys can be stored remotely, and S/Key one-time-use passphrases when they can't (see skey and related man pages).
Sudo limitations
You are allowing vi to be executed as root. Once in the editor, the "admin" user can request a shell, and they will then have a root shell without restriction and without audit history.
If you are trying to limit what "admin" can do, you must only permit the execution of programs that that do not allow shell escapes.
------------------------------------------------------
If you are "admin" and you are trying to limit damage should someone acquire the password .... your best solution is to not use passwords, or not use them alone.
Current commercial best practice is to require binary authentication -- two different things:
Something you have (token device, binary key, biometric, etc.)
Something you know (passphrase, password, PIN, etc.)
ocicat
07-02-2008, 10:36 PM
admin account is restricted :cant use su command ; can use only sudo vi /etc/pf.conf or sudo pfctl -f /etc/pf.conf.
While sudo provides finer access granularity, the reason you are unable to use su is most likely due to the account lacking membership in the wheel group. For more information, see Section 10.1 of the FAQ:
http://openbsd.org/faq/faq10.html#wheel
As a newcomer to OpenBSD, you will save yourself significant time & aggravation by familiarizing yourself with the entire FAQ now while you are searching for common configuration answers.
TerryP
07-03-2008, 01:25 AM
You are allowing vi to be executed as root. Once in the editor, the "admin" user can request a shell, and they will then have a root shell without restriction and without audit history.
If you are trying to limit what "admin" can do, you must only permit the execution of programs that that do not allow shell escapes.
You should change it to force vi to run with the -S flag -> which forces the 'secure' option on (which can not be disabled without restarting vi without the -S switch afaik).
While 'secure' is set on in Vi, the user can not :! escape to a prompt or use external programs from within vi.
This is however, not to say that one could never conceivably bypass this attempt at a security feature.
It would also be ideal, that if you must make Vi available so easy -- to make sure to have a bloody log of it's actions if possible.
The script program can't log vi's actions properly but it can log ex, which is trivial to switch to vi mode.
jggimi
07-03-2008, 04:16 AM
If the goal is to allow a normal user, "admin" -- to edit /etc/pf.conf and issue pfctl commands, then neither sudo nor su are required. Instead:# chown admin /etc/pf.conf /dev/pf
----
There are many ways to accomplish any mission. The appropriate question is not, "How do I use X?" but rather, "I need to get something done. What are some of the ways I can do it?"
milo974
07-03-2008, 05:59 AM
so, if i remove password auth in sshd_config and put public key auth.
chown admin /etc/pf.conf /dev/pf
remove admin from wheel group
remove sudo commands (vi ; pfctl)
Is it enough in security terms
Thank's !
jggimi
07-03-2008, 11:58 AM
If your goal is to have "admin" be able to manage PF, but not have any other administrative capability, then yes....remove admin from wheel group...You started this thread by stating that "admin" was not a member of wheel. :confused:
milo974
07-03-2008, 12:23 PM
I have summarized
thank's !
vBulletin® v3.7.2, Copyright ©2000-2009, Jelsoft Enterprises Ltd.