В этой секции мы расскажем об основных методах защиты и
обеспечивания безопасности Вашей системы FreeBSD, которые были
упомянуты в предыдущей секции
этой главы.
В первую очередь нужно обеспечить безопасность
суперпользовательского аккаунта, и уже после принимать аналочичные
меры в отношении прочих привелигированных аккаунтов. Во многих
системах аккаунт суперпользователя защищен паролем. Имейте в виду,
что этот пароль крайне важен, а поэтому нелишним будет относиться к
нему с очень большой осторожностью. Прежде всего, желательно
не использовать его кроме как за консолью, даже применяя команду
su(1). В частности, удостоверьтесь, что терминалы, перечисленные
в файле /etc/ttys, помечены как insecure
(небезопасные), чтобы запретить прямой доступ посредством команд
telnet или rlogin. При
использовании других сервисов, таких, например, как
sshd, также следует запретить
непосредсвенный вход в систему с правами суперпользователя.
Проверьте все возможные подступы к системе - сервисы типа
FTP чато оказываются подверженными атакам. Непосредственный
вход в систему с правами суперпользователя следует разрешить
только с консоли.
Конечно, Вам как системному администратору необходимо иметь
возжожность получить права суперпользователя, поэтому несколько
путей все же есть. Однако, очень важно защитить их использование
дополнительными паролями. Один из способов дать какому-либо
пользователю повышенные привилегии - это перечислить его
в группе wheel (в файле
/etc/group). Пользователь, входящий в эту
группу, может вызвать su для получения прав
суперпользователя. Не следует включать всех членов служебного
персонала в группу wheel, задавая ее как основную
группу пользователя в файле паролей. Вместо этого, нужно включить
их в специальную группу staff, и затем, только
в случае необходимости, некоторых из них включить в группу
wheel, сделав соответсвующую запись в файле
/etc/group. Также возможно, при использовании
методов аутентикации типа kerberos, использовать файл
.k5login для того, чтобы разрешить получение
привилегий супервозователя посредствеом команды ksu(1) без
необходимости включать кого-либо в группу wheel.
Это может оказаться лучшим решением, так как предыдущий метод
позволяет хакеру получить права суперпользователя, если ему удастся
получить доступ к служебному акканту. Тем не менее, все это лучше,
чем ничего.
Аккаунт суперпользователя можно защитить косвенным путем,
посредством использования альтернативных методов аутентикации и
замены хэшированных паролей служебных аккаунтов на символ
* в файле паролей (/etc/passwd). В этом случае,
даже если взломщик получит этот файл, он не сможет извлечь оттуда
пароли, включая пароль суперпользователя. Сотрудники служебного
персонала будут сходить в систему при помощи защищенного механизма
аутентикации, например, kerberos(1) или ssh(1), используя
специальную пару ключей (приватный/публичный). При использовании
систем типа kerberos, Вам потребуется обеспечить безопасность
kerberos-серверов и Вашей рабочей станции. При использовании
механизма публичного/приватного ключей, например, при работе с
ssh, Вам необходимо обеспечить
безопасность машины, с которой Вы будете
заходить в систему (обычно это Ваша рабочая станция), но можно также
обеспечить себе дополнительную безопасность, защитив пару ключей
паролем в момент ее генерации (ssh-keygen(1)). Возможность
заменять реальные хэши паролей на символ * в
файле паролей (это особенно важно для аккаунтов служебного
персонала, обладающего повышенными привилегиями по сравнению с
обычными пользователями) также гарантирует, что они будут
пользоваться только безопасными методами аутентикации, которые Вы
предварительно настроили. Это хорошо тем, что закрывает наиболее
часто используемую взломщиками дыру - прослушивание
("сниффинг") сети с менее защищенной машины (на которой
у него уже есть все необходимые привилегии).
Еще стоит обратить внимание на следующие моменты: если Ваш
основной сервер предоставляет всевозможные сетевые сервисы, то на
Вашей рабочей станции по возможности максимальное число сетевых
служб должно быть отключено (а в идеале - все), и нелишним
будет использование хранителя экрана, защищенного паролем. Конечно,
если у злоумышленника есть физический доступ к машине, то
практически никакие методы защиты не помогут (хотя и могут
значительно увеличить время взлома), однако большинство атак все же
происходят снаружи, по сети, когда у атакующего нет
непосредственного доступа к системе.
При использовании систем аутентикации типа kerberos, у Вас есть возможность централизованно менять пароли или блокировать доступ пользователей. Это очень полезно при подозрении, что пароль какого-либо (например, администраторского) аккаунта стал известен постороннему лицу - в этом случае можно очень быстро запретить вход на все машины, где был заведен данный пользователь. Представьте себе, насколько труднее и дольше было бы менять пароли на каждой из N машин отдельно! Kerberos предосталяет и другие возможности (принудительная смена пароля по истечении определенного промежутка времени, например).
Осторожный системный администратор конфигурирует систему так, чтобы запущены были только самые необходимые сервисы. Не больше, не меньше. Стоит с особой осторожностью отновиться
tHE prudent sysadmin only runs the servers he needs to, no more, no less. Be aware that third party servers are often the
most bug-prone. For example, running an old version of imapd or
popper is like giving a universal root ticket out to the entire
world. Never run a server that you have not checked out
carefully. Many servers do not need to be run as root. For
example, the ntalk,
comsat, and
finger daemons can be run in special
user sandboxes. A sandbox isn't perfect unless
you go to a large amount of trouble, but the onion approach to
security still stands: If someone is able to break in through
a server running in a sandbox, they still have to break out of the
sandbox. The more layers the attacker must break through, the
lower the likelihood of his success. Root holes have historically
been found in virtually every server ever run as root, including
basic system servers. If you are running a machine through which
people only login via sshd and never
login via telnetd or
rshd or
rlogind, then turn off those
services!
FreeBSD now defaults to running
ntalkd,
comsat, and
finger in a sandbox. Another program
which may be a candidate for running in a sandbox is named(8).
The default rc.conf includes the arguments
necessary to run namedin a sandbox in a
commented-out form. Depending on whether you are installing a new
system or upgrading an existing system, the special user accounts
used by these sandboxes may not be installed. The prudent
sysadmin would research and implement sandboxes for servers
whenever possible.
There are a number of other servers that typically do not run
in sandboxes: sendmail,
popper,
imapd, ftpd,
and others. There are alternatives to some of these, but
installing them may require more work then you are willing to
perform (the convenience factor strikes again). You may have to
run these servers as root and rely on other mechanisms to detect
break-ins that might occur through them.
The other big potential root hole in a system are the
suid-root and sgid binaries installed on the system. Most of
these binaries, such as rlogin, reside
in /bin, /sbin,
/usr/bin, or /usr/sbin.
While nothing is 100% safe, the system-default suid and sgid
binaries can be considered reasonably safe. Still, root holes are
occasionally found in these binaries. A root hole was found in
Xlib in 1998 that made
xterm (which is typically suid)
vulnerable. It is better to be safe then sorry and the prudent
sysadmin will restrict suid binaries that only staff should run to
a special group that only staff can access, and get rid of
(chmod 000) any suid binaries that nobody uses.
A server with no display generally does not need an
xterm binary. Sgid binaries can be
almost as dangerous. If an intruder can break an sgid-kmem binary
the intruder might be able to read /dev/kmem
and thus read the crypted password file, potentially compromising
any passworded account. Alternatively an intruder who breaks
group kmem can monitor keystrokes sent through
pty's, including pty's used by users who login through secure
methods. An intruder that breaks the tty group can write to
almost any user's tty. If a user is running a terminal program or
emulator with a keyboard-simulation feature, the intruder can
potentially generate a data stream that causes the user's terminal
to echo a command, which is then run as that user.
User accounts are usually the most difficult to secure. While
you can impose Draconian access restrictions on your staff and
* out their passwords, you may not be able to
do so with any general user accounts you might have. If you do
have sufficient control then you may win out and be able to secure
the user accounts properly. If not, you simply have to be more
vigilant in your monitoring of those accounts. Use of
ssh and kerberos for user accounts is
more problematic due to the extra administration and technical
support required, but still a very good solution compared to a
crypted password file.
The only sure fire way is to * out as many
passwords as you can and use ssh or
kerberos for access to those accounts. Even though the crypted
password file (/etc/spwd.db) can only be read
by root, it may be possible for an intruder to obtain read access
to that file even if the attacker cannot obtain root-write
access.
Your security scripts should always check for and report
changes to the password file (see Checking file integrity
below).
If an attacker breaks root he can do just about anything, but
there are certain conveniences. For example, most modern kernels
have a packet sniffing device driver built in. Under FreeBSD it
is called the bpf device. An intruder
will commonly attempt to run a packet sniffer on a compromised
machine. You do not need to give the intruder the capability and
most systems should not have the bpf device compiled in.
But even if you turn off the bpf device, you still have
/dev/mem and /dev/kmem
to worry about. For that matter, the intruder can still write to
raw disk devices. Also, there is another kernel feature called
the module loader, kldload(8). An enterprising intruder can
use a KLD module to install his own bpf device or other sniffing
device on a running kernel. To avoid these problems you have to
run the kernel at a higher secure level, at least securelevel 1.
The securelevel can be set with a sysctl on
the kern.securelevel variable. Once you have
set the securelevel to 1, write access to raw devices will be
denied and special chflags flags, such as schg,
will be enforced. You must also ensure that the
schg flag is set on critical startup binaries,
directories, and script files - everything that gets run up
to the point where the securelevel is set. This might be overdoing
it, and upgrading the system is much more difficult when you
operate at a higher secure level. You may compromise and run the
system at a higher secure level but not set the
schg flag for every system file and directory
under the sun. Another possibility is to simply mount
/ and /usr read-only.
It should be noted that being too draconian in what you attempt to
protect may prevent the all-important detection of an
intrusion.
When it comes right down to it, you can only protect your core
system configuration and control files so much before the
convenience factor rears its ugly head. For example, using
chflags to set the schg bit
on most of the files in / and
/usr is probably counterproductive because
while it may protect the files, it also closes a detection window.
The last layer of your security onion is perhaps the most
important - detection. The rest of your security is pretty
much useless (or, worse, presents you with a false sense of
safety) if you cannot detect potential incursions. Half the job
of the onion is to slow down the attacker rather then stop him in
order to give the detection side of the equation a chance to catch
him in the act.
The best way to detect an incursion is to look for modified,
missing, or unexpected files. The best way to look for modified
files is from another (often centralized) limited-access system.
Writing your security scripts on the extra-secure limited-access
system makes them mostly invisible to potential hackers, and this
is important. In order to take maximum advantage you generally
have to give the limited-access box significant access to the
other machines in the business, usually either by doing a
read-only NFS export of the other machines to the limited-access
box, or by setting up ssh keypairs to
allow the limit-access box to ssh to
the other machines. Except for its network traffic, NFS is the
least visible method - allowing you to monitor the
filesystems on each client box virtually undetected. If your
limited-access server is connected to the client boxes through a
switch, the NFS method is often the better choice. If your
limited-access server is connected to the client boxes through a
hub or through several layers of routing, the NFS method may be
too insecure (network-wise) and using
ssh may be the better choice even with
the audit-trail tracks that ssh
lays.
Once you give a limit-access box at least read access to the
client systems it is supposed to monitor, you must write scripts
to do the actual monitoring. Given an NFS mount, you can write
scripts out of simple system utilities such as find(1) and
md5(1). It is best to physically md5 the client-box files
boxes at least once a day, and to test control files such as those
found in /etc and
/usr/local/etc even more often. When
mismatches are found relative to the base md5 information the
limited-access machine knows is valid, it should scream at a
sysadmin to go check it out. A good security script will also
check for inappropriate suid binaries and for new or deleted files
on system partitions such as / and
/usr.
When using ssh rather then NFS,
writing the security script is much more difficult. You
essentially have to scp the scripts to the client box in order to
run them, making them visible, and for safety you also need to
scp the binaries (such as find) that those
scripts use. The ssh daemon on the
client box may already be compromised. All in all, using
ssh may be necessary when running over
unsecure links, but it's also a lot harder to deal with.
A good security script will also check for changes to user and
staff members access configuration files:
.rhosts, .shosts,
.ssh/authorized_keys and so forth...
files that might fall outside the purview of the
MD5 check.
If you have a huge amount of user disk space it may take too
long to run through every file on those partitions. In this case,
setting mount flags to disallow suid binaries and devices on those
partitions is a good idea. The nodev and
nosuid options (see mount(8)) are what you
want to look into. I would scan them anyway at least once a week,
since the object of this layer is to detect a break-in whether or
not the break-in is effective.
Process accounting (see accton(8)) is a relatively
low-overhead feature of the operating system which I recommend
using as a post-break-in evaluation mechanism. It is especially
useful in tracking down how an intruder has actually broken into
a system, assuming the file is still intact after the break-in
occurs.
Finally, security scripts should process the log files and the
logs themselves should be generated in as secure a manner as
possible - remote syslog can be very useful. An intruder
tries to cover his tracks, and log files are critical to the
sysadmin trying to track down the time and method of the initial
break-in. One way to keep a permanent record of the log files is
to run the system console to a serial port and collect the
information on a continuing basis through a secure machine
monitoring the consoles.
A little paranoia never hurts. As a rule, a sysadmin can add
any number of security features as long as they do not effect
convenience, and can add security features that do effect
convenience with some added thought. Even more importantly, a
security administrator should mix it up a bit - if you use
recommendations such as those given by this document verbatim, you
give away your methodologies to the prospective hacker who also
has access to this document.
This section covers Denial of Service attacks. A DOS attack
is typically a packet attack. While there is not much you can do
about modern spoofed packet attacks that saturate your network,
you can generally limit the damage by ensuring that the attacks
cannot take down your servers.
Limiting server forks.
Limiting springboard attacks (ICMP response attacks, ping
broadcast, etc.).
Kernel Route Cache.
A common DOS attack is against a forking server that attempts
to cause the server to eat processes, file descriptors, and memory
until the machine dies. Inetd (see inetd(8)) has several
options to limit this sort of attack. It should be noted that
while it is possible to prevent a machine from going down it is
not generally possible to prevent a service from being disrupted
by the attack. Read the inetd manual page carefully and pay
specific attention to the -c, -C,
and -R options. Note that spoofed-IP attacks
will circumvent the -C option to inetd, so
typically a combination of options must be used. Some standalone
servers have self-fork-limitation parameters.
Sendmail has its
-OMaxDaemonChildren option which tends to work
much better than trying to use sendmail's load limiting options
due to the load lag. You should specify a
MaxDaemonChildren parameter when you start
sendmail high enough to handle your
expected load but no so high that the computer cannot handle that
number of sendmails without falling on
its face. It is also prudent to run sendmail in queued mode
(-ODeliveryMode=queued) and to run the daemon
(sendmail -bd) separate from the queue-runs
(sendmail -q15m). If you still want realtime
delivery you can run the queue at a much lower interval, such as
-q1m, but be sure to specify a reasonable
MaxDaemonChildren option for that sendmail to
prevent cascade failures.
Syslogd can be attacked directly
and it is strongly recommended that you use the -s
option whenever possible, and the -a option
otherwise.
You should also be fairly careful with connect-back services
such as tcpwrapper's reverse-identd,
which can be attacked directly. You generally do not want to use
the reverse-ident feature of
tcpwrappers for this reason.
It is a very good idea to protect internal services from
external access by firewalling them off at your border routers.
The idea here is to prevent saturation attacks from outside your
LAN, not so much to protect internal services from network-based
root compromise. Always configure an exclusive firewall, i.e.,
"firewall everything except ports A, B,
C, D, and M-Z". This way you can firewall off all of your
low ports except for certain specific services such as
named (if you are primary for a zone),
ntalkd,
sendmail, and other internet-accessible
services. If you try to configure the firewall the other way
- as an inclusive or permissive firewall, there is a good
chance that you will forget to "close" a couple of
services or that you will add a new internal service and forget
to update the firewall. You can still open up the high-numbered
port range on the firewall to allow permissive-like operation
without compromising your low ports. Also take note that FreeBSD
allows you to control the range of port numbers used for dynamic
binding via the various net.inet.ip.portrange
sysctl's (sysctl -a | fgrep
portrange), which can also ease the complexity of your
firewall's configuration. I usually use a normal first/last range
of 4000 to 5000, and a hiport range of 49152 to 65535, then block
everything under 4000 off in my firewall (except for certain
specific internet-accessible ports, of course).
Another common DOS attack is called a springboard attack
- to attack a server in a manner that causes the server to
generate responses which then overload the server, the local
network, or some other machine. The most common attack of this
nature is the ICMP ping broadcast attack.
The attacker spoofs ping packets sent to your LAN's broadcast
address with the source IP address set to the actual machine they
wish to attack. If your border routers are not configured to
stomp on ping's to broadcast addresses, your LAN winds up
generating sufficient responses to the spoofed source address to
saturate the victim, especially when the attacker uses the same
trick on several dozen broadcast addresses over several dozen
different networks at once. Broadcast attacks of over a hundred
and twenty megabits have been measured. A second common
springboard attack is against the ICMP error reporting system.
By constructing packets that generate ICMP error responses, an
attacker can saturate a server's incoming network and cause the
server to saturate its outgoing network with ICMP responses. This
type of attack can also crash the server by running it out of
mbuf's, especially if the server cannot drain the ICMP responses
it generates fast enough. The FreeBSD kernel has a new kernel
compile option called ICMP_BANDLIM which limits the effectiveness
of these sorts of attacks. The last major class of springboard
attacks is related to certain internal inetd services such as the
udp echo service. An attacker simply spoofs a UDP packet with the
source address being server A's echo port, and the destination
address being server B's echo port, where server A and B are both
on your LAN. The two servers then bounce this one packet back and
forth between each other. The attacker can overload both servers
and their LANs simply by injecting a few packets in this manner.
Similar problems exist with the internal chargen port. A
competent sysadmin will turn off all of these inetd-internal test
services.
Spoofed packet attacks may also be used to overload the kernel
route cache. Refer to the net.inet.ip.rtexpire,
rtminexpire, and rtmaxcache
sysctl parameters. A spoofed packet attack
that uses a random source IP will cause the kernel to generate a
temporary cached route in the route table, viewable with
netstat -rna | fgrep W3. These routes
typically timeout in 1600 seconds or so. If the kernel detects
that the cached route table has gotten too big it will dynamically
reduce the rtexpire but will never decrease it to less then
rtminexpire. There are two problems:
The kernel does not react quickly enough when a lightly
loaded server is suddenly attacked.
The rtminexpire is not low enough for
the kernel to survive a sustained attack.
If your servers are connected to the internet via a T3 or
better it may be prudent to manually override both
rtexpire and rtminexpire
via sysctl(8). Never set either parameter to zero (unless
you want to crash the machine :-). Setting both
parameters to 2 seconds should be sufficient to protect the route
table from attack.
There are a few issues with both kerberos and
ssh that need to be addressed if you
intend to use them. Kerberos V is an excellent authentication
protocol but the kerberized telnet and
rlogin suck rocks. There are bugs that
make them unsuitable for dealing with binary streams. Also, by
default kerberos does not encrypt a session unless you use the
-x option. ssh
encrypts everything by default.
ssh works quite well in every
respect except that it forwards encryption keys by default. What
this means is that if you have a secure workstation holding keys
that give you access to the rest of the system, and you
ssh to an unsecure machine, your keys
becomes exposed. The actual keys themselves are not exposed, but
ssh installs a forwarding port for the
duration of your login and if a hacker has broken root on the
unsecure machine he can utilize that port to use your keys to gain
access to any other machine that your keys unlock.
We recommend that you use ssh in
combination with kerberos whenever possible for staff logins.
ssh can be compiled with kerberos
support. This reduces your reliance on potentially exposable
ssh keys while at the same time
protecting passwords via kerberos. ssh
keys should only be used for automated tasks from secure machines
(something that kerberos is unsuited to). We also recommend that
you either turn off key-forwarding in the
ssh configuration, or that you make use
of the from=IP/DOMAIN option that
ssh allows in its
authorized_keys file to make the key only
useable to entities logging in from specific machines.
