This is paper 2 of 4 of my server series. The first paper Server FreeBSD Part 1 - Services and Updating talked about basic updates of your system. Now we get a little more complex in a leadup twords the final paper. Thanks bork for letting me post this here. Also please excuse my grammer. My English is not too good.
The topics we will be covering are in today's paper are:
2. System Tuning
2.1. sysctl
2.1.1. securelevel and chflags
2.1.2. performance
2.2. User management
2.2.1. adduser / rmuser / chpass / watch
2.2.2. Quotas and login.conf
2.2.3. Jail
2.3. File integrity
2. System Tuning
Now that our system is like new and one cannot update anything any more, it is time to start on some basic security and system policys. For that we initially will see what we can do by defect with the basic system in order to increase the safety of our system and to limit exposure to attacks.
2.1. sysctl
Sysctl is an extremely practical tool within FreeBSD since it will allow us of verify or to handle the state of the kernel. Information is stored and posted through a Management Information Base or MIB according to the same model as SNMP For example to post a list of the various variables of state kernel, it is enough for you to carry out simple
($:~)=> sysctl -a
same manner that you would use a ls. Note: that you can limit the entry of the MIB if you just know it after the option in order to post only it. According to the principle of the MIB, you can reduce posting by limit a field of the MIB For example to post all the entries in connection with IP
($:~)=> sysctl net.inet.ip.*
Also note that certain variables are not modifiable and that certain entries of the MIB are in the form of tables used on the occasion by PS, netsat or systat. Finally to obtain a list of the variables sysctl which you can modify, consult the page of handbook of sysctl.
2.1.1. securelevel and chflags
One of the functionalities of FreeBSD consists of the establishment of secure level within the system. There are thus 5 levels of security within FreeBSD which cannot be decreased without starting again init. They can however be increased by a process root via the MIB sysctl, and this same in the course of execution.
To define the securelevel set up by init, modify the following lines in rc.conf:
N represents the entirety here corresponding to the one of the 5 possible entrys. Replace it by the level which is appropriate to you. Then if you wish to raise it once your system initialized, modify the following entry sysctl:
($:~)=> sysctl -w kern.securelevel=N
In addition to limitations registered in the code kernel, therefore unchangeable, suitable for each one of them, each level also defines the possible operations on files flags, attributes of files making it possible to improve the safety provided by the traditional UNIX permissions. Below, 5 levels and their limitations:
-1 which founds the insecure mode (0) in a permanent way. It is the default value.
0 indicate the insecure mode in which the files flags ' immutable' and ' system suspend only' can be withdrawn and where one can carry out operations of read/write on all. with for only restriction the already founded rights, for example, in the fstab.
1 indicates we are in secure mode in which the flags ' system immutable' and ' system suspend only' cannot be decontaminated. The access to /dev/mem and /dev/kmem is interdict in writing and the KLD cannot any more be charged or discharged.
2 founds the highly secure mode which is strictly the same one as the secure mode with the difference close as the only operations from now on carried out on the discs are the assembly and demote changes.
3 means the introduction of the network secure mode which is similar to the preceding level with in more impossibility of modifying the rules ipfw or the configuration of the traffic shaper based on ipfw dummynet.
For a workstation, the use becomes problematic as of the securelevel 1. For example, XFree86 can require the access to /dev/mem whereas that is prohibited to him. The following levels are adapted to waiters, and the last is more particularly intended for a footbridge. Note the level 2, very restrictive, which forces the access of the discs in read-only. This level, even a waiter is likely to be seen disturbed by the securelevel, even more if it requires compilations or regular modifications of configuration. Note that the level protects very well from the majority of the backdoors based on modules kernel. It could however be judiciously to replace or add the option kernel NO_LKM.
To parameterize the files flags on your files according to these levels, you will have to use the order chflags. The flags available are listed here after.
arch, only usable by root, transforms the archival file.
opaque, makes the file "opaque" to certain reading (useful against the reading by other applications) and modifiable only by the owner or the root.
nodump, makes it possible to prohibit a backup file via the utility dump. Modifiable only by the owner or the root.
sappnd, founds the flag system suspends-only only modifiable by the root in securelevel higher than 0. Suspends means that one can only add data and not to withdraw some.
schg place the flag system immutable which, as its name indicates it, is supposed to prevent any event. Modifiable by the root only in level 0.
sunlnk makes it possible to prohibit the removal of a file, knowing that this option can only by the root
uappnd, uchg and uunlnk are during respective of sappnd, schg and sunlnk. The difference lies in the fact that, in addition to the root, the owner of the file also has the right to modify the files flags.
Note that by carrying out a man chflags, you will discover the few options - in particular recursivity - what proposes this order. To withdraw a file flag they are the same options with the prefix No such as nosappnd. The files flags are interessants to be placed on certain precise sensitive files or then straightforwardly on a repertory of which you wish ensure of the integrity and who will be seldom modified. In the example, R and H make it possible to follow the bonds symbolic systems and this recursivement, the order being applied to whole repertories the binary ones.
Last detail which does not have great a deal to see with sysctl but which imports much in the management of the rights and the files. You have the leisure to modify the fstab in order to assemble your various partitions with certain options. Under FreeBSD, instead of creating only one single partition root /, the system creates simultaneously a partition /usr and /var. You can define in your fstab for the whole of your filing systems:
-rights of writing with the option rw for read-Write, or ro for read-only.
-rights of execution with the option noexec.
-privileges granted with the option nosuid.
We limit here the execution in /var in order to prevent that an intruder tries to place the binary ones there and we limit the presence of binary suid or devices in the other major repertories.
Note in the passing which the software updates that we set up in our configuration kernel do not activate via the fstab but thanks to the utility tunefs which modifies directly, and in manner persistent, the heading of the filing system. For activating these software updates indeed, follow the following line:
Then replace enable by sayable decontaminating this option.
2.1.3. Performance
Sysctl can also bring an invaluable help in the configuration system and network to us at ends of high performances. It thus will enable us to activate certain capacities network which supports perfectly the pile TCP/IP the BSD - which is that known as while certainly passing most stable, most powerful and most standard of the piles TCP/IP - but which are not activated by defect.
The first interesting entry is the option log_in_vain which goes logger through a simple entry in the file of corresponding log of syslogd, any attempt at access to a service even if no service is with listening on the port of the attempt at access. This can allow us in a secured environment, combined preference with a tool for analysis of log such as logcheck or ASAX, report of the attempts at network mapping even if we have a minimum of services available and who more is a firewall. However I will point out 2 difficulties: first of all log_in_vain logist actually only packages with flags SYN, which is not enough for really detecting a scan. And in addition, in a "hot" environment like a machine being used as footbridge or a waiter within a DMZ, the use of log_in_vain can capture a quantity of log enough impressionante and able to occupy an analyst or an administrator without tools for analysis during weeks. But within a network of out and already secured or on a critical machine, this capacity of log can be interesting. To activate it, it is enough for you to seize
The following easy ways are interesting if your machine must be used as footbridge, of filter or load to balance for other machines. The following order makes it possible to you to activate forwarding IP and thus to transform our machine into gateway what will prove to be useful for the division of connection or the deployment of a jail. You can associate the entry fastforwarding to him which activates a system of mask of the roads leading to external addresses with the local area network. The interest is to circumvent in this manner the inspection by layer IP to obtain a direct passage of the screens between levels 2 of the interfaces of the footbridge. In the case of a end host, activate check_interface rather than forwarding in order to check that the packages arriving on an interface has an address IP corresponding to the interface.
The following entries are particularly useful within the framework of a waiter which necessity a high availability or a great reliability. Indeed, we will bring to our machine the support extensions TCP for high performances. These extensions are decries in the RFC 1323 that I recommend to you to study. They consist of 3 extensions. The first is the field Window Scale which is a factor applied to the field Window Size and useful on the Broad Conceited person Network (LFN) in order to optimize the data flow on these large reseaux and to bring a better control by multiplying Window Size. We find then 2 options extremely useful in the case of use of load balancing by providing information to the algorithms of distribution of load. The Round-Trip Time Measurement (RTTM) and Protection Against Wrapper Sequence Numbers (PAWS) base all the 2 on the addition of an option of timestamp to segments TCP With simple checks of timestamp one can thus calculate time to go return between 2 ACK and thus to optimize flow or to modify the road. One can also prevent hijacking, overlapping and especially of the rejeu by carrying out a double checking on the number of sequence and the timestamp. These options come to be added following algorithms NewReno, evolution of the Reno pile, making it possible to detect and to correct a congestion in the network while exploiting the loss of packages, the times and the sizes of window TCP single the bemol is that these options function of course only between machines supporting them all the 2 in a similar way, but they do not seem to be very much used - note that the branch 4.x supports the RFC 1323 per defect since the release 4.4 - and finally you could risk disagreements vis-a-vis some firewalls or plugins of standardization of traffic if they do not recognize these options. However we decide to approach it in this article in order to facilitate its diffusion and let us apply we it to our system by asset of conscience! You will find then an entry recent which forces FreeBSD to calculate, for each connection TCP, the quantity of data in the course of transmission in the network (starting from the product delay*bw), in order to limit the sending of capable packages to involve a no relevant overload of the routers and/or switch's present on the road. This configuration then brings closer the behavior FreeBSD of the continuation of algorithms TCP Vegas. We have then as to increase the sizes owing to lack of our buffers of sending and reception (as well for TCP as for UDP), which have a direct influence on field TCP window size. Because of possible influence of these values on the time, it is recommended to try out several values, while following for example the rule wnd = bw/8 * RTT For example, we voluntarily limited the size of the buffers for UDP which does not have a mechanism of detection and avoidance of congestion and is thus more sensitive there. We also allotted values different to the buffers from sending and reception for TCP, the speed of download being often higher than that of upload (think of the lines xDSL). To finish, the two last entries sysctl indicate not to generate packages with the option road source, nor of the accepters, this option IP facilitating the spoofing already evoked while making reassemble strictly packages IP by the way used with the outward journey.
For all that, it is enough for you to carry out the following orders:
Then, we activate the implementation of the RFC 1948 applying the recommendation of Steve Bellovin to the random generation of ISN according to the equation ISN = M + F(localhost, localport, remotehost, remoteport) where M is a timestamp. However, the safety of this recommendation rests primarily on the randomness of the secret key and the power of the algorithm of hashage. Indeed, the study of Michal Zalewski (http://razor.bindview.com/publish/papers/tcpseq.html), concerning the use of attractile strange at ends of construction of spoofing sets answering the problem of prediction of ISN TCP in a blind way, showed that with the freedom left by the recommendation only generate a secret key only with starting and with the re-use of the IPv4 addresses, it is possible for a waiter with length uptime that an attacker can create attractile strange enough broad to be ensured of a good rate of success by using same IP address source. In spite of the absence of mathematical demonstrations for this study, we activate the regeneration of secrecy with a 3600 seconds interval. Will know that the phase of regeneration breaks the mechanisms of recycling TIME_WAIT, allowing to purge before 240 second lawful connections TCP in the course of closing (state TIME_WAIT), thus allocating resources a little longer. On a purely personal basis I also wonder which manner project CBOSS reconciled the integration of the syncookies in FreeBSD starting from the release 4.5 with the respect of the RFC 1948. We point out finally the various entries relating to the mechanisms of syncookies and syncache strongly limiting the risks related to the SYN flood while improving normal operation.
We decide to us proteger face now has certain attempts at Back as well as various techniques of network mapping. Using the following lines, you will be able thus in particular to modify the value of TTL per defect, which can be used to identify OS, or to prohibit the answers to the driving ICMP mask reply with a possible cartography network, but also to the ICMP broadcast, very often source of smurf or Back by amplification, and to put the maximum limit of packages ICMP in response to 200 a second. For TCP, we activate the delayed acknowledgments, restreingnant the slope of the system to send ACK for each received segment. This makes it possible to avoid Silly Window Syndrome (SWS) which tends to reduce the window size and thus to ensure a better effectiveness (see RFC 813, 896 and 2581). We also activate the keepalive one, segments TCP allowing checking if a transmission TCP always really active and is not preserved in an artificial state (following a SYN flood or Naptha, for example). Then activation comes from the blackholes consisting in preventing your system from being scanned while not answering neither by a RST for TCP nor by an ICMP port unreachable for UDP the packages sent on a closed port and thus to transform your system into "black hole". The last line is applicable only on the final hosts since it induces the checking on each arrival of packages that its TO address corresponds at an address of the interface of reception.
Always in protections against the Backs but this time side resources rather than network. The following entries of the MIB go initially permettrent us to limit the number of processes per user and the files number (including file descriptor and IPC) which it can open. We increase also the size of the tail of connections of par with the maximum number of sockets (2 times the maximum of connection roughly). Just as the size maximum of the buffers for sockets (empirically 8 times size of { recv, send}space). Lastly, we also increase the maximum number of files. All these values appear high, but they are actually used only for the resource allocation.
In addition we also have some easy ways in order to avoid the attempts at mask poisoning by accelerating the time of cooling of the table of routing and table ARP.
The first entry makes it possible to improve the treatment in particular on broad volumes of files. It relates to the UNIX files which will be hidden in the buffer hides rather than directly on the disc exploiting thus fully the virtual memory FreeBSD in addition already very powerful. Then we decide to activate the savecore application which makes it possible to preserve a trace of the core dump associated a kernel with an aim of study after a crash for example in order to in determiner the causes. Lastly, we make so that the users see only their own processes and that only the root can see the unit.
Note that we also have some configurable functionality by means of the loader. If you have a disc IDE, the following order allows of active the mask in writing
($:~)=> loader set hw.ata.wc=1
If you have discs IBM DPTA or DTLA, you can use in the place the entry hw.ata.tags but with your risks and dangers since it is still experimental. These modifications must be reflected on/boot/loader.conf. Same manner, the options sysctl which will want to find with each demarrage must be in the file/etc/sysctl.conf in the form ' entrée=parametre '.
In a system with multi users, each local or distant user must have a personal use allowing to converse the environment of each one in the state desire as well as a clearer management of the activity of the system. In margin of the traditional accounts user we strongly recommend creer to you several accounts known as ' systeme' intend has executer with a minimum of risk of compromising or exploitation of compromised account, the significant services network which you will desirez to set up. Among more interessant on which to apply this practice, one finds waiters DNS, the Web servers or waiters smtp and pop3/imap4. Note also the presence of the account nobody corresponding has the user system no privileged credits, but the more there are services which use nobody, the more this account acquires privileges.
Note that the multiple chapters on sysctl, the configuration kernel, the management of the users or the installation of a jail, we think of being able to exempt to us of an additional chapter on the basic orders which are chroot, chmod and chown accompanied by a fast explanation on the privileges. Thus do not seek information on these orders in our columns.
Note in addition that the use of the account root gold of the operations limitees of maintenance is strongly deconseille for reasons of safety. Each handling of the root can entrainer of the significant consequences for the integrite of the system or if the account is compromised, then all the machine passes under control of the intruder. In short, it is preferable to also constitute an account user pertaining him to the group wheel and having the capacity of executer orders in root by sudo which enables us to remain under an account user and to carry out specific operations necessitant of the rights root or to intervene in on other accounts if need be. For example we can publish the index of our Web server on the account www system by using the option - U which makes it possible to specify the user of which one wishes to endorse the rights
($:~)=> sudo -u eberkut vi ~eberkut/CNS/FreeBSD.txt
Of course this freedom of handling can be dangerous this is why we have need to publish and configure/etc/sudoers in order to limit the accesses. The scheme of/etc/sudoers is as follows: you can define alias for one or more users, or one or more orders then you define the authorizations according to diagram WHO WHERE=WHAT.
# directives
root ALL = (ALL) ALL
FULLTIMERS ALL = NOPASSWD: DEBUG, KILL, SHELLS, RIGHTS, USER, NET, DAEMON
PARTTIMERS ALL = DEBUG, NET, (OP) NOPASSWD: DAEMON
ALL ALL = NOPASSWD: CDROM
Sudo is based on timestamp between the differences orders entered to ensure a minimum of security while placing a timeout. For updater your timestamp without executer of orders, you can type sudo - v and to kill it definitively, sudo - K.
2.2.1. adduser / rmuser / chpass / watch
adduser is a tool extremement useful which enables us to add new users in a very simple way. It allows in an operation of gerer the necessary whole of actions A the creation of a new account user. A simple order carries out a configuration not does not have an account this including the creation of the entrees necessary in/etc/passwd and/etc/group, the creation of the repertoire of the user and the copy of the files required by defect until A a notification of welcome.
We owe creer first of all the file of configuration adduser by
($:~)=> adduser -s -config_create
Then we lancons the creation of the user.
($:~)=> adduser -v
Use option ``-silent'' if you don't want to see all warnings and questions.
Check /etc/shells
Check /etc/master.passwd
Check /etc/group
Enter your default shell: csh date no sh tcsh zsh [sh]: sh
Your default shell is: sh -> /usr/local/bin/sh
Enter your default HOME partition: [/home]:
Copy dotfiles from: /usr/share/skel no [/usr/share/skel]:
Send message from file: /etc/adduser.message no
[/etc/adduser.message]: no
Do not send message
Use passwords (y/n) [y]: y
Write your changes to /etc/adduser.conf? (y/n) [n]: y
Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any
input.
Enter username [a-z0-9_-]: eberkut
Enter full name []: eberkut
Enter shell csh date no sh tcsh zsh [zsh]:
Enter home directory (full path) [/home/eberkut]:
Uid [1000]:
Enter login class []: root
Login group wheel [wheel]:
Login group is ``eberkut''. Invite eberkut into other groups: guest no
[no]:
Enter password []:
Enter password again []:
Name: eberkut
Password: ********
Fullname: eberkut
Uid: 1000
Gid: 1000
Class: root
Groups: wheel
HOME: /home/eberkut
Shell: /usr/local/bin/zsh
OK? (y/n) [y]: y
Added user ``eberkut''
Copy files from /usr/share/skel to /home/eberkut
Add another user? (y/n) [y]: n
Goodbye!
Note that you can easily notice that we use add here to use for the premiere time since we needed creer the file of configuration then adduser has request to us his default values. Moreover for more simplicity we were in verbose mode (- v). In the future you will not have that information of the user has to enter and you will be able to carry out this operation in mode silent (- S).
Adduser possede a program brother, rmuser, which will allow us symmetric manner has adduser, to remove in only one operation a user and all dependences that that supposes. Rmuser carries out thus the suppression of the entree user in the file of passwords, sound repertoire (in/home), of its mail on standby (in/var/mail), of its temporary files (in/tmp), and its entree in/etc/group even the suppression of the group if it becomes empty. But rmuser also erases the entrees of the user in the crontab or kill all the processes in progress pertaining has the user in question.
($:~)=> rmuser eberkut
Matching password entry:
eberkut:*:1000:1000::0:0:eberkut:/home/eberkut:/usr/local/bin/zsh
Is this the entry you wish to remove? y
Remove user's home directory (/home/eberkut)? y
Updating password file, updating databases, done.
Updating group file: trusted done.
Removing user's incoming mail file /var/mail/jru: done.
Removing files belonging to eberkut from /tmp: done.
Removing files belonging to eberkut from /var/tmp: done.
Removing files belonging to eberkut from /var/tmp/vi.recover: done.
Lastly, chpass is another marvelous tool moreover enabling us to facilitate management user largely. He makes it possible to modify basic information of a user such as his password, his Shell or of more personal information. Only the root and the user he can modify information with chpass. Chpass functions in the same way as edquota, it be-A-statement which it will open an editor making it possible to modify our configuration.
($:~)=> chpass eberkut
($:~)=>Changing user database information for eberkut.
Login: eberkut
Password: ********
Uid [#]: 1000
Gid [# or name]: 1000
Change [month day year]:
Expire [month day year]:
Class:
Home directory: /home/eberkut
Shell: /usr/local/bin/zsh
Full Name: eberkut
Office Location:
Office Phone:
Home Phone:
Other information:
When you wish to set up a service, in addition to making it function in stand alone like explaining previously, and if it requires certain rights, then to assign a specific user to him can allow to limit partially with additional mechanisms like jail or chroot the damage caused by an intrusion via this service. This remark is true also for BIND which with the good options remains root only a few moments or for Apache which turns in nobody - and its scripts also what can give vulnerabilities in the event of misconfiguration.
Lastly, when a user comes to loguer and that you noticed his share an illegitimate or intrusive behavior, the options for the snoop device which we placed at the time of the configuration kernel will enable us to take position in order to observe and to even write on the tty of a user. For that we will use the tool watch. We create initially the periphériques ones
Then we can launch watch. Before that we check the active users on the system in order to specify the tty device to be supervised. We place the option T to obtain a timestamp at the beginning of the observation, N to prevent the user from changing attached tty and the option W to allow to write within the supervised tty.
($:~)=> who
($:~)=> watch -tnW ttyp1
2.2.2. quotas and limits
The quotas are an option of FreeBSD which allowing you to limit the quantity of disk space or the number of files to which the right a user or all the users of the same group has, on a filing system given. In a system with multi users with accesses distant, this method prevents that only one user does not consume all the disk space.
The quotas having to be active manually within the file of configuration of the kernel and thus necessitant a recompiling, we have recommends to you of verifier the presence of the option quotas like several others to the beginning of this text. Once this stage passee, you must activate once more the quotas manually this time within the file/etc/rc.conf. For that let us publish we it and let us add the line to it
enable_quotas="YES"
For an increased control, you also have a second option but which will launch a program - quotacheck - which can slow down the demarrage of your machine considerably. However safety preceding, we recommend to you to publish the line
check_quotas="YES"
You must finally publish the file/etc/fstab to bring into service the quotas filing system per filing system. It is there that you say if you want quotas of use of the discs by user, group or both, for each filing system.
To bring into service quotas by user, add the option userquota to the zone of options of the entry of/etc/fstab for the filing system on which you want quotas. For example:
/dev/ad0s1c /home ufs rw,nosuid,userquota 2 2
For quotas by user one uses userquota and for quotas by groups, one will use groupquota. To apply quotas at the same time has the user and with his group, one will combine the 2 orders precedents as we did for our file. It does not remain you any more but with redemarrer in order to activate the taking into account of quota and the generation of the files/etc/quota.user and/etc/quota/group.
The quotas can be founded on a system according to several criteria. First of all in addition to being able to apply quotas by user and/or groups, you have the possibility of applying these limitations according to various formats either in terms of disk space, the blocks, or in term of files, the inodes. In addition, it is necessary to add degrees in the limitations: strict or flexible. The first follow the rules of quotas to the letter, but when a user reaches his quota, it can nothing any more add. The second degree of limitation offers to the user a time - valid during one week per defect - allowing him making it possible not not to be suddenly limited in its work by a too strict quota and to add or (especially) to withdraw files during this time. However if it did not return on a normal level once the run out time, the limitation becomes strict and it can nothing any more add until A what it goes down again below its limitations.
To publish our quotas, we will use the order edquota which will open an editor (VI per defect):
($:~)=> edquota
Quotas for user eberkut:
/usr/home/eberkut: blocks in use: 0, limits (soft = 80, hard = 100)
inodes in use: 0, limits (soft = 40, hard = 60)
/usr/var: blocks in use: 0, limits (soft = 80, hard = 90)
inodes in use: 0, limits (soft = 60, hard = 80)
To be simplified the attribution of quotas, one can apply a prototype quota to a beach of uid by the intermediaire of the option - p of edquota once the quotas definis a premiere time
($:~)=> edquota -p eberkut 1000-10000
The order quota can be utilize in order to know the quotas and the use of the disk space of a user and/or a group. As for the majority of the other orders relating to the user newses, only the root can go to consult the quotas of all accounts and all groups.
($:~)=> quota -u eberkut
Finally "last goal not least", FreeBSD has a file called login.conf which enables us to define certain capacities and especially operational limit of resources. The classes of login.conf are generally divided into 3 types which must arise in a form similar to the entries sysctl, i.e. nom=valor which can always be in seconds for time and B, KB, mb, GB, Tb for the size. Note also some Boolean:
O limits of resources
- cputime in seconds to limit time CPU (not percentage). Option - T of limits
- filesize to limit the size maximum of a file (overwrity by the quotas). Option - F of limits
- datasize, stacksize and coredumpsize on the same diagram for the data, the stack or the files of coredump. Options - D, - S and - C of limits
- operational limits of memory memoryuse, memorylocked. Options - m and - L
- a maximum number of processes maxproc. Option - U of limits
- a number of files opened by process openfiles. Option - N of limits
- sbzise for the size maximum of the socketbuffer. Option - B of limits
O of the variables of environment
- Lang, to specify $LANG, the variable of language
- manpath, for the access path by defect to the manpages
- nologin is the access path to your file nologin posted right before finishing a session
- requirehome, true or false, make it possible to requerir a repertory home validates for loguer
- setenv, makes it possible to specify a list of variables of environment separated by commas
- Shell, makes it possible to specify Shell to carry out in the place that to specify in the file passwd
- term, determines the type of terminal
- umask specifies the value of the mask of creation of file (ex: 022 = 755)
- welcome definite the file containing the welcome message
O the variables of authentification
- minpasswordlen definite the minimal length of a password
- passwd_format specifies the format of encryption for the passwords (of or md5)
- mixpasswordcase force the user to use capital letters or figures in its password
- times.allow and times.deny make it possible to specify a list of schedules during which the logins are authorized or prohibited
- ttys.allow and ttys.deny make it possible to specify a list of tty usable by this class
- passwd_format allows to specify the algorithm used for the storage of the password. By defect this field is with ' des' which is relatively weak. You can put it at ' md5 ' and more recently at ' blf' to use Blowfish.
O limiting of accounts
- accounted, activates the accounting for the users of this class
- daytime definite the maximum time of login per day - expireperiod, makes it possible to determine a limit of expiry on behalf of the class then graceexpire makes it possible to leave a deferment just as gracetime for times of login
- host.accounted and host.exempt makes it possible to list the hosts since which the accounting is or not activated. In the same way for ttys.accounted and ttys.exempt for the tty
- idletime, definite the time of inactivity before an automatic logout
- passwordtime makes it possible to define a limit of expiry for the passwords
- sessiontime specifies the maximum time allocated by session - sessionlimit specifies the maximum number of concurrent sessions
- warnexpire, warnpassword and warntime make it possible to define one moment to warn the user before expiry of the account, the password or the time of login allocated
# the field Tc enables us to return a user or a group to a definite class
#. You can overwriter of the limits of default by adding them with
# new classifies. Adduser enables you to add a user to a class.
We can use the order limits here in order to adjust these limits of resources for a class of user class_login defined in login.conf
($:~)=> limits -e -C classe_login -B -m 20m
To apply your capabilities login.conf, we use cap_mkdb.
($:~)=> cap_mkdb /etc/login.conf
2.2.3. jail
Jail is a very powerful mechanism which, as its name indicates it, makes it possible to refine the privileges and the management of the users according to a principle, similar to chroot, of imprisonment of the processes. Jail goes however much further since it proposes the reproduction of a complete environment inside an environment relative. The function jail() is based on a reinforced version of chroot().
To build a jail can prove very useful to confine a user or service to which one makes no confidence or which is likely to threaten the integrity and the stability of the system. For that jail offers completely operational virtual a FreeBSD environment with its own files of configuration or management of the users, the whole attached to alias a IP Moreover, one process once in the jail is as behind an ice without dye, it evolves/moves freely but cannot see beyond its environment while the host of the jail can all observe and supervise. Thus, a process in the jail cannot leave there, and you can delegate accounts root within each jail. On the assumption of an attack, the intruder will obtain for example initially a local access by a distant exploit, then an access root by a local exploit but would be seen confining with its jail (theoretically, jail being based on chroot(), nothing are sure).
Jail is posed here in precursor of the more recent concept of honeypot, and can be used very well like such to encourage and supervise intrusions with a limited risk of total compromising of the machine, while preserving logs and information at the shelter. To preserve its integrity, jail restraint possible actions compared to a complete environment. It is thus prohibited to modify the kernel (which remains single for the whole of the system) and to charge of the modules kernel, to modify the configuration network, to assemble filing systems, to create devices, to use raw sockets, to modify the MIB sysctl or the securelevels. All that is not directly related to the operation of the jail is prohibited. We can however use as usual privileged ports, modifiers the permissions of the files and users inside the jail, etc in order to really cloner a traditional environment.
The effective installation of a jail is carried out using the following sequence of orders:
($:~)=> ifconfig fxp0 alias $jail_IP_alias netmask 255.255.255.0
($:~)=> mkdir -p /jail/jailone
($:~)=> cd /usr/src
($:~)=> export JONE=/jail/jailone
($:~)=> make world DESTDIR=$JONE
($:~)=> cd /etc
($:~)=> make distribution DESTDIR=$JONE NO_MAKEDEV=yes
($:~)=> cd $JONE/dev
($:~)=> ./MAKEDEV jail
($:~)=> ln -sf null /boot/kernel/
($:~)=> touch ../etc/fstab
We allot an address alias IP to our jail then we create the repertory/jail/jailone in which will be to confine our virtual environment. The order make then makes it possible to build a complete system with for destination the jailone, including binary, files of configuration and tree structure of the devices. Note at the end the bond symbolic system towards the kernel, as well as the creation of an fstab vacuum to ensure itself of the correct operation of certain programs.
The jails are not yet persistent, it is thus necessary to configure your rc.conf principal to preserve the configuration ifconfig at each reboot:
If you envisage using cron or syslog, we recommend to you to entirely recreate your file of configuration by adapting the entries to the jail.
For the use of cron, we recommend to you to entirely recreate your file of configuration with your own entries. In addition all the files copied are it after complete configuration of the environment host, which means that these files were chmoded, thus think of making in the same way with crontab, httpd.conf and named.conf
By using adduser and chpass as sight previously, we do not have any more but to change the password root of the jail, then to create a user by service which we wish to confine. We will take as named example and httpd. If you wish to authorize the access to your jail with preexistent users, it you will be supposed to copy spwd.db. For that we will recopy only information which interests us:
For a securisation of the system, in margin of file of configuration useful that we already copied, you can use the functionalities of chmod, or even the chflags, to modify the permissions on the confined correspondents of the repertories/bin,/sbin,/usr/lib,/usr/share/lib in order to avoid any modification or compromising.
We can also add with the sysctl.conf environment host certain variables concerning the jails. Note that now that we set up a jail, we will referring ourselves with the jail like the environment jail and the normal machine as with the environment host. The following entries sysctl make it possible to decide if the jail has the right to change its own domain name, to use IPC standards System V for the communication inter process enabling him to communicate and thus to deteriorate processes apart from the jail, and finally to limit or not the access to more types socket and not subjected to the restrictions jail:
If you wish to configure a significant number of jail, as it will be the case if you to confine each service or site lodged indépendemment, for at the same time more safety and also to limit the size occupied by the jail, you can use pseudo-devices vn exploiting the driver vnode which makes it possible to treat a file like a device. When you decided maximum size by jail, use ' truncate' to create a file of this size (here 1 Go):
($:~)=> truncate 1G jailfile
Then, for mounter these files like partitions on which to install your jail, use ' vnconfig' to transform the preceding file into a device (here vn0c). If no file is specified, vnconfig will use the swap to create the device. You will be able then to specify the size with the option - S followed by the size (in KB, Mo, go and to), and to fill it of it of zeros with - T, thus supplanting the use of truncate:
($:~)=> vnconfig -e vn0c jailfile
or, to remove the recourse to truncate:
($:~)=> vnconfig -S 1g -T vn0c
You can then assemble it and dismount as usual. You will have to insert these new peripherals in vote fstab in order to assemble them to starting as a partition jail (peripheric a vn by jail). The interest is the great flexibility since you can easily increase or reduce the size of the file used to emulate quotas. For retransformer your device vn in file, carry out:
($:~)=> vnconfig -u /dev/vn0c
If you ridges to turn several services in your jails, it can happen that a fault of safety is discovered, requiring the patching of this service. Thanks to the virtualization of the jail, you could use NFS between this one and the environment host. There is however a simpler solution consisting in using mount_null which makes it possible to duplicate part of a filing system so that it is seen by a different way. As patcher and recompiler require the access to/usr/src, you preserve your safety while assembling this way in read-only from the point of view of the jail.
($:~)=> mount_null -o ro /usr/src $JONE/usr/src
It does not remain you any more whereas to apply the patch and to recompiler normally your binary userland.
To note all the same that it is recommended to use the user named since whom bind - which will be placed a few moments with the rights root to recover the files descriptor before returning to more reasonable privileges - will be used. With BIND it is also strongly recommended to use a key of authentification TSIG between your waiters DNS, to limit the AXFR or transfer of zone to sure waiters DNS secondary or to modify the response to the request host - L chaos version.bind which can give to the attacker information on the version of BIND and thus possible remote possible buffer overflow.
If you use Apache as a httpd, do not forget to publish httpd.conf in order to specify as owner the www user in order not to have resorts to nobody which more it will be used, more it will gain drois. Also take care not to overload the system and, more particularly, not to reach too much facilemenent the number of maximum process per user (in such a case if the traffic is legitimate pass in root jail to adapt the parameter by sysctl).
If you are anxious of an unspecified dependence with chroot(), and seek more precise capacities of configuration, you can turn to the reimplementation partial of Robert Watson: jailNG. This one provides several improvements as regards the configuration and the management of the jail. It is enough for you to recover the patch on http://www.watson.org/~robert/jailng/ and to apply it in the following way:
($:~)=> cd /usr/src && patch -p1 < jailng.1.diff
It does not remain any more but with recompiler your kernel. The use is carried out then via ' jailctl' having 3 orders at the present time:
- ' jailctl create' or ' destroy' which takes in argument the name of the jail and makes it possible to create or remove a jail
- ' jailctl join fascinating in argument the name of the jail to be joined, the way to be confined with the option - C, and finally an order, such as the launching of Shell.
The rights of each jail could be to manage more finely thanks to entries sysctl specific, form jail.jail_name.entry_name, for each one of them. These new entries are as follows:
The jails can - or not - thus modify their hostname, the processes in their centre can use the IPC SysV, sockets INET, the sockets UNIX, the sockets road, any other type of socket, and finally you can parameterize address IP of the jail.
A small remark but of weight after this encensement: the jailNG project is already old and nowhere does not show any more any sign of activity for a long time. The code is thus likely to cause many problems, and the new functionalities are long in coming, undoubtedly since Robert Watson, from now on member of the core TEAM, is with the head of the solid mass TrustedBSD project, aiming at the implementation of the standard POSIX.1e starting from FreeBSD 5.x, and one of the instigator of the project CBOSS which chapeaute several open developments source in the field of safety. FreeBSD 5.0 has all the same some thin improvements like the configuration of securelevel independent for each jail.
2.3. file integrity
The preceding chapter approaching a kind of system in the system, it leaves a little the logical path and step by step this article. Thus do not forget to take account of the following easy ways in the configuration of your environments jail in addition to vote environment host. We are interested here in the integrity of the files and in particular by the permissions and privileges granted within the framework of the use or the management of certain files.
A major danger of the safety of the files is represented by bits SUID. This bit placed on a file makes it possible to use it with the same rights as the owner of the file what can appear dangerous if the owner is the root. But first of all, we seek marked files SUID and SGID (similar to SUID but on a group scale) with find
($:~)=> find / -perm 02000 -o -perm 04000 print
We obtain a list of all the file or repertoires with bit SUID or SGID. Among all celà, there are executables that we do not want inevitably to leave with the range of no matter whom or although we do not intend to use. The selection to be carried out among file SUID is left with your discretion according to your use. However, it is strongly recommended not to leave Shell procedures in SUID especially pertaining to the root, this possibly being able to involve the illegitimate execution of orders.
To carry out our modifications, we use the utility chmod which enables us to modify the permissions allocated with a file. To calculate the modes which we wish to apply to such file, we base ourselves on the diagram of permissions according to:
4000 bit SUID (SetUserID one execution) about which we already spoke
2000 bit SGID (Set-Group-ID-one-execution) which we also approached
1000 sticky bit, under freebsd this functions only on the repertories and makes it possible to the user to remove or re-elect only the files of which they are owners
0400 allows the reading by owner
0200 allows the writing by owner
0100 allows the execution of a file by the owner and research within a repertoire
0040 allows the reading by the members of the group
0020 allows the writing by the members of the group
0010 allows the execution of a file by the members of the group and seeks it within a repertoire
0004 allows the reading by all other users 0002 allows the writing by all other users
0001 allows the execution of a file by all the other users and research within a repertory
When you make a ls, they are omnipresent the srwx-rwx-rwx. You will find more precise details on the permissions and the use of chmod by a man 1 chmod.
We can first of all decide to limit the modifications made to some of our files of configuration. We thus allow the reading and the writing by the owner, the reading by the group and any right to the remainder of the users
Note that we can combine these operations with something of more drastic if we have a rather high securelevel. Thus, if you seldom recompilez or update you can also apply the order chflags studied higher to the repertories and files of your choice by taking guard to the later problems in the event of compilation or of configuration. Also profit are error messages of chmod to check your bits SUID/SGID and the déselectionner on the binary sensitive ones.
We then will worry we about the integrity of our files and our system. For that we first of all will be used we as mtree. Mtree can be regarded as an inspector of integrity integrated system in the same style as ASSISTANCE or TripWire. It will enable us to generate a specification of our file system against which to compare our system regularly in order to detect possible illegitimate modifications. To generate our specification we enter the following order
The option S makes it possible to obtain a single checksum for all the files to which one applied the keyword ' cksum' and requires a figure in keyword (to be preserved at the shelter). The option K specifies a keyword to apply which will be stored in the specification and compared later knowing than by defect one has the keywords flags (for the files flags), gid (for the group), mode (for the permissions into octal), nlink (for the hardware link), size (for the size), link (for the bonds symbolic systems), time (for the last timestamp of modification), and uid (for the owner) to which we add cksum to obtain a checksum according to the diagram of the order cksum(1), sha1digest to obtain a signature using the agorithme with single direction Sha-1 to obtain the owner in the form of name. Then option X makes it possible not to jump the points of mountage, C makes it possible to leave information on the standard output and p specifies the way. What will give us in practice
A good idea is to launch the first orders once after each recompiling of the system and the checking once per week or as soon as you have a doubt about the integrity of your system. All that of course by the intermediaire of cron.
You will be able to find several improvements dedicated to the use of mtree as a tool for checking of integrity - in particular its use via/etc/periodic/security - to .http://people.freebsd.org/~fanf/FreeBSD/.
A last very useful tool that we will use to ensure us of the integrity of our system will be KSEC for Kernel Security Checker. KSEC does not make party of the official distribution FreeBSD and is not either in the ports. KSEC is the adaption with FreeBSD of the tool of safety Linux KSTAT (Kernel Security Therapy Anti Trolls) by s0ftpr0ject. To get one to you or the other, return to .http://www.s0ftpj.org/en/site.html. These tools function according to a highly paranoiac design of the system and thus decides to take their information only kernel by using bookshop KVM and by limiting the operations on the syscall ioctl(). It thus will use to us to detect the presence of backdoors in the system in their most frightening form, the modules kernel. KSEC is so thorough that it can be used to us as replacement with ifconfig for the reading. Indeed, by directly observing the structures ifnet or the files descriptor bpf, it can detect if an interface is or not in promiscuous revealing mode of a sniffer and to even provide information and statistics on the traffic or the state of the interfaces. These checks can be carried out through the following operations for the interface fxp0 -- to specify ' all' for all the interfaces available:
($:~)=> ksec -i fxp0
But KSEC also will use to us to detect a deterioration of our integrity system by checking if the addresses indicated in our syscall table are indeed the same ones as announced by/dev/kmem. The modification of the syscall table is a very widespread method in the design of lkm backdoors but which becomes a little old and can be seen replacing by methods of hijacking syscall, pointers towards the syscall table or even of a patching of/dev/kmem to avoid this type of detection. It is on the latter point that the securelevel by preventing any modification of/dev/kmem is judicious. It can also carry out various operations of checking of integrity of the protocols or integrity of the files linkés between them. It any more but does not remain us to carry out a compilation of these options in order to obtain a full report of integrity system
($:~)=> ksec -i interface -b -k -p
In addition we recommend to you to test in case of doubts following mtree reports/ratios and ksec, to carry out an ultimate checking using chkrootkit which him is based primarily on known signatures announcing of the trojanized files but also provides a small series of tests in a style similar to KSEC but less kernel-dependant. See http://www.chkrootkit.org and the ports security for more information.