diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml
index f13ba66626..026acfe72a 100644
--- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml
@@ -1,3478 +1,3478 @@
MatthewDillonMuch of this chapter has been taken from the
security(7) manual page by SecuritysecuritySynopsisThis chapter will provide a basic introduction to system security
concepts, some general good rules of thumb, and some advanced topics
under FreeBSD. A lot of the topics covered here can be applied
to system and Internet security in general as well. The Internet
is no longer a friendly place in which everyone
wants to be your kind neighbor. Securing your system is imperative
to protect your data, intellectual property, time, and much more
from the hands of hackers and the like.FreeBSD provides an array of utilities and mechanisms to
ensure the integrity and security of your system and
network.After reading this chapter, you will know:Basic system security concepts, in respect to FreeBSD.About the various crypt mechanisms available in FreeBSD,
such as DES and MD5.How to setup S/Key, an alternative, one-time password
authentication system.How to setup Kerberos, another alternative
authentication system.How to create firewalls using IPFW.How to configure IPsec.How to configure and use OpenSSH, FreeBSD's SSH
implementation.Before reading this chapter, you should:Understand basic FreeBSD and Internet concepts.IntroductionSecurity is a function that begins and ends with the system
administrator. While all BSD Unix multi-user systems have some
inherent security, the job of building and maintaining additional
security mechanisms to keep those users honest is
probably one of the single largest undertakings of the sysadmin.
Machines are only as secure as you make them, and security concerns
are ever competing with the human necessity for convenience. Unix
systems, in general, are capable of running a huge number of
simultaneous processes and many of these processes operate as
servers – meaning that external entities can connect and talk
to them. As yesterday's mini-computers and mainframes become
today's desktops, and as computers become networked and
internetworked, security becomes an even bigger issue.Security is best implemented through a layered
onion approach. In a nutshell, what you want to do is
to create as many layers of security as are convenient and then
carefully monitor the system for intrusions. You do not want to
overbuild your security or you will interfere with the detection
side, and detection is one of the single most important aspects of
any security mechanism. For example, it makes little sense to set
the schg flags (see &man.chflags.1;) on every
system binary because
while this may temporarily protect the binaries, it prevents an
attacker who has broken in from making an easily detectable change
that may result in your security mechanisms not detecting the attacker
at all.System security also pertains to dealing with various forms of
attack, including attacks that attempt to crash, or otherwise make a
system unusable, but do not attempt to compromise the
root account (break root).
Security concerns
can be split up into several categories:Denial of service attacks.User account compromises.Root compromise through accessible servers.Root compromise via user accounts.Backdoor creation.DoS attacksDenial of Service (DoS)securityDoS attacksDenial of Service (DoS)Denial of Service (DoS)A denial of service attack is an action that deprives the
machine of needed resources. Typically, DoS attacks are
brute-force mechanisms that attempt to crash or otherwise make a
machine unusable by overwhelming its servers or network stack. Some
DoS attacks try to take advantage of bugs in the networking
stack to crash a machine with a single packet. The latter can only
be fixed by applying a bug fix to the kernel. Attacks on servers
can often be fixed by properly specifying options to limit the load
the servers incur on the system under adverse conditions.
Brute-force network attacks are harder to deal with. A
spoofed-packet attack, for example, is nearly impossible to stop,
short of cutting your system off from the Internet. It may not be
able to take your machine down, but it can saturate your
Internet connection.securityaccount compromisesA user account compromise is even more common than a DoS
attack. Many sysadmins still run standard
telnetd, rlogind,
rshd,
and ftpd servers on their machines.
These servers, by default, do
not operate over encrypted connections. The result is that if you
have any moderate-sized user base, one or more of your users logging
into your system from a remote location (which is the most common
and convenient way to login to a system) will have his or her
password sniffed. The attentive system admin will analyze his
remote access logs looking for suspicious source addresses even for
successful logins.One must always assume that once an attacker has access to a
user account, the attacker can break root.
However, the reality is that in a well secured and maintained system,
access to a user account does not necessarily give the attacker
access to root. The distinction is important
because without access to root the attacker
cannot generally hide his tracks and may, at best, be able to do
nothing more than mess with the user's files, or crash the machine.
User account compromises are very common because users tend not to
take the precautions that sysadmins take.securitybackdoorsSystem administrators must keep in mind that there are
potentially many ways to break root on a machine.
The attacker may know the root password,
the attacker may find a bug in a root-run server and be able
to break root over a network
connection to that server, or the attacker may know of a bug in
a suid-root program that allows the attacker to break
root once he has broken into a user's account.
If an attacker has found a way to break root
on a machine, the attacker may not have a need
to install a backdoor. Many of the root holes
found and closed to date involve a considerable amount of work
by the attacker to cleanup after himself, so most attackers install
backdoors. A backdoor provides the attacker with a way to easily
regain root access to the system, but it
also gives the smart system administrator a convenient way
to detect the intrusion.
Making it impossible for an attacker to install a backdoor may
actually be detrimental to your security, because it will not
close off the hole the attacker found to break in the first
place.Security remedies should always be implemented with a
multi-layered onion peel approach and can be
categorized as follows:Securing root and staff accounts.Securing root – root-run servers
and suid/sgid binaries.Securing user accounts.Securing the password file.Securing the kernel core, raw devices, and
filesystems.Quick detection of inappropriate changes made to the
system.Paranoia.The next section of this chapter will cover the above bullet
items in greater depth.securitysecuringSecuring FreeBSDCommand vs. ProtocolThroughout this document, we will use
bold text to refer to a command or
application. This is used for instances such as ssh, since it is
a protocol as well as command.The sections that follow will cover the methods of securing your
FreeBSD system that were mentioned in the last section of this chapter.Securing the root Account and
Staff AccountssuFirst off, do not bother securing staff accounts if you have
not secured the root account.
Most systems have a password assigned to the root
account. The first thing you do is assume
that the password is always compromised.
This does not mean that you should remove the password. The
password is almost always necessary for console access to the
machine. What it does mean is that you should not make it
possible to use the password outside of the console or possibly
even with the &man.su.1; command. For example, make sure that
your pty's are specified as being insecure in the
/etc/ttys file so that direct
root logins
via telnet or rlogin are
disallowed. If using other login services such as
sshd, make sure that direct
root logins are disabled there as well.
You can do this by editing
your /etc/ssh/sshd_config file, and making
sure that PermitRootLogin is set to
NO. Consider every access method –
services such as FTP often fall through the cracks.
Direct root logins should only be allowed
via the system console.wheelOf course, as a sysadmin you have to be able to get to
root, so we open up a few holes.
But we make sure these holes require additional password
verification to operate. One way to make root
accessible is to add appropriate staff accounts to the
wheel group (in
/etc/group). The staff members placed in the
wheel group are allowed to
su to root.
You should never give staff
members native wheel access by putting them in the
wheel group in their password entry. Staff
accounts should be placed in a staff group, and
then added to the wheel group via the
/etc/group file. Only those staff members
who actually need to have root access
should be placed in the
wheel group. It is also possible, when using
an authentication method such as Kerberos, to use Kerberos'
.k5login file in the root
account to allow a &man.ksu.1; to root
without having to place anyone at all in the
wheel group. This may be the better solution
since the wheel mechanism still allows an
intruder to break root if the intruder
has gotten hold of your
password file and can break into a staff account. While having
the wheel mechanism is better than having
nothing at all, it is not necessarily the safest option.An indirect way to secure staff accounts, and ultimately
root access is to use an alternative
login access method and
do what is known as starring out the encrypted
password for the staff accounts. Using the &man.vipw.8;
command, one can replace each instance of an encrypted password
with a single * character.
This command will update the /etc/master.passwd
file and user/password database to disable password-authenticated
logins.A staff account entry such as:foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcshShould be changed to this:foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcshThis change will prevent normal logins from occurring,
since the encrypted password will never match
*. With this done,
staff members must use
another mechanism to authenticate themselves such as
&man.kerberos.1; or &man.ssh.1; using a public/private key
pair. When using something like Kerberos, one generally must
secure the machines which run the Kerberos servers and your
desktop workstation. When using a public/private key pair
with ssh, one must generally secure
the machine used to login from (typically
one's workstation). An additional layer of protection can be
added to the key pair by password protecting the key pair when
creating it with &man.ssh-keygen.1;. Being able to
star out the passwords for staff accounts also
guarantees that staff members can only login through secure
access methods that you have setup. This forces all staff
members to use secure, encrypted connections for all of their
sessions, which closes an important hole used by many
intruders: sniffing the network from an unrelated,
less secure machine.The more indirect security mechanisms also assume that you are
logging in from a more restrictive server to a less restrictive
server. For example, if your main box is running all sorts of
servers, your workstation should not be running any. In order for
your workstation to be reasonably secure you should run as few
servers as possible, up to and including no servers at all, and
you should run a password-protected screen blanker. Of course,
given physical access to a workstation an attacker can break any
sort of security you put on it. This is definitely a problem that
you should consider, but you should also consider the fact that the
vast majority of break-ins occur remotely, over a network, from
people who do not have physical access to your workstation or
servers.KerberosUsing something like Kerberos also gives you the ability to
disable or change the password for a staff account in one place,
and have it immediately effect all the machines on which the staff
member may have an account. If a staff member's account gets
compromised, the ability to instantly change his password on all
machines should not be underrated. With discrete passwords,
changing a password on N machines can be a mess. You can also
impose re-passwording restrictions with Kerberos: not only can a
Kerberos ticket be made to timeout after a while, but the Kerberos
system can require that the user choose a new password after a
certain period of time (say, once a month).Securing Root-run Servers and SUID/SGID BinariesntalkcomsatfingersandboxessshdtelnetdrshdrlogindThe 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 is not perfect,
unless you go through 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 &man.named.8;.
/etc/defaults/rc.conf includes the arguments
necessary to run named in 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.sendmailThere 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 than 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 holes 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 than 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 encrypted 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.Securing User AccountsUser accounts are usually the most difficult to secure. While
you can impose Draconian access restrictions on your staff and
star 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.Securing the Password FileThe 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 encrypted
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 the Checking file integrity section
below).Securing the Kernel Core, Raw Devices, and
FilesystemsIf 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 do not have the need for the
bpf device compiled in.sysctlBut 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, &man.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.Checking File Integrity: Binaries, Configuration Files,
Etc.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 than 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 attackers, 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 key-pairs to
allow the limited-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 limited-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 &man.find.1; and
&man.md5.1;. It is best to physically md5 the client-box files
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 than 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 client on the
client box may already be compromised. All in all, using
ssh may be necessary when running over
insecure links, but it is 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 &man.mount.8;) are what you
want to look into. You should probably 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 &man.accton.8;) is a relatively
low-overhead feature of the operating system which might help
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.ParanoiaA 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 attacker who also has access to this document.Denial of Service AttacksDenial of Service (DoS)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 &man.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 , ,
and options. Note that spoofed-IP attacks
will circumvent the option to
inetd, so
typically a combination of options must be used. Some standalone
servers have self-fork-limitation parameters.Sendmail has its
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 not 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
() and to run the daemon
(sendmail -bd) separate from the queue-runs
(sendmail -q15m). If you still want real-time
delivery you can run the queue at a much lower interval, such as
, 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
option whenever possible, and the 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.portrangesysctl's (sysctl -a | fgrep
portrange), which can also ease the complexity of your
firewall's configuration. For example, you might use a normal
first/last range of 4000 to 5000, and a hiport range of 49152 to
65535, then block off everything under 4000 in your firewall
(except for certain specific Internet-accessible ports, of
course).ICMP_BANDLIMAnother common DoS attack is called a springboard attack
– to attack a server in a manner that causes the server to
generate responses which overloads 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
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 rtmaxcachesysctl 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 than 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 &man.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.Access Issues with Kerberos and SSHsshKerberosThere 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 there are bugs in the kerberized
telnet and
rlogin applications that make them
unsuitable for dealing with binary streams. Also, by default
Kerberos does not encrypt a session unless you use the
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 insecure machine, your keys
are usable. The actual keys themselves are not exposed, but
ssh installs a forwarding port for the
duration of your login, and if an attacker has broken
root on the
insecure 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 do). 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
usable to entities logging in from specific machines.BillSwingleParts rewritten and updated by DES, MD5, and CryptsecuritycryptcryptDESMD5Every user on a Unix system has a password associated with
their account. It seems obvious that these passwords need to be
known only to the user and the actual operating system. In
order to keep these passwords secret, they are encrypted with
what is known as a one-way hash, that is, they can
only be easily encrypted but not decrypted. In other words, what
we told you a moment ago was obvious is not even true: the
operating system itself does not really know
the password. It only knows the encrypted
form of the password. The only way to get the
plain-text password is by a brute force search of the
space of possible passwords.Unfortunately the only secure way to encrypt passwords when
Unix came into being was based on DES, the Data Encryption
Standard. This was not such a problem for users resident in
the US, but since the source code for DES could not be exported
outside the US, FreeBSD had to find a way to both comply with
US law and retain compatibility with all the other Unix
variants that still used DES.The solution was to divide up the encryption libraries
so that US users could install the DES libraries and use
DES but international users still had an encryption method
that could be exported abroad. This is how FreeBSD came to
use MD5 as its default encryption method. MD5 is believed to
be more secure than DES, so installing DES is offered primarily
for compatibility reasons.Recognizing Your Crypt Mechanism
- Before FreeBSD 4.4 libcrypt.a was a
+ Before FreeBSD 4.4 libcrypt.a was a
symbolic link pointing to the library which was used for
- encryption. FreeBSD 4.4 changed libcrypt.a to
+ encryption. FreeBSD 4.4 changed libcrypt.a to
provide a configurable password authentication hash library.
Currently the library supports DES, MD5 and Blowfish hash
functions. By default FreeBSD uses MD5 to encrypt
passwords.It is pretty easy to identify which encryption method
FreeBSD is set up to use. Examining the encrypted passwords in
the /etc/master.passwd file is one way.
Passwords encrypted with the MD5 hash are longer than those
encrypted with the DES hash and also begin with the characters
$1$. Passwords starting with
$2$ are encrypted with the
Blowfish hash function. DES password strings do not
have any particular identifying characteristics, but they are
shorter than MD5 passwords, and are coded in a 64-character
alphabet which does not include the $
character, so a relatively short string which does not begin with
a dollar sign is very likely a DES password.The password format used for new passwords is controlled
by the passwd_format login capability in
/etc/login.conf, which takes values of
des or md5 or
blf. See the &man.login.conf.5; manual page
for more information about login capabilities.S/KeyS/KeysecurityS/KeyS/Key is a one-time password scheme based on a one-way hash
function. FreeBSD uses the MD4 hash for compatibility but other
systems have used MD5 and DES-MAC. S/Key has been part of the
FreeBSD base system since version 1.1.5 and is also used on a
growing number of other operating systems. S/Key is a registered
trademark of Bell Communications Research, Inc.From version 5.0 of FreeBSD, S/Key has been replaced with
the functionally equivalent OPIE (Onetime Passwords In
Everything). OPIE uses the MD5 hash by default.There are three different sorts of passwords which we will talk
about in the discussion below. The first is your usual Unix-style or
Kerberos password; we will call this a Unix password.
The second sort is the one-time password which is generated by the
S/Key key program or the OPIE
opiekey program and accepted by the
keyinit or opiepasswd programs
and the login prompt; we will
call this a one-time password. The final sort of
password is the secret password which you give to the
key/opiekey programs (and
sometimes the
keyinit/opiepasswd programs)
which it uses to generate
one-time passwords; we will call it a secret password
or just unqualified password.The secret password does not have anything to do with your Unix
password; they can be the same but this is not recommended. S/Key
and OPIE secret passwords are not limited to 8 characters like Unix
passwords, they can be as long as you like. Passwords of six or
seven word long phrases are fairly common. For the most part, the
S/Key or OPIE system operates completely independently of the Unix
password system.Besides the password, there are two other pieces of data that
are important to S/Key and OPIE. One is what is known as the
seed or key, consisting of two letters
and five digits. The other is what is called the iteration
count, a number between 1 and 100. S/Key creates the
one-time password by concatenating the seed and the secret password,
then applying the MD4/MD5 hash as many times as specified by the
iteration count and turning the result into six short English words.
These six English words are your one-time password. The
authentication system (primarily PAM) keeps
track of the last one-time password used, and the user is
authenticated if the hash of the user-provided password is equal to
the previous password. Because a one-way hash is used it is
impossible to generate future one-time passwords if a successfully
used password is captured; the iteration count is decremented after
each successful login to keep the user and the login program in
sync. When the iteration count gets down to 1, S/Key and OPIE must be
reinitialized.There are three programs involved in each system
which we will discuss below. The key and
opiekey programs accept an iteration
count, a seed, and a secret password, and generate a one-time
password or a consecutive list of one-time passwords. The
keyinit and opiepasswd
programs are used to initialize S/Key and OPIE respectively,
and to change passwords, iteration counts, or seeds; they
take either a secret passphrase, or an iteration count,
seed, and one-time password. The keyinfo
and opieinfo programs examine the
relevant credentials files (/etc/skeykeys or
/etc/opiekeys) and print out the invoking user's
current iteration count and seed.There are four different sorts of operations we will cover. The
first is using keyinit or
opiepasswd over a secure connection to set up
one-time-passwords for the first time, or to change your password
or seed. The second operation is using keyinit
or opiepasswd over an insecure connection, in
conjunction with key or opiekey
over a secure connection, to do the same. The third is using
key/opiekey to log in over
an insecure connection. The fourth is using key
or opiekey to generate a number of keys which
can be written down or printed out to carry with you when going to
some location without secure connections to anywhere.Secure Connection InitializationTo initialize S/Key for the first time, change your password,
or change your seed while logged in over a secure connection
(e.g., on the console of a machine or via ssh), use the
keyinit command without any parameters while
logged in as yourself:&prompt.user; keyinit
Adding unfurl:
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password:
Again secret password:
ID unfurl s/key is 99 to17757
DEFY CLUB PRO NASH LACE SOFTFor OPIE, opiepasswd is used instead:&prompt.user; opiepasswd -c
[grimreaper] ~ $ opiepasswd -f -c
Adding unfurl:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
ID unfurl OTP key is 499 to4268
MOS MALL GOAT ARM AVID COED
At the Enter new secret pass phrase: or
Enter secret password: prompts, you
should enter a password or phrase. Remember, this is not the
password that you will use to login with, this is used to generate
your one-time login keys. The ID line gives the
parameters of your particular instance; your login name, the
iteration count, and seed. When logging in the system
will remember these parameters and present them back to you so you
do not have to remember them. The last line gives the particular
one-time password which corresponds to those parameters and your
secret password; if you were to re-login immediately, this
one-time password is the one you would use.Insecure Connection InitializationTo initialize or change your secret password over an
insecure connection, you will need to already have a secure
connection to some place where you can run key
or opiekey; this might be in the form of a
desk accessory on a Macintosh, or a shell prompt on a machine you
trust. You will also need to make up an iteration count (100 is
probably a good value), and you may make up your own seed or use a
randomly-generated one. Over on the insecure connection (to the
machine you are initializing), use the keyinit
-s command:&prompt.user; keyinit -s
Updating unfurl:
Old key: to17758
Reminder you need the 6 English words from the key command.
Enter sequence count from 1 to 9999: 100
Enter new key [default to17759]:
s/key 100 to 17759
s/key access password:
s/key access password:CURE MIKE BANE HIM RACY GOREFor OPIE, you need to use opiepasswd:&prompt.user; opiepasswd
Updating unfurl:
You need the response from an OTP generator.
Old secret pass phrase:
otp-md5 498 to4268 ext
Response: GAME GAG WELT OUT DOWN CHAT
New secret pass phrase:
otp-md5 499 to4269
Response: LINE PAP MILK NELL BUOY TROY
ID mark OTP key is 499 gr4269
LINE PAP MILK NELL BUOY TROY
To accept the default seed (which the
keyinit program confusingly calls a
key), press Return.
Then before entering an
access password, move over to your secure connection or S/Key desk
accessory, and give it the same parameters:&prompt.user; key 100 to17759
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: <secret password>
CURE MIKE BANE HIM RACY GOREOr for OPIE:&prompt.user; opiekey 498 to4268
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT
Now switch back over to the insecure connection, and copy the
one-time password generated over to the relevant program.Generating a Single one-time PasswordOnce you have initialized S/Key or OPIE, when you login you will be
presented with a prompt like this:&prompt.user; telnet example.com
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.
FreeBSD/i386 (example.com) (ttypa)
login: <username>
s/key 97 fw13894
Password: Or for OPIE:&prompt.user; telnet example.com
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.
FreeBSD/i386 (example.com) (ttypa)
login: <username>
otp-md5 498 gr4269 ext
Password: As a side note, the S/Key and OPIE prompts have a useful feature
(not shown here): if you press Return
at the password prompt, the
prompter will turn echo on, so you can see what you are
typing. This can be extremely useful if you are attempting to
type in a password by hand, such as from a printout.MS-DOSWindowsMacOSAt this point you need to generate your one-time password to
answer this login prompt. This must be done on a trusted system
that you can run key or
opiekey on. (There are versions of these for DOS,
Windows and MacOS as well.) They need both the iteration count and
the seed as command line options. You can cut-and-paste these
right from the login prompt on the machine that you are logging
in to.On the trusted system:&prompt.user; key 97 fw13894
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
WELD LIP ACTS ENDS ME HAAGFor OPIE:&prompt.user; opiekey 498 to4268
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHATNow that you have your one-time password you can continue
logging in:login: <username>
s/key 97 fw13894
Password: <return to enable echo>
s/key 97 fw13894
Password [echo on]: WELD LIP ACTS ENDS ME HAAG
Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... Generating Multiple one-time PasswordsSometimes you have to go places where you do not have
access to a trusted machine or secure connection. In this case,
it is possible to use the key command to
generate a number of one-time passwords before hand to be printed
out and taken with you. For example:&prompt.user; key -n 5 30 zz99999
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: <secret password>
26: SODA RUDE LEA LIND BUDD SILT
27: JILT SPY DUTY GLOW COWL ROT
28: THEM OW COLA RUNT BONG SCOT
29: COT MASH BARR BRIM NAN FLAG
30: CAN KNEE CAST NAME FOLK BILKThe requests five keys in sequence, the
specifies what the last iteration number
should be. Note that these are printed out in
reverse order of eventual use. If you are
really paranoid, you might want to write the results down by hand;
otherwise you can cut-and-paste into lpr. Note
that each line shows both the iteration count and the one-time
password; you may still find it handy to scratch off passwords as
you use them.Restricting Use of Unix PasswordsRestrictions can be placed on the use of Unix passwords based
on the host name, user name, terminal port, or IP address of a
login session. These restrictions can be found in the
configuration file /etc/skey.access. The
&man.skey.access.5; manual page has more information on the complete
format of the file and also details some security cautions to be
aware of before depending on this file for security.If there is no /etc/skey.access file
(this is the FreeBSD default), then all users will be allowed to
use Unix passwords. If the file exists, however, then all users
will be required to use S/Key unless explicitly permitted to do
otherwise by configuration statements in the
skey.access file. In all cases, Unix
passwords are permitted on the console.Here is a sample configuration file which illustrates the
three most common sorts of configuration statements:permit internet 192.168.0.0 255.255.0.0
permit user fnord
permit port ttyd0The first line (permit internet) allows
users whose IP source address (which is vulnerable to spoofing)
matches the specified value and mask, to use Unix passwords. This
should not be considered a security mechanism, but rather, a means
to remind authorized users that they are using an insecure network
and need to use S/Key for authentication.The second line (permit user) allows the
specified username, in this case fnord, to use
Unix passwords at any time. Generally speaking, this should only
be used for people who are either unable to use the
key program, like those with dumb terminals, or
those who are uneducable.The third line (permit port) allows all
users logging in on the specified terminal line to use Unix
passwords; this would be used for dial-ups.MarkMurrayContributed by MarkDapozBased on a contribution by KerberosKerberosKerberos is a network add-on system/protocol that allows users to
authenticate themselves through the services of a secure server.
Services such as remote login, remote copy, secure inter-system file
copying and other high-risk tasks are made considerably safer and more
controllable.The following instructions can be used as a guide on how to set up
Kerberos as distributed for FreeBSD. However, you should refer to the
relevant manual pages for a complete description.Installing KerberosMITKerberosinstallingKerberos is an optional component of FreeBSD. The easiest
way to install this software is by selecting the 'krb4' or
'krb5' distribution in sysinstall
during the initial installation of FreeBSD. This will install
the 'eBones' (KerberosIV) or 'Heimdal' (Kerberos5)
implementation of Kerberos. These implementations are
included because they are developed outside the USA/Canada and
were thus available to system owners outside those countries
during the era of restrictive export controls on cryptographic
code from the USA.Alternatively, the MIT implementation of Kerberos is
available from the ports collection as
security/krb5.Creating the Initial DatabaseThis is done on the Kerberos server only. First make sure that
you do not have any old Kerberos databases around. You should change
to the directory /etc/kerberosIV and check that
only the following files are present:&prompt.root; cd /etc/kerberosIV
&prompt.root; ls
README krb.conf krb.realmsIf any additional files (such as principal.*
or master_key) exist, then use the
kdb_destroy command to destroy the old Kerberos
database, or if Kerberos is not running, simply delete the extra
files.You should now edit the krb.conf and
krb.realms files to define your Kerberos realm.
In this case the realm will be EXAMPLE.COM and the
server is grunt.example.com. We edit
or create the krb.conf file:&prompt.root; cat krb.conf
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.govIn this case, the other realms do not need to be there. They are
here as an example of how a machine may be made aware of multiple
realms. You may wish to not include them for simplicity.The first line names the realm in which this system works. The
other lines contain realm/host entries. The first item on a line is a
realm, and the second is a host in that realm that is acting as a
key distribution center. The words admin
server following a host's name means that host also
provides an administrative database server. For further explanation
of these terms, please consult the Kerberos manual pages.Now we have to add grunt.example.com
to the EXAMPLE.COM realm and also add an entry to
put all hosts in the .example.com
domain in the EXAMPLE.COM realm. The
krb.realms file would be updated as
follows:&prompt.root; cat krb.realms
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDUAgain, the other realms do not need to be there. They are here as
an example of how a machine may be made aware of multiple realms. You
may wish to remove them to simplify things.The first line puts the specific system into
the named realm. The rest of the lines show how to default systems of
a particular subdomain to a named realm.Now we are ready to create the database. This only needs to run
on the Kerberos server (or Key Distribution Center). Issue the
kdb_init command to do this:&prompt.root; kdb_initRealm name [default ATHENA.MIT.EDU ]:EXAMPLE.COM
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:Now we have to save the key so that servers on the local machine
can pick it up. Use the kstash command to do
this.&prompt.root; kstashEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!This saves the encrypted master password in
/etc/kerberosIV/master_key.Making It All RunTwo principals need to be added to the database for
each system that will be secured with Kerberos.
Their names are kpasswd and rcmd
These two principals are made for each system, with the instance being
the name of the individual system.These daemons, kpasswd and
rcmd allow other systems to change Kerberos
passwords and run commands like rcp,
rlogin and rsh.Now let us add these entries:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:passwdInstance:grunt
<Not found>, Create [y] ?y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name:rcmdInstance:grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitCreating the Server FileWe now have to extract all the instances which define the
services on each machine. For this we use the
ext_srvtab command. This will create a file
which must be copied or moved by secure
means to each Kerberos client's
/etc/kerberosIV directory. This file must
be present on each server and client, and is crucial to the
operation of Kerberos.&prompt.root; ext_srvtab gruntEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....Now, this command only generates a temporary file which must be
renamed to srvtab so that all the servers can pick
it up. Use the mv command to move it into place on
the original system:&prompt.root; mv grunt-new-srvtab srvtabIf the file is for a client system, and the network is not deemed
safe, then copy the
client-new-srvtab to
removable media and transport it by secure physical means. Be sure to
rename it to srvtab in the client's
/etc/kerberosIV directory, and make sure it is
mode 600:&prompt.root; mv grumble-new-srvtab srvtab
&prompt.root; chmod 600 srvtabPopulating the DatabaseWe now have to add some user entries into the database. First
let us create an entry for the user jane. Use the
kdb_edit command to do this:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:
<Not found>, Create [y] ?y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- enter a secure password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitTesting It All OutFirst we have to start the Kerberos daemons. NOTE that if you
have correctly edited your /etc/rc.conf then this
will happen automatically when you reboot. This is only necessary on
the Kerberos server. Kerberos clients will automagically get what
they need from the /etc/kerberosIV
directory.&prompt.root; kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: EXAMPLE.COM
&prompt.root; kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!Now we can try using the kinit command to get a
ticket for the id jane that we created
above:&prompt.user; kinit jane
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane"
Password:Try listing the tokens using klist to see if we
really have them:&prompt.user; klist
Ticket file: /tmp/tkt245
Principal: jane@EXAMPLE.COM
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COMNow try changing the password using passwd to
check if the kpasswd daemon can get
authorization to the Kerberos database:&prompt.user; passwd
realm EXAMPLE.COM
Old password for jane:New Password for jane:
Verifying password
New Password for jane:
Password changed.Adding su PrivilegesKerberos allows us to give each user
who needs root privileges their own
separatesu password.
We could now add an id which is authorized to
su to root. This is
controlled by having an instance of root
associated with a principal. Using kdb_edit
we can create the entry jane.root in the
Kerberos database:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- enter a SECURE password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitNow try getting tokens for it to make sure it works:&prompt.root; kinit jane.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
Password:Now we need to add the user to root's
.klogin file:&prompt.root; cat /root/.klogin
jane.root@EXAMPLE.COMNow try doing the su:&prompt.user; suPassword:and take a look at what tokens we have:&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@EXAMPLE.COM
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COMUsing Other CommandsIn an earlier example, we created a principal called
jane with an instance root.
This was based on a user with the same name as the principal, and this
is a Kerberos default; that a
<principal>.<instance> of the form
<username>.root will allow
that <username> to su to
root if the necessary entries are in the
.klogin file in root's
home directory:&prompt.root; cat /root/.klogin
jane.root@EXAMPLE.COMLikewise, if a user has in their own home directory lines of the
form:&prompt.user; cat ~/.klogin
jane@EXAMPLE.COM
jack@EXAMPLE.COMThis allows anyone in the EXAMPLE.COM realm
who has authenticated themselves to jane or
jack (via kinit, see above)
access to rlogin to jane's
account or files on this system (grunt) via
rlogin, rsh or
rcp.For example, jane now logs into another system using
Kerberos:&prompt.user; kinit
MIT Project Athena (grunt.example.com)
Password:
&prompt.user; rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995Or Jack logs into Jane's account on the same machine
(jane having
set up the .klogin file as above, and the person
in charge of Kerberos having set up principal
jack with a null instance:&prompt.user; kinit
&prompt.user; rlogin grunt -l jane
MIT Project Athena (grunt.example.com)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995GaryPalmerContributed by AlexNashFirewallsfirewallsecurityfirewallsFirewalls are an area of increasing interest for people who are
connected to the Internet, and are even finding applications on private
networks to provide enhanced security. This section will hopefully
explain what firewalls are, how to use them, and how to use the
facilities provided in the FreeBSD kernel to implement them.People often think that having a firewall between your
internal network and the Big Bad Internet will solve all
your security problems. It may help, but a poorly setup firewall
system is more of a security risk than not having one at all. A
firewall can add another layer of security to your systems, but it
cannot stop a really determined cracker from penetrating your internal
network. If you let internal security lapse because you believe your
firewall to be impenetrable, you have just made the crackers job that
much easier.What Is a Firewall?There are currently two distinct types of firewalls in common use
on the Internet today. The first type is more properly called a
packet filtering router, where the kernel on a
multi-homed machine chooses whether to forward or block packets based
on a set of rules. The second type, known as a proxy
server, relies on daemons to provide authentication and to
forward packets, possibly on a multi-homed machine which has kernel
packet forwarding disabled.Sometimes sites combine the two types of firewalls, so that only a
certain machine (known as a bastion host) is
allowed to send packets through a packet filtering router onto an
internal network. Proxy services are run on the bastion host, which
are generally more secure than normal authentication
mechanisms.FreeBSD comes with a kernel packet filter (known as
IPFW), which is what the rest of this
section will concentrate on. Proxy servers can be built on FreeBSD
from third party software, but there is such a variety of proxy
servers available that it would be impossible to cover them in this
section.Packet Filtering RoutersA router is a machine which forwards packets between two or more
networks. A packet filtering router has an extra piece of code in
its kernel which compares each packet to a list of rules before
deciding if it should be forwarded or not. Most modern IP routing
software has packet filtering code within it that defaults to
forwarding all packets. To enable the filters, you need to define a
set of rules for the filtering code so it can decide if the
packet should be allowed to pass or not.To decide whether a packet should be passed on, the code looks
through its set of rules for a rule which matches the contents of
this packets headers. Once a match is found, the rule action is
obeyed. The rule action could be to drop the packet, to forward the
packet, or even to send an ICMP message back to the originator.
Only the first match counts, as the rules are searched in order.
Hence, the list of rules can be referred to as a rule
chain.The packet matching criteria varies depending on the software
used, but typically you can specify rules which depend on the source
IP address of the packet, the destination IP address, the source
port number, the destination port number (for protocols which
support ports), or even the packet type (UDP, TCP, ICMP,
etc).Proxy ServersProxy servers are machines which have had the normal system
daemons (telnetd,
ftpd, etc) replaced with special servers.
These
servers are called proxy servers as they
normally only allow onward connections to be made. This enables you
to run (for example) a proxy telnet server on your firewall host,
and people can telnet in to your firewall from the outside, go
through some authentication mechanism, and then gain access to the
internal network (alternatively, proxy servers can be used for
signals coming from the internal network and heading out).Proxy servers are normally more secure than normal servers, and
often have a wider variety of authentication mechanisms available,
including one-shot password systems so that even if
someone manages to discover what password you used, they will not be
able to use it to gain access to your systems as the password
instantly expires. As they do not actually give users access to the
host machine, it becomes a lot more difficult for someone to install
backdoors around your security system.Proxy servers often have ways of restricting access further, so
that only certain hosts can gain access to the servers, and often
they can be set up so that you can limit which users can talk to
which destination machine. Again, what facilities are available
depends largely on what proxy software you choose.What Does IPFW Allow Me to Do?ipfwIPFW, the software supplied with
FreeBSD, is a packet filtering and accounting system which resides in
the kernel, and has a user-land control utility,
&man.ipfw.8;. Together, they allow you to define and query the
rules currently used by the kernel in its routing decisions.There are two related parts to IPFW.
The firewall section allows you to perform packet filtering. There is
also an IP accounting section which allows you to track usage of your
router, based on similar rules to the firewall section. This allows
you to see (for example) how much traffic your router is getting from
a certain machine, or how much WWW (World Wide Web) traffic it is
forwarding.As a result of the way that IPFW is
designed, you can use IPFW on non-router
machines to perform packet filtering on incoming and outgoing
connections. This is a special case of the more general use of
IPFW, and the same commands and techniques
should be used in this situation.Enabling IPFW on FreeBSDipfwenablingAs the main part of the IPFW system
lives in the kernel, you will need to add one or more options to your
kernel configuration file, depending on what facilities you want, and
recompile your kernel. See "Reconfiguring your Kernel" ()
for more details on how to recompile your
kernel.There are currently three kernel configuration options relevant to
IPFW:options IPFIREWALLCompiles into the kernel the code for packet
filtering.options IPFIREWALL_VERBOSEEnables code to allow logging of packets through
&man.syslogd.8;. Without this option, even if you specify
that packets should be logged in the filter rules, nothing will
happen.options IPFIREWALL_VERBOSE_LIMIT=10Limits the number of packets logged through
&man.syslogd.8; on a per entry basis. You may wish to use
this option in hostile environments in which you want to log
firewall activity, but do not want to be open to a denial of
service attack via syslog flooding.When a chain entry reaches the packet limit specified,
logging is turned off for that particular entry. To resume
logging, you will need to reset the associated counter using the
&man.ipfw.8; utility:&prompt.root; ipfw zero 4500Where 4500 is the chain entry you wish to continue
logging.Previous versions of FreeBSD contained an
IPFIREWALL_ACCT option. This is now obsolete as
the firewall code automatically includes accounting
facilities.Configuring IPFWipfwconfiguringThe configuration of the IPFW software
is done through the &man.ipfw.8; utility. The syntax for this
command looks quite complicated, but it is relatively simple once you
understand its structure.There are currently four different command categories used by the
utility: addition/deletion, listing, flushing, and clearing.
Addition/deletion is used to build the rules that control how packets
are accepted, rejected, and logged. Listing is used to examine the
contents of your rule set (otherwise known as the chain) and packet
counters (accounting). Flushing is used to remove all entries from
the chain. Clearing is used to zero out one or more accounting
entries.Altering the IPFW RulesThe syntax for this form of the command is:
ipfw-NcommandindexactionlogprotocoladdressesoptionsThere is one valid flag when using this form of the
command:-NResolve addresses and service names in output.The command given can be shortened to the
shortest unique form. The valid commands
are:addAdd an entry to the firewall/accounting rule listdeleteDelete an entry from the firewall/accounting rule
listPrevious versions of IPFW used
separate firewall and accounting entries. The present version
provides packet accounting with each firewall entry.If an index value is supplied, it is used to
place the entry at a specific point in the chain. Otherwise, the
entry is placed at the end of the chain at an index 100 greater than
the last chain entry (this does not include the default policy, rule
65535, deny).The log option causes matching rules to be
output to the system console if the kernel was compiled with
IPFIREWALL_VERBOSE.Valid actions are:rejectDrop the packet, and send an ICMP host or port unreachable
(as appropriate) packet to the source.allowPass the packet on as normal. (aliases:
pass and
accept)denyDrop the packet. The source is not notified via an
ICMP message (thus it appears that the packet never
arrived at the destination).countUpdate packet counters but do not allow/deny the packet
based on this rule. The search continues with the next chain
entry.Each action will be recognized by the
shortest unambiguous prefix.The protocols which can be specified
are:allMatches any IP packeticmpMatches ICMP packetstcpMatches TCP packetsudpMatches UDP packetsThe address specification is:fromaddress/maskporttoaddress/maskportvia interfaceYou can only specify port in
conjunction with protocols which support ports
(UDP and TCP).The is optional and may specify the IP
address or domain name of a local IP interface, or an interface name
(e.g. ed0) to match only packets coming
through this interface. Interface unit numbers can be specified
with an optional wildcard. For example, ppp*
would match all kernel PPP interfaces.The syntax used to specify an
address/mask is:
address
or
address/mask-bits
or
address:mask-patternA valid hostname may be specified in place of the IP address.
is a decimal
number representing how many bits in the address mask should be set.
e.g. specifying 192.216.222.1/24 will create a
mask which will allow any address in a class C subnet (in this case,
192.216.222) to be matched.
is an IP
address which will be logically AND'ed with the address given. The
keyword any may be used to specify any IP
address.The port numbers to be blocked are specified as:
port,port,port…
to specify either a single port or a list of ports, or
port-port
to specify a range of ports. You may also combine a single range
with a list, but the range must always be specified first.The options available are:fragMatches if the packet is not the first fragment of the
datagram.inMatches if the packet is on the way in.outMatches if the packet is on the way out.ipoptions specMatches if the IP header contains the comma separated list
of options specified in spec. The
supported list of IP options are: ssrr
(strict source route), lsrr (loose source
route), rr (record packet route), and
ts (time stamp). The absence of a
particular option may be denoted with a leading
!.establishedMatches if the packet is part of an already established
TCP connection (i.e. it has the RST or ACK bits set). You can
optimize the performance of the firewall by placing
established rules early in the
chain.setupMatches if the packet is an attempt to establish a TCP
connection (the SYN bit is set but the ACK bit is
not).tcpflags flagsMatches if the TCP header contains the comma separated
list of flags. The supported flags
are fin, syn,
rst, psh,
ack, and urg. The
absence of a particular flag may be indicated by a leading
!.icmptypes typesMatches if the ICMP type is present in the list
types. The list may be specified
as any combination of ranges and/or individual types separated
by commas. Commonly used ICMP types are: 0
echo reply (ping reply), 3 destination
unreachable, 5 redirect,
8 echo request (ping request), and
11 time exceeded (used to indicate TTL
expiration as with &man.traceroute.8;).Listing the IPFW RulesThe syntax for this form of the command is:
ipfw-a-t-NlThere are three valid flags when using this form of the
command:-aWhile listing, show counter values. This option is the
only way to see accounting counters.-tDisplay the last match times for each chain entry. The
time listing is incompatible with the input syntax used by the
&man.ipfw.8; utility.-NAttempt to resolve given addresses and service
names.Flushing the IPFW RulesThe syntax for flushing the chain is:
ipfwflushThis causes all entries in the firewall chain to be removed
except the fixed default policy enforced by the kernel (index
65535). Use caution when flushing rules, the default deny policy
will leave your system cut off from the network until allow entries
are added to the chain.Clearing the IPFW Packet CountersThe syntax for clearing one or more packet counters is:
ipfwzeroindexWhen used without an index argument,
all packet counters are cleared. If an
index is supplied, the clearing operation
only affects a specific chain entry.Example Commands for ipfwThis command will deny all packets from the host evil.crackers.org to the telnet port of the
host nice.people.org:&prompt.root; ipfw add deny tcp from evil.crackers.org to nice.people.org 23The next example denies and logs any TCP traffic from the entire
crackers.org network (a class C) to
the nice.people.org machine (any
port).&prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.orgIf you do not want people sending X sessions to your internal
network (a subnet of a class C), the following command will do the
necessary filtering:&prompt.root; ipfw add deny tcp from any to my.org/28 6000 setupTo see the accounting records:
&prompt.root; ipfw -a list
or in the short form
&prompt.root; ipfw -a lYou can also see the last time a chain entry was matched
with:&prompt.root; ipfw -at lBuilding a Packet Filtering FirewallThe following suggestions are just that: suggestions. The
requirements of each firewall are different and we cannot tell you
how to build a firewall to meet your particular requirements.When initially setting up your firewall, unless you have a test
bench setup where you can configure your firewall host in a controlled
environment, it is strongly recommend you use the logging version of the
commands and enable logging in the kernel. This will allow you to
quickly identify problem areas and cure them without too much
disruption. Even after the initial setup phase is complete, I
recommend using the logging for `deny' as it allows tracing of
possible attacks and also modification of the firewall rules if your
requirements alter.If you use the logging versions of the accept
command, it can generate large amounts of log
data as one log line will be generated for every packet that passes
through the firewall, so large FTP/http transfers, etc, will really
slow the system down. It also increases the latencies on those
packets as it requires more work to be done by the kernel before the
packet can be passed on. syslogd will
also start using up a lot
more processor time as it logs all the extra data to disk, and it
could quite easily fill the partition /var/log
is located on.You should enable your firewall from
/etc/rc.conf.local or
/etc/rc.conf. The associated manual page explains
which knobs to fiddle and lists some preset firewall configurations.
If you do not use a preset configuration, ipfw list
will output the current ruleset into a file that you can
pass to rc.conf. If you do not use
/etc/rc.conf.local or
/etc/rc.conf to enable your firewall,
it is important to make sure your firewall is enabled before
any IP interfaces are configured.The next problem is what your firewall should actually
do! This is largely dependent on what access to
your network you want to allow from the outside, and how much access
to the outside world you want to allow from the inside. Some general
rules are:Block all incoming access to ports below 1024 for TCP. This is
where most of the security sensitive services are, like finger,
SMTP (mail) and telnet.Block all incoming UDP traffic. There
are very few useful services that travel over UDP, and what useful
traffic there is, is normally a security threat (e.g. Suns RPC and
NFS protocols). This has its disadvantages also, since UDP is a
connectionless protocol, denying incoming UDP traffic also blocks
the replies to outgoing UDP traffic. This can cause a problem for
people (on the inside) using external archie (prospero) servers.
If you want to allow access to archie, you will have to allow
packets coming from ports 191 and 1525 to any internal UDP port
through the firewall. ntp is another
service you may consider allowing through, which comes from port
123.Block traffic to port 6000 from the outside. Port 6000 is the
port used for access to X11 servers, and can be a security threat
(especially if people are in the habit of doing xhost
+ on their workstations). X11 can actually use a
range of ports starting at 6000, the upper limit being how many X
displays you can run on the machine. The upper limit as defined
by RFC 1700 (Assigned Numbers) is 6063.Check what ports any internal servers use (e.g. SQL servers,
etc). It is probably a good idea to block those as well, as they
normally fall outside the 1-1024 range specified above.Another checklist for firewall configuration is available from
CERT at http://www.cert.org/tech_tips/packet_filtering.htmlAs stated above, these are only guidelines.
You will have to decide what filter rules you want to use on your
firewall yourself. We cannot accept ANY responsibility if someone
breaks into your network, even if you follow the advice given
above.IPFW Overhead and OptimizationMany people want to know how much overhead IPFW adds to a
system. The answer to this depends mostly on your rule set and
processor speed. For most applications dealing with Ethernet
and small rule sets, the answer is
negligible. For those of you that need actual
measurements to satisfy your curiosity, read on.The following measurements were made using 2.2.5-STABLE on
a 486-66. (While IPFW has changed slightly in later releases
of FreeBSD, it still performs with similar speed.) IPFW was
modified to measure the time spent within the
ip_fw_chk routine, displaying the results
to the console every 1000 packets.Two rule sets, each with 1000 rules were tested. The
first set was designed to demonstrate a worst case scenario by
repeating the rule:&prompt.root; ipfw add deny tcp from any to any 55555This demonstrates worst case by causing most of IPFW's
packet check routine to be executed before finally deciding
that the packet does not match the rule (by virtue of the port
number). Following the 999th iteration of this rule was an
allow ip from any to any.The second set of rules were designed to abort the rule
check quickly:&prompt.root; ipfw add deny ip from 1.2.3.4 to 1.2.3.4The non-matching source IP address for the above rule
causes these rules to be skipped very quickly. As before, the
1000th rule was an allow ip from any to
any.The per-packet processing overhead in the former case was
- approximately 2.703ms/packet, or roughly 2.7 microseconds per
+ approximately 2.703 ms/packet, or roughly 2.7 microseconds per
rule. Thus the theoretical packet processing limit with these
- rules is around 370 packets per second. Assuming 10Mbps
- Ethernet and a ~1500 byte packet size, we would only be able
+ rules is around 370 packets per second. Assuming 10 Mbps
+ Ethernet and a ~1500 byte packet size, we would only be able
to achieve a 55.5% bandwidth utilization.For the latter case each packet was processed in
- approximately 1.172ms, or roughly 1.2 microseconds per rule.
+ approximately 1.172 ms, or roughly 1.2 microseconds per rule.
The theoretical packet processing limit here would be about
- 853 packets per second, which could consume 10Mbps Ethernet
+ 853 packets per second, which could consume 10 Mbps Ethernet
bandwidth.The excessive number of rules tested and the nature of
those rules do not provide a real-world scenario -- they were
used only to generate the timing information presented here.
Here are a few things to keep in mind when building an
efficient rule set:Place an established rule early on
to handle the majority of TCP traffic. Do not put any
allow tcp statements before this
rule.Place heavily triggered rules earlier in the rule set
than those rarely used (without changing the
permissiveness of the firewall, of course).
You can see which rules are used most often by examining
the packet counting statistics with ipfw -a
l.OpenSSLsecurityOpenSSLOpenSSL
- As of FreeBSD 4.0, the OpenSSL toolkit is a part of the base
+ As of FreeBSD 4.0, the OpenSSL toolkit is a part of the base
system. OpenSSL
provides a general-purpose cryptography library, as well as the
Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer
Security v1 (TLSv1) network security protocols.However, one of the algorithms (specifically IDEA)
included in OpenSSL is protected by patents in the USA and
elsewhere, and is not available for unrestricted use.
IDEA is included in the OpenSSL sources in FreeBSD, but it is not
built by default. If you wish to use it, and you comply with the
license terms, enable the MAKE_IDEA switch in
/etc/make.conf and
rebuild your sources using make world.Today, the RSA algorithm is free for use in USA and other
countries. In the past it was protected by a patent.OpenSSLinstallSource Code InstallationsOpenSSL is part of the src-crypto and
src-secure cvsup collections. See the Obtaining FreeBSD section for more
information about obtaining and updating FreeBSD source
code.YoshinobuInoueContributed by IPsecIPsecsecurityIPsecTerminating CharactersThroughout examples in this section, and other sections,
you will notice that there is a ^D at the end
of some examples. This means to hold down the Control
key and hit the D key. Another commonly used
character is ^C, which respectively means to hold
down Control and press C.For other HOWTOs detailing IPsec implementation in
FreeBSD, take a look at
and .The IPsec mechanism provides secure communication for IP
layer and socket layer communication. This section should
explain how to use them. For implementation details, please
refer to The
Developers' Handbook.The current IPsec implementation supports both transport mode
and tunnel mode. However, tunnel mode comes with some restrictions.
http://www.kame.net/newsletter/
has more comprehensive examples.Please be aware that in order to use this functionality, you
must have the following options compiled into your kernel:options IPSEC #IP security
options IPSEC_ESP #IP security (crypto; define w/IPSEC)Transport Mode Example with IPv4Let us setup security association to deploy a secure channel
between HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little
complicated example. From HOST A to HOST B, only old AH is used.
From HOST B to HOST A, new AH and new ESP are combined.Now we should choose an algorithm to be used corresponding to
AH/new AH/ESP/
new ESP. Please refer to the &man.setkey.8; man
page to know algorithm names. Our choice is MD5 for AH, new-HMAC-SHA1
for new AH, and new-DES-expIV with 8 byte IV for new ESP.Key length highly depends on each algorithm. For example, key
length must be equal to 16 bytes for MD5, 20 for new-HMAC-SHA1,
and 8 for new-DES-expIV. Now we choose MYSECRETMYSECRET,
KAMEKAMEKAMEKAMEKAME, PASSWORD,
respectively.OK, let us assign SPI (Security Parameter Index) for each protocol.
Please note that we need 3 SPIs for this secure channel since three
security headers are produced (one for from HOST A to HOST B, two for
from HOST B to HOST A). Please also note that SPI MUST be greater
than or equal to 256. We choose, 1000, 2000, and 3000,
respectively.
(1)
HOST A ------> HOST B
(1)PROTO=AH
ALG=MD5(RFC1826)
KEY=MYSECRETMYSECRET
SPI=1000
(2.1)
HOST A <------ HOST B
<------
(2.2)
(2.1)
PROTO=AH
ALG=new-HMAC-SHA1(new AH)
KEY=KAMEKAMEKAMEKAMEKAME
SPI=2000
(2.2)
PROTO=ESP
ALG=new-DES-expIV(new ESP)
IV length = 8
KEY=PASSWORD
SPI=3000
Now, let us setup security association. Execute &man.setkey.8;
on both HOST A and B:&prompt.root; setkey -c
add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ;
add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ;
add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ;
^DActually, IPsec communication does not process until security policy
entries are defined. In this case, you must setup each host.
At A:
&prompt.root; setkey -c
spdadd 10.2.3.4 10.6.7.8 any -P out ipsec
ah/transport/10.2.3.4-10.6.7.8/require ;
^D
At B:
&prompt.root; setkey -c
spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
esp/transport/10.6.7.8-10.2.3.4/require ;
spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
ah/transport/10.6.7.8-10.2.3.4/require ;
^D
HOST A --------------------------------------> HOST E
10.2.3.4 10.6.7.8
| |
========== old AH keyed-md5 ==========>
<========= new AH hmac-sha1 ===========
<========= new ESP des-cbc ============
Transport Mode Example with IPv6Another example using IPv6.ESP transport mode is recommended for TCP port number 110 between
Host-A and Host-B.
============ ESP ============
| |
Host-A Host-B
fec0::10 -------------------- fec0::11
Encryption algorithm is blowfish-cbc whose key is
kamekame, and authentication algorithm is hmac-sha1
whose key is this is the test key.
Configuration at Host-A:&prompt.root; setkey -c <<EOF
spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec
esp/transport/fec0::10-fec0::11/use ;
spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec
esp/transport/fec0::11-fec0::10/use ;
add fec0::10 fec0::11 esp 0x10001
-m transport
-E blowfish-cbc "kamekame"
-A hmac-sha1 "this is the test key" ;
add fec0::11 fec0::10 esp 0x10002
-m transport
-E blowfish-cbc "kamekame"
-A hmac-sha1 "this is the test key" ;
EOFand at Host-B:&prompt.root; setkey -c <<EOF
spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec
esp/transport/fec0::11-fec0::10/use ;
spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec
esp/transport/fec0::10-fec0::11/use ;
add fec0::10 fec0::11 esp 0x10001 -m transport
-E blowfish-cbc "kamekame"
-A hmac-sha1 "this is the test key" ;
add fec0::11 fec0::10 esp 0x10002 -m transport
-E blowfish-cbc "kamekame"
-A hmac-sha1 "this is the test key" ;
EOFNote the direction of SP.Tunnel Mode Example with IPv4Tunnel mode between two security gatewaysSecurity protocol is old AH tunnel mode, i.e. specified by
RFC1826, with keyed-md5 whose key is this is the test as
authentication algorithm.
======= AH =======
| |
Network-A Gateway-A Gateway-B Network-B
10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24
Configuration at Gateway-A:&prompt.root; setkey -c <<EOF
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
ah/tunnel/172.16.0.1-172.16.0.2/require ;
spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
ah/tunnel/172.16.0.2-172.16.0.1/require ;
add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any
-A keyed-md5 "this is the test" ;
add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any
-A keyed-md5 "this is the test" ;
EOFIf the port number field is omitted such as above then
[any] is employed. -m
specifies the mode of SA to be used. -m any means
wild-card of mode of security protocol. You can use this SA for both
tunnel and transport mode.and at Gateway-B:&prompt.root; setkey -c <<EOF
spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
ah/tunnel/172.16.0.2-172.16.0.1/require ;
spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
ah/tunnel/172.16.0.1-172.16.0.2/require ;
add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any
-A keyed-md5 "this is the test" ;
add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any
-A keyed-md5 "this is the test" ;
EOFMaking SA bundle between two security gatewaysAH transport mode and ESP tunnel mode is required between
Gateway-A and Gateway-B. In this case, ESP tunnel mode is applied first,
and AH transport mode is next.
========== AH =========
| ======= ESP ===== |
| | | |
Network-A Gateway-A Gateway-B Network-B
fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64
Tunnel Mode Example with IPv6Encryption algorithm is 3des-cbc, and authentication algorithm
for ESP is hmac-sha1. Authentication algorithm for AH is hmac-md5.
Configuration at Gateway-A:&prompt.root; setkey -c <<EOF
spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec
esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require
ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ;
spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec
esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require
ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ;
add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel
-E 3des-cbc "kamekame12341234kame1234"
-A hmac-sha1 "this is the test key" ;
add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport
-A hmac-md5 "this is the test" ;
add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel
-E 3des-cbc "kamekame12341234kame1234"
-A hmac-sha1 "this is the test key" ;
add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport
-A hmac-md5 "this is the test" ;
EOFMaking SAs with the different endESP tunnel mode is required between Host-A and Gateway-A. Encryption
algorithm is cast128-cbc, and authentication algorithm for ESP is
hmac-sha1. ESP transport mode is recommended between Host-A and Host-B.
Encryption algorithm is rc5-cbc, and authentication algorithm for ESP is
hmac-md5.
================== ESP =================
| ======= ESP ======= |
| | | |
Host-A Gateway-A Host-B
fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2
Configuration at Host-A:&prompt.root; setkey -c <<EOF
spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec
esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use
esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ;
spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec
esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use
esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ;
add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001
-m transport
-E cast128-cbc "12341234"
-A hmac-sha1 "this is the test key" ;
add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002
-E rc5-cbc "kamekame"
-A hmac-md5 "this is the test" ;
add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003
-m transport
-E cast128-cbc "12341234"
-A hmac-sha1 "this is the test key" ;
add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004
-E rc5-cbc "kamekame"
-A hmac-md5 "this is the test" ;
EOFChernLeeContributed by OpenSSHOpenSSHsecurityOpenSSHSecure shell is a set of network connectivity tools used to
access remote machines securely. It can be used as a direct
replacement for rlogin,
rsh, rcp, and
telnet. Additionally, any other TCP/IP
connections can be tunneled/forwarded securely through ssh.
ssh encrypts all traffic to effectively eliminate eavesdropping,
connection hijacking, and other network-level attacks.OpenSSH is maintained by the OpenBSD project, and is based
upon SSH v1.2.12 with all the recent bug fixes and updates. It
is compatible with both SSH protocols 1 and 2. OpenSSH has been
- in the base system since FreeBSD 4.0.
+ in the base system since FreeBSD 4.0.
Advantages of Using OpenSSHNormally, when using &man.telnet.1; or &man.rlogin.1;,
data is sent over the network in an clear, un-encrypted form.
Network sniffers anywhere in between the client and server can
steal your user/password information or data transferred in
your session. OpenSSH offers a variety of authentication and
encryption methods to prevent this from happening.Enabling sshdOpenSSHenablingBe sure to make the following additions to your
rc.conf file:sshd_enable="YES"This will load the ssh daemon
the next time your system initializes. Alternatively, you can
simply run the sshd daemon.SSH ClientOpenSSHclientThe &man.ssh.1; utility works similarly to
&man.rlogin.1;.&prompt.root; ssh user@example.com
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'example.com' added to the list of known hosts.
user@example.com's password: *******The login will continue just as it would have if a session was
created using rlogin or
telnet. SSH utilizes a key fingerprint
system for verifying the authenticity of the server when the
client connects. The user is prompted to enter
yes only when
connecting for the first time. Future attempts to login are all
verified against the saved fingerprint key. The SSH client
will alert you if the saved fingerprint differs from the
received fingerprint on future login attempts. The fingerprints
are saved in ~/.ssh/known_hosts, or
~/.ssh/known_hosts2 for SSH v2
fingerprints.By default, OpenSSH servers are configured to accept both
SSH v1 and SSH v2 connections. The client, however, can choose
between the two. Version 2 is known to be more robust and
secure than its predecessor.ssh can be forced to use either protocol
by passing it the or argument
for v1 and v2, respectively.Secure CopyOpenSSHsecure copyscpThe scp command works similarly to
rcp; it copies a file to or from a remote machine,
except in a secure fashion.&prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT
user@example.com's password: *******
COPYRIGHT 100% |*****************************| 4735
00:00
&prompt.root;Since the fingerprint was already saved for this host in the
previous example, it is verified when using scp
here.The arguments passed to scp are similar
to cp, with the file or files in the first
argument, and the destination in the second. Since the file is
fetched over the network, through SSH, one or more of the file
arguments takes on the form
.ConfigurationOpenSSHconfigurationThe system-wide configuration files for both the OpenSSH
daemon and client reside within the /etc/ssh
directory.ssh_config configures the client
settings, while sshd_config configures the
daemon.Additionally, the
(/usr/sbin/sshd by default), and
rc.conf
options can provide more levels of configuration.ssh-keygenInstead of using passwords, &man.ssh-keygen.1; can
be used to generate RSA keys to authenticate a user.&prompt.user; ssh-keygen
Initializing random number generator...
Generating p: .++ (distance 66)
Generating q: ..............................++ (distance 498)
Computing the keys...
Key generation complete.
Enter file in which to save the key (/home/user/.ssh/identity):
Enter passphrase:
Enter the same passphrase again:
Your identification has been saved in /home/user/.ssh/identity.
...&man.ssh-keygen.1; will create a public and private
key pair for use in authentication. The private key is stored in
~/.ssh/identity, whereas the public key is
stored in ~/.ssh/identity.pub. The public
key must be placed in ~/.ssh/authorized_keys
of the remote machine in order for the setup to work.This will allow connection to the remote machine based upon
RSA authentication instead of passwords.If a passphrase is used in &man.ssh-keygen.1;, the user
will be prompted for a password each time in order to use the private
key.A SSH v2 DSA key can be created for the same purpose by using
the ssh-keygen -d command (or
ssh-keygen -t dsa for FreeBSD &os.current;).
This will
create a public/private DSA key for use in SSH v2 sessions only.
The public key is stored in ~/.ssh/id_dsa.pub,
while the private key is in ~/.ssh/id_dsa.DSA public keys are placed in
~/.ssh/authorized_keys2 on the remote
machine.&man.ssh-agent.1; and &man.ssh-add.1; are
utilities used in managing multiple passworded private keys.SSH TunnelingOpenSSHtunnelingOpenSSH has the ability to create a tunnel to encapsulate
another protocol in an encrypted session.The following command tells &man.ssh.1; to create a tunnel
for telnet.&prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
&prompt.user;The ssh command is used with the
following options:Forces ssh to use version 2 of
the protocol. (Do not use if you are working with older
ssh servers)Indicates no command, or tunnel only. If omitted,
ssh would initiate a normal
session.Forces ssh to run in the
background.Indicates a local tunnel in
localport:remotehost:remoteport
fashion.The remote SSH server.An SSH tunnel works by creating a listen socket on
localhost on the specified port.
It then forwards any connection received
on the local host/port via the SSH connection to the specified
remote host and port.In the example, port 5023 on
localhost is being forwarded to port
23 on localhost
of the remote machine. Since 23 is telnet,
this would create a secure telnet session through an SSH tunnel.This can be used to wrap any number of insecure TCP protocols
such as SMTP, POP3, FTP, etc.Using SSH to create a secure tunnel for SMTP&prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
&prompt.user; telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTPThis can be used in conjunction with an
&man.ssh-keygen.1; and additional user accounts to create a
more seamless/hassle-free SSH tunneling environment. Keys
can be used in place of typing a password, and the tunnels
can be run as a separate user.Practical SSH Tunneling ExamplesSecure Access of a POP3 serverAt work, there is an SSH server that accepts
connections from the outside. On the same office network
resides a mail server running a POP3 server. The network,
or network path between your home and office may or may not
be completely trustable. Because of this, you need to check
your e-mail in a secure manner. The solution is to create
an SSH connection to your office's SSH server, and tunnel
through to the mail server.&prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
user@ssh-server.example.com's password: ******When the tunnel is up and running, you can point your
mail client to send POP3 requests to localhost
port 2110. A connection here will be forwarded securely across
the tunnel to mail.example.com.Bypassing a Draconian FirewallSome network administrators impose extremely Draconian
firewall rules, filtering not only incoming connections,
but outgoing connections. You may be only given access
to contact remote machines on ports 22 and 80 for SSH
and web surfing.You may wish to access another (perhaps non-work
related) service, such as an Ogg Vorbis server to stream
music. If this Ogg Vorbis server is streaming on some other
port than 22 or 80, you will not be able to access it.The solution is to create an SSH connection to a machine
outside of your network's firewall, and use it to tunnel to
the Ogg Vorbis server.&prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled.myserver.com
user@unfirewalled.myserver.com's password: *******Your streaming client can now be pointed to
localhost port 8888, which will be
forwarded over to music.example.com port
8000, successfully evading the firewall.Further ReadingOpenSSH&man.ssh.1; &man.scp.1; &man.ssh-keygen.1;
&man.ssh-agent.1; &man.ssh-add.1;&man.sshd.8; &man.sftp-server.8;
diff --git a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml b/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
index 670e2bc290..d1f7e147e7 100644
--- a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
@@ -1,2625 +1,2625 @@
Serial CommunicationsSynopsisserial communicationsUnix has always had support for serial communications. In fact,
the very first Unix machines relied on serial lines for user input
and output. Things have changed a lot from the days when the average
terminal consisted of a 10-character-per-second serial
printer and a keyboard. This chapter will cover some of the ways in
which FreeBSD uses serial communications.After reading this chapter, you will know:How to connect terminals to your FreeBSD
system.How to use a modem to dial out to remote
hosts.How to allow remote users to login to your
system with a modem.How to boot your system from a serial
console.Before reading this chapter, you should:Know how to configure and install a new kernel ().Understand Unix permissions and processes ().Have access to the technical manual for the
serial hardware (modem or multi-port card) that you would like
to use with FreeBSD.IntroductionTerminologybits-per-secondbpsBits per Second — the rate at which data is
transmittedDTEDTEData Terminal Equipment — for example, your
computerDCEDCEData Communications Equipment — your modemRS-232RS-232C cablesEIA standard for hardware serial communicationsWhen talking about communications data rates, this section
does not use the term baud. Baud refers to the
number of electrical state transitions that may be made in a
period of time, while bps (bits per second) is
the correct term to use (at least it does not
seem to bother the curmudgeons quite a much).Cables and PortsTo connect a modem or terminal to your FreeBSD system, you
will need a serial port on your computer and the proper cable to connect
to your serial device. If you are already familiar with your
hardware and the cable it requires, you can safely skip this
section.CablesThere are several different kinds of serial cables. The
two most common types for our purposes are null-modem cables
and standard ("straight") RS-232 cables. The documentation
for your hardware should describe the type of cable
required.Null-modem Cablesnull-modem cableA null-modem cable passes some signals straight through, like
signal ground, but switches other signals. For
example, the send data pin on one end goes to the
receive data pin on the other end.If you like making your own cables, you can construct
a null-modem cable for use with
terminals. This table shows the RS-232C signal names and the pin
numbers on a DB-25 connector.SignalPin #Pin #SignalTxD2connects to3RxDRxD3connects to2TxDDTR20connects to6DSRDSR6connects to20DTRSG7connects to7SGDCD8connects to4RTSRTS45CTSCTS5connects to8DCDFor DCD to RTS, connect pins 4 to 5 internally in the
connector hood, and then to pin 8 in the remote
hood.Standard RS-232C CablesRS-232C cablesA standard serial cable passes all the RS-232C signals
straight-through. That is, the send data pin on one
end of the cable goes to the send data pin on the
other end. This is the type of cable to connect a modem to your
FreeBSD system, and the type of cable needed for some
terminals.PortsSerial ports are the devices through which data is transferred
between the FreeBSD host computer and the terminal. This section
describes the kinds of ports that exist and how they are addressed
in FreeBSD.Kinds of PortsSeveral kinds of serial ports exist. Before you purchase or
construct a cable, you need to make sure it will fit the ports on
your terminal and on the FreeBSD system.Most terminals will have DB25 ports. Personal computers,
including PCs running FreeBSD, will have DB25 or DB9 ports. If you
have a multiport serial card for your PC, you may have RJ-12 or
RJ-45 ports.See the documentation that accompanied the hardware for
specifications on the kind of port in use. A visual inspection of
the port often works too.Port NamesIn FreeBSD, you access each serial port through an entry in
the /dev directory. There are two different
kinds of entries:Call-in ports are named
/dev/ttydN
where N is the port number,
starting from zero. Generally, you use the call-in port for
terminals. Call-in ports require that the serial line assert
the data carrier detect (DCD) signal to work.Call-out ports are named
/dev/cuaaN.
You usually do not use the call-out port for terminals, just
for modems. You may use the call-out port if the serial cable
or the terminal does not support the carrier detect
signal.If you have connected a terminal to the first serial port
(COM1 in MS-DOS), then you want to
use /dev/ttyd0 to refer to the terminal. If
it is on the second serial port (also known as
COM2), it is
/dev/ttyd1, and so forth.Kernel ConfigurationFreeBSD supports four serial ports by default. In the
MS-DOS world, these are known as
COM1,
COM2,
COM3, and
COM4. FreeBSD currently supports
dumb multiport serial interface cards, such as
the BocaBoard 1008 and 2016, as well as more
intelligent multi-port cards such as those made by Digiboard
and Stallion Technologies. However, the default kernel only looks
for the standard COM ports.To see if your kernel recognizes any of your serial ports, watch
for messages while the kernel is booting, or use the
/sbin/dmesg command to replay the kernel's boot
messages. In particular, look for messages that start with the
characters sio.To view just the messages that have the word
sio, use the command:&prompt.root; /sbin/dmesg | grep 'sio'For example, on a system with four serial ports, these are the
serial-port specific kernel boot messages:sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
sio2 at 0x3e8-0x3ef irq 5 on isa
sio2: type 16550A
sio3 at 0x2e8-0x2ef irq 9 on isa
sio3: type 16550AIf your kernel does not recognize all of your serial
ports, you will probably need to configure a custom FreeBSD
kernel for your system. For detailed information on
configuring your kernel, please see .The relevant device lines for your kernel configuration
file would look like this:device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr
device sio3 at isa? port "IO_COM4" tty irq 9 vector siointrYou can comment-out or completely remove lines for devices
you do not have. Please see the &man.sio.4; manual page for
complete information on how to write configuration lines for
multiport boards. Be careful if you are using a configuration
file that was previously used for a different version of
FreeBSD because the device flags have changed between
versions.port "IO_COM1" is a substitution for
port 0x3f8, IO_COM2 is
0x2f8, IO_COM3 is
0x3e8, and IO_COM4 is
0x2e8, which are fairly common port addresses for
their respective serial ports; interrupts 4, 3, 5, and 9 are fairly
common interrupt request lines. Also note that regular serial ports
cannot share interrupts on ISA-bus PCs
(multiport boards have on-board electronics that allow all the
16550A's on the board to share one or two interrupt request
lines).Device Special FilesMost devices in the kernel are accessed through device
special files, which are located in the
/dev directory. The sio
devices are accessed through the
/dev/ttydN (dial-in)
and /dev/cuaaN
(call-out) devices. FreeBSD also provides initialization devices
(/dev/ttyidN and
/dev/cuai0N) and
locking devices
(/dev/ttyldN and
/dev/cual0N). The
initialization devices are used to initialize communications port
parameters each time a port is opened, such as
crtscts for modems which use
RTS/CTS signaling for flow control. The locking
devices are used to lock flags on ports to prevent users or programs
changing certain parameters; see the manual pages &man.termios.4;,
&man.sio.4;, and &man.stty.1; for
information on the terminal settings, locking and initializing
devices, and setting terminal options, respectively.Making Device Special Files
- FreeBSD 5.0 includes the devfs
+ FreeBSD 5.0 includes the devfs
filesystem which automatically creates device nodes as
needed. If you are running a version of FreeBSD with
devfs enabled then you can safely skip
this section.A shell script called MAKEDEV in the
/dev directory manages the device special
files. To use MAKEDEV to make dial-up device
special files for COM1 (port 0),
cd to /dev and issue the
command MAKEDEV ttyd0. Likewise, to make dial-up
device special files for COM2 (port 1),
use MAKEDEV ttyd1.MAKEDEV not only creates the
/dev/ttydN device
special files, but also the
/dev/cuaaN,
/dev/cuaiaN,
/dev/cualaN,
/dev/ttyldN,
and
/dev/ttyidN
nodes.After making new device special files, be sure to check the
permissions on the files (especially the
/dev/cua* files) to make sure that only users
who should have access to those device special files can read and
write on them — you probably do not want to allow your average
user to use your modems to dial-out. The default permissions on the
/dev/cua* files should be sufficient:crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cuaa1
crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuaia1
crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cuala1These permissions allow the user uucp and
users in the group dialer to use the call-out
devices.Serial Port ConfigurationttydcuaaThe ttydN (or
cuaaN) device is the
regular device you will want to open for your applications. When a
process opens the device, it will have a default set of terminal I/O
settings. You can see these settings with the command&prompt.root; stty -a -f /dev/ttyd1When you change the settings to this device, the settings are in
effect until the device is closed. When it is reopened, it goes back to
the default set. To make changes to the default set, you can open and
adjust the settings of the initial state device. For
example, to turn on mode, 8 bit communication,
and flow control by default for
ttyd5, type:&prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoffrc filesrc.serialSystem-wide initialization of the serial devices is
controlled in /etc/rc.serial. This file
affects the default settings of serial devices.To prevent certain settings from being changed by an
application, make adjustments to the lock state
device. For example, to lock the speed of
- ttyd5 to 57600 bps, type:
+ ttyd5 to 57600 bps, type:
&prompt.root; stty -f /dev/ttyld5 57600Now, an application that opens
ttyd5 and tries to change the speed of
- the port will be stuck with 57600 bps.
+ the port will be stuck with 57600 bps.
MAKEDEVNaturally, you should make the initial state and lock state devices
writable only by the root account.SeanKellyContributed by TerminalsterminalsTerminals provide a convenient and low-cost way to access
your FreeBSD system when you are not at the computer's console or on
a connected network. This section describes how to use terminals with
FreeBSD.Uses and Types of TerminalsThe original Unix systems did not have consoles. Instead, people
logged in and ran programs through terminals that were connected to
the computer's serial ports. It is quite similar to using a modem and
terminal software to dial into a remote system to do text-only
work.Today's PCs have consoles capable of high quality graphics, but
the ability to establish a login session on a serial port still exists
in nearly every Unix-style operating system today; FreeBSD is no
exception. By using a terminal attached to an unused serial port, you
can log in and run any text program that you would normally run on the
console or in an xterm window in the X Window
System.For the business user, you can attach many terminals to a FreeBSD
system and place them on your employees' desktops. For a home user, a
spare computer such as an older IBM PC or a Macintosh can be a
terminal wired into a more powerful computer running FreeBSD. You can
turn what might otherwise be a single-user computer into a powerful
multiple user system.For FreeBSD, there are three kinds of terminals:Dumb terminalsPCs acting as terminalsX terminalsThe remaining subsections describe each kind.Dumb TerminalsDumb terminals are specialized pieces of hardware that let you
connect to computers over serial lines. They are called
dumb because they have only enough computational power
to display, send, and receive text. You cannot run any programs on
them. It is the computer to which you connect them that has all the
power to run text editors, compilers, email, games, and so
forth.There are hundreds of kinds of dumb terminals made by many
manufacturers, including Digital Equipment Corporation's VT-100 and
Wyse's WY-75. Just about any kind will work with FreeBSD. Some
high-end terminals can even display graphics, but only certain
software packages can take advantage of these advanced
features.Dumb terminals are popular in work environments where workers do
not need access to graphic applications such as those provided by
the X Window System.PCs Acting As TerminalsIf a dumb terminal has just
enough ability to display, send, and receive text, then certainly
any spare personal computer can be a dumb terminal. All you need is
the proper cable and some terminal emulation
software to run on the computer.Such a configuration is popular in homes. For example, if your
spouse is busy working on your FreeBSD system's console, you can do
some text-only work at the same time from a less powerful personal
computer hooked up as a terminal to the FreeBSD system.X TerminalsX terminals are the most sophisticated kind of terminal
available. Instead of connecting to a serial port, they usually
connect to a network like Ethernet. Instead of being relegated to
text-only applications, they can display any X application.We introduce X terminals just for the sake of completeness.
However, this chapter does not cover setup,
configuration, or use of X terminals.ConfigurationThis section describes what you need to configure on your FreeBSD
system to enable a login session on a terminal. It assumes you have
already configured your kernel to support the serial port to which the
terminal is connected—and that you have connected it.Recall from that the
init process is responsible for all process
control and initialization at system startup. One of the
tasks performed by init is to read the
/etc/ttys file and start a
getty process on the available terminals.
The getty process is responsible for
reading a login name and starting the login
program.Thus, to configure terminals for your FreeBSD system the
following steps should be taken as root:Add a line to /etc/ttys for the entry in
the /dev directory for the serial port if it
is not already there.Specify that /usr/libexec/getty be run on
the port, and specify the appropriate
getty type from the
/etc/gettytab file.Specify the default terminal type.Set the port to on.Specify whether the port should be
secure.Force init to reread the
/etc/ttys file.As an optional step, you may wish to create a custom
getty type for use in step 2 by making an
entry in /etc/gettytab. This chapter does
not explain how to do so; you are encouraged to see the
&man.gettytab.5; and the &man.getty.8; manual pages for more
information.Adding an Entry to /etc/ttysThe /etc/ttys file lists all of the ports
on your FreeBSD system where you want to allow logins. For example,
the first virtual console ttyv0 has an entry in
this file. You can log in on the console using this entry. This
file also contains entries for the other virtual consoles, serial ports,
and pseudo-ttys. For a hardwired terminal, just list the serial
port's /dev entry without the
/dev part (for example,
/dev/ttyv0 would be listed as
ttyv0).A default FreeBSD install includes an
/etc/ttys file with support for the first
four serial ports: ttyd0 through
ttyd3. If you are attaching a terminal
to one of those ports, you do not need to add another entry.Adding Terminal Entries to
/etc/ttysSuppose we would like to connect two terminals to the
system: a Wyse-50 and an old 286 IBM PC running
Procomm terminal software
emulating a VT-100 terminal. We connect the Wyse to the
second serial port and the 286 to the sixth serial port (a
port on a multiport serial card). The corresponding
entries in the /etc/ttys file would
look like this:ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure
ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure
The first field normally specifies the name of
the terminal special file as it is found in
/dev.The second field is the command to execute for
this line, which is usually &man.getty.8;.
getty initializes and opens the
line, sets the speed, prompts for a user name and then
executes the &man.login.1; program.The getty program accepts one
(optional) parameter on its command line, the
getty type. A
getty type tells about
characteristics on the terminal line, like bps rate
and parity. The getty program reads
these characteristics from the file
/etc/gettytab.The file /etc/gettytab
contains lots of entries for terminal lines both old
and new. In almost all cases, the entries that start
with the text std will work for
hardwired terminals. These entries ignore parity.
There is a std entry for each bps
rate from 110 to 115200. Of course, you can add your
own entries to this file. The &man.gettytab.5; manual
page provides more information.When setting the getty
type in the /etc/ttys file, make
sure that the communications settings on the terminal
match.For our example, the Wyse-50 uses no parity and
- connects at 38400 bps. The 286 PC uses no parity and
- connects at 19200 bps.
+ connects at 38400 bps. The 286 PC uses no parity and
+ connects at 19200 bps.
The third field is the type of terminal usually
connected to that tty line. For dial-up ports,
unknown or
dialup is typically used in this
field since users may dial up with practically any
type of terminal or software. For hardwired
terminals, the terminal type does not change, so you
can put a real terminal type from the &man.termcap.5;
database file in this field.For our example, the Wyse-50 uses the real
terminal type while the 286 PC running
Procomm will be set to
emulate at VT-100. The fourth field specifies if the port should be
enabled. Putting on here will have
the init process start the program
in the second field, getty. If you
put off in this field, there will
be no getty, and hence no logins on
the port.The final field is used to specify whether the
port is secure. Marking a port as secure means that
you trust it enough to allow the
root account (or any account with
a user ID of 0) to login from that port. Insecure
ports do not allow root logins.
On an insecure port, users must login from
unprivileged accounts and then use &man.su.1; or a
similar mechanism to gain superuser privileges.It is highly recommended that you use
insecure
even for terminals that are behind locked doors. It
is quite easy to login and use su
if you need superuser privileges.Force init to Reread
/etc/ttysAfter making the necessary changes to the
/etc/ttys file you should send a SIGHUP
(hangup) signal to the init process to
force it to re-read its configuration file. For example:&prompt.root; kill -HUP 1init is always the first process run
on a system, therefore it will always have PID 1.If everything is set up correctly, all cables are in
place, and the terminals are powered up, then a
getty process should be running on each
terminal and you should see login prompts on your terminals
at this point.Troubleshooting Your ConnectionEven with the most meticulous attention to detail, something could
still go wrong while setting up a terminal. Here is a list of
symptoms and some suggested fixes.No login prompt appearsMake sure the terminal is plugged in and powered up. If it
is a personal computer acting as a terminal, make sure it is
running terminal emulation software on the correct serial
port.Make sure the cable is connected firmly to both the terminal
and the FreeBSD computer. Make sure it is the right kind of
cable.Make sure the terminal and FreeBSD agree on the bps rate and
parity settings. If you have a video display terminal, make
sure the contrast and brightness controls are turned up. If it
is a printing terminal, make sure paper and ink are in good
supply.Make sure that a getty process is running
and serving the terminal. For example, to get a list of
running getty processes with
ps, type:&prompt.root; ps -axww|grep gettyYou should see an entry for the terminal. For
example, the following display shows that a
getty is running on the second serial
port ttyd1 and is using the
std.38400 entry in
/etc/gettytab:22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1If no getty process is running, make sure
you have enabled the port in /etc/ttys.
Also remember to run kill -HUP 1
after modifying the ttys file.If the getty process is running
but the terminal still does not display a login prompt,
or if it displays a prompt but will not allow you to
type, your terminal or cable may not support hardware
handshaking. Try changing the entry in
/etc/ttys from
std.38400 to
3wire.38400 remember to run
kill -HUP 1 after modifying
/etc/ttys). The
3wire entry is similar to
std, but ignores hardware
handshaking. You may need to reduce the baud rate or
enable software flow control when using
3wire to prevent buffer
overflows.Garbage appears instead of a login promptMake sure the terminal and FreeBSD agree on the bps rate and
parity settings. Check the getty processes
to make sure the
correct getty type is in use. If
not, edit /etc/ttys and run kill
-HUP 1.Characters appear doubled; the password appears when
typedSwitch the terminal (or the terminal emulation software)
from half duplex or local echo to
full duplex.GuyHelmerContributed by SeanKellyAdditions by Dial-in Servicedial-in serviceConfiguring your FreeBSD system for dial-in service is very
similar to connecting terminals except that you are dealing with
modems instead of terminals.External vs. Internal ModemsExternal modems seem to be more convenient for dial-up, because
external modems often can be semi-permanently configured via
parameters stored in non-volatile RAM and they usually provide
lighted indicators that display the state of important RS-232
signals. Blinking lights impress visitors, but lights are also very
useful to see whether a modem is operating properly.Internal modems usually lack non-volatile RAM, so their
configuration may be limited only to setting DIP switches. If your
internal modem has any signal indicator lights, it is probably
difficult to view the lights when the system's cover is in
place.Modems and CablesmodemIf you are using an external modem, then you will of
course need the proper cable. A standard RS-232C serial
cable should suffice as long as all of the normal signals
are wired:Transmitted Data (SD)Received Data (RD)Request to Send (RTS)Clear to Send (CTS)Data Set Ready (DSR)Data Terminal Ready (DTR)Carrier Detect (CD)Signal Ground (SG)FreeBSD needs the RTS and
CTS signals for flow-control at speeds above
- 2400bps, the CD signal to detect when a call has
+ 2400 bps, the CD signal to detect when a call has
been answered or the line has been hung up, and the
DTR signal to reset the modem after a session is
complete. Some cables are wired without all of the needed signals,
so if you have problems, such as a login session not going away when
the line hangs up, you may have a problem with your cable.Like other Unix-like operating systems, FreeBSD uses the
hardware signals to find out when a call has been answered
or a line has been hung up and to hangup and reset the modem
after a call. FreeBSD avoids sending commands to the modem
or watching for status reports from the modem. If you are
familiar with connecting modems to PC-based bulletin board
systems, this may seem awkward.Serial Interface ConsiderationsFreeBSD supports NS8250-, NS16450-, NS16550-, and NS16550A-based
EIA RS-232C (CCITT V.24) communications interfaces. The 8250 and
16450 devices have single-character buffers. The 16550 device
provides a 16-character buffer, which allows for better system
performance. (Bugs in plain 16550's prevent the use of the
16-character buffer, so use 16550A's if possible). Because
single-character-buffer devices require more work by the operating
system than the 16-character-buffer devices, 16550A-based serial
interface cards are much preferred. If the system has many active
serial ports or will have a heavy load, 16550A-based cards are
better for low-error-rate communications.Quick OverviewgettyAs with terminals, init spawns a
getty process for each configured serial
port for dial-in connections. For example, if a modem is
attached to /dev/ttyd0, the command
ps ax might show this: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0When a user dials the modem's line and the modems connect, the
CD (Carrier Detect) line is reported by the modem.
The kernel
notices that carrier has been detected and completes
getty's open of the port. getty
sends a login: prompt at the specified initial line
speed. getty watches to see if legitimate
characters are received, and, in a typical configuration, if it finds
junk (probably due to the modem's connection speed being different
than getty's speed), getty tries
adjusting the line speeds until it receives reasonable
characters./usr/bin/loginAfter the user enters his/her login name,
getty executes
/usr/bin/login, which completes the login
by asking for the user's password and then starting the user's
shell.Configuration FilesThere are three system configuration files in the
/etc directory that you will probably need to
edit to allow dial-up access to your FreeBSD system. The first,
/etc/gettytab, contains configuration information
for the /usr/libexec/getty daemon. Second,
/etc/ttys holds information that tells
/sbin/init what tty devices
should have getty processes running on them.
Lastly, you can place port initialization commands in the
/etc/rc.serial script.There are two schools of thought regarding dial-up modems on Unix.
One group likes to configure their modems and systems so that no matter
at what speed a remote user dials in, the local computer-to-modem
RS-232 interface runs at a locked speed. The benefit of this
configuration is that the remote user always sees a system login
prompt immediately. The downside is that the system does not know
what a user's true data rate is, so full-screen programs like Emacs
will not adjust their screen-painting methods to make their response
better for slower connections.The other school configures their modems' RS-232 interface to vary
its speed based on the remote user's connection speed. For example,
- V.32bis (14.4 Kbps) connections to the modem might make the modem run
- its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the
- modem's RS-232 interface run at 2400 bps. Because
+ V.32bis (14.4 Kbps) connections to the modem might make the modem run
+ its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the
+ modem's RS-232 interface run at 2400 bps. Because
getty does not understand any particular modem's
connection speed reporting, getty gives a
login: message at an initial speed and watches the
characters that come back in response. If the user sees junk, it is
assumed that they know they should press the
Enter key until they see a recognizable
prompt. If the data rates do not match, getty sees
anything the user types as junk, tries going to the next
speed and gives the login: prompt again. This
procedure can continue ad nauseam, but normally only takes a keystroke
or two before the user sees a good prompt. Obviously, this login
sequence does not look as clean as the former
locked-speed method, but a user on a low-speed
connection should receive better interactive response from full-screen
programs.This section will try to give balanced configuration information,
but is biased towards having the modem's data rate follow the
connection rate./etc/gettytab/etc/gettytab/etc/gettytab is a &man.termcap.5;-style
file of configuration information for &man.getty.8;. Please see the
&man.gettytab.5; manual page for complete information on the
format of the file and the list of capabilities.Locked-Speed ConfigIf you are locking your modem's data communications rate at a
particular speed, you probably will not need to make any changes
to /etc/gettytab.Matching-Speed ConfigYou will need to setup an entry in
/etc/gettytab to give
getty information about the speeds you wish to
- use for your modem. If you have a 2400 bps modem, you can
+ use for your modem. If you have a 2400 bps modem, you can
probably use the existing D2400 entry.#
# Fast dialup terminals, 2400/1200/300 rotary (can start either way)
#
D2400|d2400|Fast-Dial-2400:\
:nx=D1200:tc=2400-baud:
3|D1200|Fast-Dial-1200:\
:nx=D300:tc=1200-baud:
5|D300|Fast-Dial-300:\
:nx=D2400:tc=300-baud:If you have a higher speed modem, you will probably need to
add an entry in /etc/gettytab; here is an
- entry you could use for a 14.4 Kbps modem with a top interface
- speed of 19.2 Kbps:
+ entry you could use for a 14.4 Kbps modem with a top interface
+ speed of 19.2 Kbps:
#
# Additions for a V.32bis Modem
#
um|V300|High Speed Modem at 300,8-bit:\
:nx=V19200:tc=std.300:
un|V1200|High Speed Modem at 1200,8-bit:\
:nx=V300:tc=std.1200:
uo|V2400|High Speed Modem at 2400,8-bit:\
:nx=V1200:tc=std.2400:
up|V9600|High Speed Modem at 9600,8-bit:\
:nx=V2400:tc=std.9600:
uq|V19200|High Speed Modem at 19200,8-bit:\
:nx=V9600:tc=std.19200:This will result in 8-bit, no parity connections.
- The example above starts the communications rate at 19.2 Kbps
- (for a V.32bis connection), then cycles through 9600 bps (for
- V.32), 2400 bps, 1200 bps, 300 bps, and back to 19.2 Kbps.
+ The example above starts the communications rate at 19.2 Kbps
+ (for a V.32bis connection), then cycles through 9600 bps (for
+ V.32), 2400 bps, 1200 bps, 300 bps, and back to 19.2 Kbps.
Communications rate cycling is implemented with the
nx= (next table) capability.
Each of the lines uses a tc= (table
continuation) entry to pick up the rest of the
standard settings for a particular data rate.
- If you have a 28.8 Kbps modem and/or you want to take
- advantage of compression on a 14.4 Kbps modem, you need to use a
- higher communications rate than 19.2 Kbps. Here is an example of
- a gettytab entry starting a 57.6 Kbps:
+ If you have a 28.8 Kbps modem and/or you want to take
+ advantage of compression on a 14.4 Kbps modem, you need to use a
+ higher communications rate than 19.2 Kbps. Here is an example of
+ a gettytab entry starting a 57.6 Kbps:#
# Additions for a V.32bis or V.34 Modem
# Starting at 57.6 Kbps
#
vm|VH300|Very High Speed Modem at 300,8-bit:\
:nx=VH57600:tc=std.300:
vn|VH1200|Very High Speed Modem at 1200,8-bit:\
:nx=VH300:tc=std.1200:
vo|VH2400|Very High Speed Modem at 2400,8-bit:\
:nx=VH1200:tc=std.2400:
vp|VH9600|Very High Speed Modem at 9600,8-bit:\
:nx=VH2400:tc=std.9600:
vq|VH57600|Very High Speed Modem at 57600,8-bit:\
:nx=VH9600:tc=std.57600:If you have a slow CPU or a heavily loaded system and do
not have 16550A-based serial ports, you may receive
sio
- silo errors at 57.6 Kbps.
+ silo errors at 57.6 Kbps./etc/ttys/etc/ttysConfiguration of the /etc/ttys file
was covered in .
Configuration for modems is similar but we must pass a
different argument to getty and specify a
different terminal type. The general format for both
locked-speed and matching-speed configurations is:ttyd0 "/usr/libexec/getty xxx" dialup onThe first item in the above line is the device special file for
this entry — ttyd0 means
/dev/ttyd0 is the file that this
getty will be watching. The second item,
"/usr/libexec/getty
xxx"
(xxx will be replaced by the initial
gettytab capability) is the process
init will run on the device. The third item,
dialup, is the default terminal type. The fourth
parameter, on, indicates to
init that the line is operational. There can be
a fifth parameter, secure, but it should only be
used for terminals which are physically secure (such as the system
console).The default terminal type (dialup in the
example above) may depend on local preferences.
dialup is the traditional default terminal type
on dial-up lines so that users may customize their login scripts to
notice when the terminal is dialup and
automatically adjust their terminal type. However, the author finds
it easier at his site to specify vt102 as the
default terminal type, since the users just use VT102 emulation on
their remote systems.After you have made changes to /etc/ttys,
you may send the init process a
HUP signal to re-read the file. You can use the
command
&prompt.root; kill -HUP 1
to send the signal. If this is your first time setting up the
system, you may want to wait until your modem(s) are properly
configured and connected before signaling init.
Locked-Speed ConfigFor a locked-speed configuration, your
ttys entry needs to have a fixed-speed entry
provided to getty. For a modem whose port
- speed is locked at 19.2 Kbps, the ttys entry
+ speed is locked at 19.2 Kbps, the ttys entry
might look like this:ttyd0 "/usr/libexec/getty std.19200" dialup onIf your modem is locked at a different data rate,
substitute the appropriate value for
std.speed
instead of std.19200. Make sure that
you use a valid type listed in
/etc/gettytab.Matching-Speed ConfigIn a matching-speed configuration, your
ttys entry needs to reference the appropriate
beginning auto-baud (sic) entry in
/etc/gettytab. For example, if you added the
above suggested entry for a matching-speed modem that starts at
- 19.2 Kbps (the gettytab entry containing the
+ 19.2 Kbps (the gettytab entry containing the
V19200 starting point), your
ttys entry might look like this:ttyd0 "/usr/libexec/getty V19200" dialup on/etc/rc.serialrc filesrc.serialHigh-speed modems, like V.32, V.32bis, and V.34 modems,
need to use hardware (RTS/CTS) flow
control. You can add stty commands to
/etc/rc.serial to set the hardware flow
control flag in the FreeBSD kernel for the modem
ports.For example to set the termios flag
crtscts on serial port #1's
(COM2) dial-in and dial-out initialization
devices, the following lines could be added to
/etc/rc.serial:# Serial port initial configuration
stty -f /dev/ttyid1 crtscts
stty -f /dev/cuai01 crtsctsModem SettingsIf you have a modem whose parameters may be permanently set in
non-volatile RAM, you will need to use a terminal program (such as
Telix under MS-DOS or tip under FreeBSD) to set the
parameters. Connect to the modem using the same communications speed
as the initial speed getty will use and configure
the modem's non-volatile RAM to match these requirements:CD asserted when connectedDTR asserted for operation; dropping DTR
hangs up line and resets modemCTS transmitted data flow controlDisable XON/XOFF flow controlRTS received data flow controlQuiet mode (no result codes)No command echoPlease read the documentation for your modem to find out what
commands and/or DIP switch settings you need to give it.For example, to set the above parameters on a USRobotics
Sportster 14,400 external modem, one could give these commands to
the modem:ATZ
AT&C1&D2&H1&I0&R2&WYou might also want to take this opportunity to adjust other
settings in the modem, such as whether it will use V.42bis and/or MNP5
compression.The USR Sportster 14,400 external modem also has some DIP switches
that need to be set; for other modems, perhaps you can use these
settings as an example:Switch 1: UP — DTR NormalSwitch 2: N/A (Verbal Result Codes/Numeric Result
Codes)Switch 3: UP — Suppress Result CodesSwitch 4: DOWN — No echo, offline commandsSwitch 5: UP — Auto AnswerSwitch 6: UP — Carrier Detect NormalSwitch 7: UP — Load NVRAM DefaultsSwitch 8: N/A (Smart Mode/Dumb Mode)Result codes should be disabled/suppressed for dial-up modems to
avoid problems that can occur if getty mistakenly
gives a login: prompt to a modem that is in command
mode and the modem echoes the command or returns a result
code. This sequence can result in a extended, silly conversation
between getty and the modem.Locked-speed ConfigFor a locked-speed configuration, you will need to configure the
modem to maintain a constant modem-to-computer data rate independent
of the communications rate. On a USR Sportster 14,400 external
modem, these commands will lock the modem-to-computer data rate at
the speed used to issue the commands:ATZ
AT&B1&WMatching-speed ConfigFor a variable-speed configuration, you will need to configure
your modem to adjust its serial port data rate to match the incoming
call rate. On a USR Sportster 14,400 external modem, these commands
will lock the modem's error-corrected data rate to the speed used to
issue the commands, but allow the serial port rate to vary for
non-error-corrected connections:ATZ
AT&B2&WChecking the Modem's ConfigurationMost high-speed modems provide commands to view the modem's
current operating parameters in a somewhat human-readable fashion.
On the USR Sportster 14,400 external modems, the command
ATI5 displays the settings that are stored in the
non-volatile RAM. To see the true operating parameters of the modem
(as influenced by the USR's DIP switch settings), use the commands
ATZ and then ATI4.If you have a different brand of modem, check your modem's
manual to see how to double-check your modem's configuration
parameters.TroubleshootingHere are a few steps you can follow to check out the dial-up modem
on your system.Checking out the FreeBSD SystemHook up your modem to your FreeBSD system, boot the system, and,
if your modem has status indication lights, watch to see whether the
modem's DTR indicator lights when the
login: prompt appears on the system's console
— if it lights up, that should mean that FreeBSD has started a
getty process on the appropriate communications
port and is waiting for the modem to accept a call.If the DTR indicator does not light, login to
the FreeBSD system through the console and issue a ps
ax to see if FreeBSD is trying to run a
getty process on the correct port. You should see
lines like these among the processes displayed: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0
115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1If you see something different, like this: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0and the modem has not accepted a call yet, this means that
getty has completed its open on the
communications port. This could indicate a problem with the cabling
or a mis-configured modem, because getty should
not be able to open the communications port until
CD (carrier detect) has been asserted by the
modem.If you do not see any getty processes waiting
to open the desired
ttydN port,
double-check your entries in /etc/ttys to see
if there are any mistakes there. Also, check the log file
/var/log/messages to see if there are any log
messages from init or getty
regarding any problems. If there are any messages, triple-check the
configuration files /etc/ttys and
/etc/gettytab, as well as the appropriate
device special files /dev/ttydN, for any
mistakes, missing entries, or missing device special files.Try Dialing InTry dialing into the system; be sure to use 8 bits, no parity,
and 1
stop bit on the remote system. If you do not get a prompt right
away, or get garbage, try pressing Enter
about once per second. If you still do not see a
login: prompt after a while, try sending a
BREAK. If you are using a high-speed modem to do
the dialing, try dialing again after locking the dialing modem's
interface speed (via AT&B1 on a USR
Sportster, for example).If you still cannot get a login: prompt, check
/etc/gettytab again and double-check
thatThe initial capability name specified in
/etc/ttys for the line matches a name of a
capability in /etc/gettytabEach nx= entry matches another
gettytab capability nameEach tc= entry matches another
gettytab capability nameIf you dial but the modem on the FreeBSD system will not answer,
make sure that the modem is configured to answer the phone when
DTR is asserted. If the modem seems to be
configured correctly, verify that the DTR line is
asserted by checking the modem's indicator lights (if it has
any).If you have gone over everything several times and it still does
not work, take a break and come back to it later. If it still does
not work, perhaps you can send an electronic mail message to the
&a.questions; describing your modem and your problem, and the good
folks on the list will try to help.Dial-out Servicedial-out serviceThe following are tips to getting your host to be able to connect
over the modem to another computer. This is appropriate for
establishing a terminal session with a remote host.This is useful to log onto a BBS.This kind of connection can be extremely helpful to get a file on
the Internet if you have problems with PPP. If you need to FTP
something and PPP is broken, use the terminal session to FTP it. Then
use zmodem to transfer it to your machine.My Stock Hayes Modem Is Not Supported, What Can I Do?Actually, the manual page for tip is out of date.
There is a generic Hayes dialer already built in. Just use
at=hayes in your /etc/remote
file.The Hayes driver is not smart enough to recognize some of the
advanced features of newer modems—messages like
BUSY, NO DIALTONE, or
CONNECT 115200 will just confuse it. You should
turn those messages off when you use tip (using
ATX0&W).Also, the dial timeout for tip is 60 seconds.
Your modem should use something less, or else tip will think there is
a communication problem. Try ATS7=45&W.As shipped, tip does not yet support
Hayes modems fully. The solution is to edit the file
tipconf.h in the directory
/usr/src/usr.bin/tip/tip. Obviously you need the
source distribution to do this.Edit the line #define HAYES 0 to
#define HAYES 1. Then make and
make install. Everything works nicely after
that.How Am I Expected to Enter These AT Commands?/etc/remoteMake what is called a direct entry in your
/etc/remote file. For example, if your modem is
hooked up to the first serial port, /dev/cuaa0,
then put in the following line:cuaa0:dv=/dev/cuaa0:br#19200:pa=noneUse the highest bps rate your modem supports in the br capability.
Then, type tip cuaa0 and you will be connected to
your modem.If there is no /dev/cuaa0 on your system, do
this:&prompt.root; cd /dev
&prompt.root; sh MAKEDEV cuaa0Or use cu as root with the
following command:&prompt.root; cu -lline -sspeedline is the serial port
(e.g./dev/cuaa0) and
speed is the speed
(e.g.57600). When you are done entering the AT
commands hit ~. to exit.The @ Sign for the pn Capability Does Not
Work!The @ sign in the phone number capability tells
tip to look in /etc/phones for a phone number.
But the @ sign is also a special character in
capability files like /etc/remote. Escape it
with a backslash:pn=\@How Can I Dial a Phone Number on the Command Line?Put what is called a generic entry in your
/etc/remote file. For example:tip115200|Dial any phone number at 115200 bps:\
:dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
tip57600|Dial any phone number at 57600 bps:\
:dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:Then you can do things like:&prompt.root; tip -115200 5551234If you prefer cu over tip,
use a generic cu entry:cu115200|Use cu to dial any number at 115200bps:\
:dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:and type:&prompt.root; cu 5551234 -s 115200Do I Have to Type in the bps Rate Every Time I Do That?Put in an entry for tip1200 or
cu1200, but go ahead and use whatever bps rate is
appropriate with the br capability. tip thinks a
- good default is 1200 bps which is why it looks for a
- tip1200 entry. You do not have to use 1200 bps,
+ good default is 1200 bps which is why it looks for a
+ tip1200 entry. You do not have to use 1200 bps,
though.I Access a Number of Hosts through a Terminal ServerRather than waiting until you are connected and typing
CONNECT <host> each time, use tip's
cm capability. For example, these entries in
/etc/remote:pain|pain.deep13.com|Forrester's machine:\
:cm=CONNECT pain\n:tc=deep13:
muffin|muffin.deep13.com|Frank's machine:\
:cm=CONNECT muffin\n:tc=deep13:
deep13:Gizmonics Institute terminal server:\
:dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234:will let you type tip pain or tip
muffin to connect to the hosts pain or muffin, and
tip deep13 to get to the terminal server.Can Tip Try More Than one Line for each Site?This is often a problem where a university has several modem lines
and several thousand students trying to use them...Make an entry for your university in
/etc/remote and use @ for the
pn capability:big-university:\
:pn=\@:tc=dialout
dialout:\
:dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:Then, list the phone numbers for the university in
/etc/phones:big-university 5551111
big-university 5551112
big-university 5551113
big-university 5551114tip will try each one in the listed order, then
give up. If you want to keep retrying, run tip in
a while loop.Why Do I Have to Hit
CtrlP
Twice to Send
CtrlP
Once?CtrlP is the default force character, used to tell
tip that the next character is literal data. You
can set the force character to any other character with the
~s escape, which means set a
variable.Type
~sforce=single-char
followed by a newline. single-char is any
single character. If you leave out
single-char, then the force character is
the nul character, which you can get by typing
Ctrl2
or
CtrlSpace.
A pretty good value for single-char is
ShiftCtrl6, which is only used on some terminal
servers.You can have the force character be whatever you want by
specifying the following in your $HOME/.tiprc
file:force=<single-char>Suddenly Everything I Type Is in UPPER CASE??You must have pressed
CtrlA, tip's
raise character, specially designed for people with
broken caps-lock keys. Use ~s as above and set the
variable raisechar to something reasonable. In
fact, you can set it to the same as the force character, if you never
expect to use either of these features.Here is a sample .tiprc file perfect for
Emacs users who need to type
Ctrl2
and
CtrlA
a lot:force=^^
raisechar=^^The ^^ is
ShiftCtrl6.How Can I Do File Transfers with tip?If you are talking to another Unix system, you can send and
receive files with ~p (put) and
~t (take). These commands run
cat and echo on the remote
system to accept and send files. The syntax is:~plocal-fileremote-file~tremote-filelocal-fileThere is no error checking, so you probably should use another
protocol, like zmodem.How Can I Run zmodem with tip?To receive files, start the sending program on the remote end.
Then, type ~C rz to begin receiving them
locally.To send files, start the receiving program on the remote end.
Then, type ~C sz files
to send them to the remote system.KazutakaYOKOTAContributed by BillPaulBased on a document by Setting Up the Serial Consoleserial consoleIntroductionFreeBSD has the ability to boot on a system with only
a dumb terminal on a serial port as a console. Such a configuration
should be useful for two classes of people: system administrators who
wish to install FreeBSD on machines that have no keyboard or monitor
attached, and developers who want to debug the kernel or device
drivers.As described in , FreeBSD employs a three stage
bootstrap. The first two stages are in the boot block code which is
stored at the beginning of the FreeBSD slice on the boot disk. The
boot block will then load and run the boot loader
(/boot/loader) as the third stage code.In order to set up the serial console you must configure the boot
block code, the boot loader code and the kernel.Serial Console ConfigurationPrepare a serial cable.null-modem cableYou will need either a null-modem cable or a standard serial
cable and a null-modem adapter. See for
a discussion on serial cables.Unplug your keyboard.Most PC systems probe for the keyboard during the Power-On
Self-Test (POST) and will generate an error if the keyboard is not
detected. Some machines complain loudly about the lack of a
keyboard and will not continue to boot until it is plugged
in.If your computer complains about the error, but boots anyway,
then you do not have to do anything special. (Some machines with
Phoenix BIOS installed merely say Keyboard
failed and continue to boot normally.)If your computer refuses to boot without a keyboard attached
then you will have to configure the BIOS so that it ignores this
error (if it can). Consult your motherboard's manual for details
on how to do this.Setting the keyboard to Not installed in the
BIOS setup does not mean that you will not
be able to use your keyboard. All this does is tell the BIOS
not to probe for a keyboard at power-on, so it will not
complain if the keyboard is not plugged in. You can leave the
keyboard plugged in even with this flag set to Not
installed and the keyboard will still work.If your system has a PS/2 mouse, chances are very good that
you may have to unplug your mouse as well as your keyboard.
This is because PS/2 mice share some hardware with the keyboard
and leaving the mouse plugged in can fool the keyboard probe
into thinking the keyboard is still there. It is said that a
- Gateway 2000 Pentium 90MHz system with an AMI BIOS that behaves
+ Gateway 2000 Pentium 90 MHz system with an AMI BIOS that behaves
this way. In general, this is not a problem since the mouse is
not much good without the keyboard anyway.Plug a dumb terminal into COM1
(sio0).If you do not have a dumb terminal, you can use an old PC/XT
with a modem program, or the serial port on another Unix box. If
you do not have a COM1
(sio0), get one. At this time, there is
no way to select a port other than COM1
for the boot blocks without recompiling the boot blocks. If you
are already using COM1 for another
device, you will have to temporarily remove that device and
install a new boot block and kernel once you get FreeBSD up and
running. (It is assumed that COM1 will
be available on a file/compute/terminal server anyway; if you
really need COM1 for something else
(and you cannot switch that something else to
COM2 (sio1)),
then you probably should not even be bothering with all this in
the first place.)Make sure the configuration file of your kernel has
appropriate flags set for COM1
(sio0).Relevant flags are:0x10Enables console support for this unit. The other
console flags are ignored unless this is set. Currently, at
most one unit can have console support; the first one (in
config file order) with this flag set is preferred. This
option alone will not make the serial port the console. Set
the following flag or use the option
described below, together with this flag.0x20Forces this unit to be the console (unless there is
another higher priority console), regardless of the
option discussed below. This flag
replaces the COMCONSOLE option in FreeBSD
versions 2.X. The flag 0x20 must be used
together with the flag.0x40Reserves this unit (in conjunction with
0x10) and makes the unit
unavailable for normal access. You should not set
this flag to the serial port unit which you want to
use as the serial console. The only use of this
flag is to designate the unit for kernel remote
debugging. See The
Developer's Handbook for more information on
remote debugging.
- In FreeBSD 4.0 or later the semantics of the
+ In FreeBSD 4.0 or later the semantics of the
flag 0x40 are slightly different and
there is another flag to specify a serial port for remote
debugging.Example:device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4See the &man.sio.4; manual page for more details.If the flags were not set, you need to run UserConfig (on a
different console) or recompile the kernel.Create boot.config in the root directory
of the a partition on the boot drive.This file will instruct the boot block code how you would like
to boot the system. In order to activate the serial console, you
need one or more of the following options—if you want
multiple options, include them all on the same line:Toggles internal and serial consoles. You can use this
to switch console devices. For instance, if you boot from
the internal (video) console, you can use
to direct the boot loader and the kernel
to use the serial port as its console device. Alternatively,
if you boot from the serial port, you can use the
to tell the boot loader and the kernel
to use the video display as the console instead.Toggles single and dual console configurations. In the
single configuration the console will be either the internal
console (video display) or the serial port, depending on the
state of the option above. In the dual
console configuration, both the video display and the
serial port will become the console at the same time,
regardless of the state of the option.
However, note that the dual console configuration takes effect
only during the boot block is running. Once the boot loader
gets control, the console specified by the
option becomes the only console.Makes the boot block probe the keyboard. If no keyboard
is found, the and
options are automatically set.Due to space constraints in the current version of the
boot blocks, the option is capable of
detecting extended keyboards only. Keyboards with less
than 101 keys (and without F11 and F12 keys) may not be
detected. Keyboards on some laptop computers may not be
properly found because of this limitation. If this is
the case with your system, you have to abandon using
the option. Unfortunately there is no
workaround for this problem.Use either the option to select the
console automatically, or the option to
activate the serial console.You may include other options described in &man.boot.8; as
well.The options, except for , will be passed to
the boot loader (/boot/loader). The boot
loader will determine which of the internal video or the serial
port should become the console by examining the state of the
option alone. This means that if you specify
the option but not the
option in /boot.config, you can use the
serial port as the console only during the boot block; the boot
loader will use the internal video display as the console.Boot the machine.When you start your FreeBSD box, the boot blocks will echo the
contents of /boot.config to the console. For
example:/boot.config: -P
Keyboard: noThe second line appears only if you put in
/boot.config and indicates presence/absence
of the keyboard. These messages go to either serial or internal
console, or both, depending on the option in
/boot.config.OptionsMessage goes tononeinternal consoleserial consoleserial and internal consolesserial and internal consoles, keyboard presentinternal console, keyboard absentserial consoleAfter the above messages, there will be a small pause before
the boot blocks continue loading the boot loader and before any
further messages printed to the console. Under normal
circumstances, you do not need to interrupt the boot blocks, but
you may want to do so in order to make sure things are set up
correctly.Hit any key, other than Enter, at the console to
interrupt the boot process. The boot blocks will then prompt you
for further action. You should now see something like:>> FreeBSD/i386 BOOT
Default: 0:wd(0,a)/boot/loader
boot:Verify the above message appears on either the serial or
internal console or both, according to the options you put in
/boot.config. If the message appears in the
correct console, hit Enter to continue the boot
process.If you want the serial console but you do not see the prompt
on the serial terminal, something is wrong with your settings. In
the meantime, you enter and hit Enter/Return
(if possible) to tell the boot block (and then the boot loader and
the kernel) to choose the serial port for the console. Once the
system is up, go back and check what went wrong.After the boot loader is loaded and you are in the third stage of
the boot process you can still switch between the internal console and
the serial console by setting appropriate environment variables in the
boot loader. See .SummaryHere is the summary of various settings discussed in this section
and the console eventually selected.Case 1: You Set the flags to 0x10 for
sio0device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4Options in /boot.configConsole during boot blocksConsole during boot loaderConsole in kernelnothinginternalinternalinternalserialserialserialserial and internalinternalinternalserial and internalserialserial, keyboard presentinternalinternalinternal, keyboard absentserial and internalserialserialCase 2: You Set the flags to 0x30 for sio0device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4Options in /boot.configConsole during boot blocksConsole during boot loaderConsole in kernelnothinginternalinternalserialserialserialserialserial and internalinternalserialserial and internalserialserial, keyboard presentinternalinternalserial, keyboard absentserial and internalserialserialTips for the Serial ConsoleSetting a Faster Serial Port SpeedBy default, the serial port settings are: 9600 baud, 8
bits, no parity, and 1 stop bit. If you wish to change the speed, you
need to recompile at least the boot blocks. Add the following line
to /etc/make.conf and compile new boot
blocks:BOOT_COMCONSOLE_SPEED=19200If the serial console is configured in some other way than by
booting with , or if the serial console used by
the kernel is different from the one used by the boot blocks, then
you must also add the following option to the kernel configuration
file and compile a new kernel:options CONSPEED=19200Using Serial Port Other Than sio0 for
the ConsoleUsing a port other than sio0 as the
console requires some recompiling. If you want to use another
serial port for whatever reasons, recompile the boot blocks, the
boot loader and the kernel as follows.Get the kernel source. (See )Edit /etc/make.conf and set
BOOT_COMCONSOLE_PORT to the address of the
port you want to use (0x3F8, 0x2F8, 0x3E8 or 0x2E8). Only
sio0 through
sio3 (COM1
through COM4) can be used; multiport
serial cards will not work. No interrupt setting is
needed.Create a custom kernel configuration file and add
appropriate flags for the serial port you want to use. For
example, if you want to make sio1
(COM2) the console:device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3ordevice sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3The console flags for the other serial ports should not be
set.Recompile and install the boot blocks and the boot loader:&prompt.root; cd /sys/boot
&prompt.root; make
&prompt.root; make installRebuild and install the kernel.Write the boot blocks to the boot disk with
&man.disklabel.8; and boot from the new kernel.Entering the DDB Debugger from the Serial LineIf you wish to drop into the kernel debugger from the serial
console (useful for remote diagnostics, but also dangerous if you
generate a spurious BREAK on the serial port!) then you should
compile your kernel with the following options:options BREAK_TO_DEBUGGER
options DDBGetting a Login Prompt on the Serial ConsoleWhile this is not required, you may wish to get a
login prompt over the serial line, now that you
can see boot messages and can enter the kernel debugging session
through the serial console. Here is how to do it.Open the file /etc/ttys with an editor
and locate the lines:ttyd0 "/usr/libexec/getty std.9600" unknown off secure
ttyd1 "/usr/libexec/getty std.9600" unknown off secure
ttyd2 "/usr/libexec/getty std.9600" unknown off secure
ttyd3 "/usr/libexec/getty std.9600" unknown off securettyd0 through ttyd3
corresponds to COM1 through
COM4. Change off to
on for the desired port. If you have changed the
speed of the serial port, you need to change
std.9600 to match the current setting, e.g.
std.19200.You may also want to change the terminal type from
unknown to the actual type of your serial
terminal.After editing the file, you must kill -HUP 1
to make this change take effect.Changing Console from the Boot LoaderPrevious sections described how to set up the serial console by
tweaking the boot block. This section shows that you can specify the
console by entering some commands and environment variables in the
boot loader. As the boot loader is invoked at the third stage of the
boot process, after the boot block, the settings in the boot loader
will override the settings in the boot block.Setting up the Serial ConsoleYou can easily specify the boot loader and the kernel to use the
serial console by writing just one line in
/boot/loader.rc:set console=comconsoleThis will take effect regardless of the settings in the boot
block discussed in the previous section.You had better put the above line as the first line of
/boot/loader.rc so as to see boot messages on
the serial console as early as possible.Likewise, you can specify the internal console as:set console=vidconsoleIf you do not set the boot loader environment variable
console, the boot loader, and subsequently the
kernel, will use whichever console indicated by the
option in the boot block.In versions 3.2 or later, you may specify the console in
/boot/loader.conf.local or
/boot/loader.conf, rather than in
/boot/loader.rc. In this method your
/boot/loader.rc should look like:include /boot/loader.4th
startThen, create /boot/loader.conf.local and
put the following line there.console=comconsoleorconsole=vidconsoleSee &man.loader.conf.5; for more information.At the moment, the boot loader has no option equivalent to the
option in the boot block, and there is no
provision to automatically select the internal console and the
serial console based on the presence of the keyboard.Using Serial Port Other than sio0 for
the ConsoleYou need to recompile the boot loader to use a serial port other
than sio0 for the serial console. Follow the
procedure described in .CaveatsThe idea here is to allow people to set up dedicated servers that
require no graphics hardware or attached keyboards. Unfortunately,
while most systems will let you boot without a keyboard, there
are quite a few that will not let you boot without a graphics adapter.
Machines with AMI BIOSes can be configured to boot with no graphics
adapter installed simply by changing the `graphics adapter' setting in
the CMOS configuration to `Not installed.'However, many machines do not support this option and will refuse
to boot if you have no display hardware in the system. With these
machines, you will have to leave some kind of graphics card plugged in,
(even if it is just a junky mono board) although you will not have to
attach a monitor into it. You might also try installing an AMI
BIOS.