Date: Fri, 10 Nov 2000 14:50:59 +0100 (CET) From: Christian Ruediger Bahls <christian@it-netservice.de> To: Aleksey Zvyagin <zal@ping.ru> Cc: freebsd-security@FreeBSD.ORG Subject: Re: About FreeBSD securelevel Message-ID: <Pine.BSF.4.21.0011101416380.1615-100000@phase2.intern.it-netservice.de> In-Reply-To: <001101c04a67$87b88e40$9600a8c0@zal.ping.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
you certainly forgot: chflags schg /
this implies chflags sunlnk /etc
and is always a good idea ..
securelevel should be higher than 1 anyway
(ever spend a thought about an evil attacker
that just erases your hardisk with a single newfs ?)
chflags schg /etc/*wd* is sometimes a good idea too ..
prevents an attacker from creating a user with uid=0 or a
throw_away-account ..
also a chflags -R sappnd /root as this closes some holes in ssh
(authentification by ~/.ssh/authorized keys [schg would be better]
which can be faked after intrusion, known_hosts should be sappnd as well)
/etc/inetd.conf should be schg as well (trojan horses;Backdoors)
sshd_config, ssh_config as well
ok to make it short:
chflags -P -R schg /bin /sbin /etc/* /modules* /misc /kernel* /boot*
chflags -P -R sappnd /root
chflags nosappnd,schg /root/.ssh/authorized_keys /root/.*
chflags -P -R schg /usr
be carefull not to include /home [where ever this is linked]
(in my case it has its own partition together with all user-writeable
tmp's so i have only one disk with qoutas /usr is mounted ro anyway)
chflags -P -R sunlnk /var
chflags -P -R schg /var/lib /var/games /var/crash /var/preserve
chflags sappnd /var/quotas
chflags -P -R sappnd /var/log <be carefull with this don't forget to
disable newsyslog, as you will get a lot of errormessages>
PS: never set /etc to sappnd because you will certainly get problems with
an undeleteable /etc/nologin thus preventing you from logging in
remote after a reboot
PPS: use a securelevel > 1 if this machine is a firewall
this prevents an intruder from changing your firewall ruleset
on the fly, also make everything that has to do with your firewall
schg .. :)
PPPS: for the real paranoid .. if you exspect user to be able to use the
console mark /dev/console[ or better /dev/tty* as well] insecure
and disable kerneldebugger
yours ..
tiptoe ..
On Thu, 9 Nov 2000, Aleksey Zvyagin wrote:
> Hello!
>
> I have read the security FreeBSD document
> (http://people.freebsd.org/~jkb/howto.html) and would
> like to improve the doc about securelevel
>
> I found some "exploits" for securelevel what it desribes. My language is bad
> thus i will be brief.
>
> If a system administrator will set FreeBSD (FreeBSD 2.2.6 and more) with
> these the advises then a hacker will low securelevel following ways:
>
> 1. to correct the file /etc/default/rc.conf and to low securelevel there
> 2. to move /etc to /foo and then to create a copy of /etc without schg flags
> and then restart FreeBSD (after a correction of /etc/rc.conf file)
> 3. To correct /etc/rc.conf
> 4. To move /usr/bin & /usr/sbin directories to /usr/foo1 /usr/foo2 and then
> to fake the system progs
> 5. To correct some /etc/rc.* files so as the /etc/rc exits at error of shell
> before the setting kern.securelevel > 0
> 6. All above changes come into effect at restart FreeBSD by hacker command
> "shutdown -r now" for example.
>
> >From the above exploits i see the following resolves:
>
> chflags schg to:
> /boot.config
> /kernel
> /boot/*
> /etc/rc*
> /etc/defaults/*
> /bin/*
> /sbin/*
> /usr/bin/*
> /usr/sbin/*
> /usr/lib/*
>
> chflags sunlnk to:
> /etc
> /boot
> /bin
> /sbin
> /usr/bin
> /usr/sbin
> /usr/lib
> /etc/defaults
>
> And i would like to offer you for a publication at FreeBSD my toolkit for a
> lowing securelevel at remote server of system administrator by password
> file. Thus the hacker of remote server (at ISP for example) will not be able
> to low securelevelbut the system administrator will be able to low
> securelevel (far from server). Do anybode need this toolkit?
>
> P.S. Please to forward me your letters to zal@ping.ru address (or reply to
> "From" address)
>
> Thank you
> Aleksey Zvyagin, Russia, system administrator and web programmer.
>
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
>
--
Christian Bahls
Networking Dep.
iT-netservice GmbH
Leipzig, Germany
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011101416380.1615-100000>