Tools and Security awareness

• ethereal (http://www.ethereal.org)
  
• Shadow (http://www.nswc.navy.mil/ISSEC/CID/)
  
• NStreams (http://www.hsc.fr/ressources/Tools/nstreams/)
  
  3.2. Nessus
  
  Nessus is what is called a scanner of vulnerabilities (assessment scanner). It has as a characteristic to really carry out the tests corresponding to an attack known against the machine, and this by exploiting as well traditional software attacks as errors of configuration. In addition, it is equipped with a modern architecture aliant customer-server modularity and model. The waiter nessusd carries out the tests while the graphic interface nessus - which can be GTK, Java or even Win32 - allows to select the tests and of reading the reports/ratios of scan by controlling the waiter. This architecture makes it possible to imagine all the configurations like a distant daemon for several operators or an operator for several let us daemons on several networks (this idea not having escaped the companies carrying out from the tests from intrusion on the basis of nessus and seldom contributing). In addition, Nessus is modular, which means that each attack is a plugin in NASL (Nessus Attack Script Language, a language with syntax similar to C for the writing of tests) or out of C called by nessusd to carry out the tests. The plugins are managed by Knowledge Base, true architecture of communication inter plugins in which they are seen sorted according to their type, dependence, need or exclusion and by which they can share information in order to avoid the redundancy of tests. A last notable characteristic is that through the KB, it does not take account of the scanné port, but only of the service thus avoiding being misled by exotic bindés ports. Nessus will use to us to check if our preceding configurations on the level network did not involve the creation of exploitable errors by an intruder and also to check if our services and our system are vulnerable or not to the hundreds of attacks that Nessus tests. It will then only remain us to take measurements necessary like patcher our machine or to modify the configuration of it. You can recover Nessus with http://www.nessus.org or since the ports tree with/usr/ports/security/nessus-1.2.3. You could need also Queso, Nmap or in the future Whisker or IDS which parse the ruleset Snort like Prelude.
  
  Initially, once the finished installation, you must launch the order nessus-adduser in order to add a user to the daemon nessus.
  
  ($:~)=> nessus-adduser
  Using /var/tmp as a temporary file holder
  
  Add a new nessusd user
  ----------------------
  
  Login : eberkut
  Authentication (pass/cert) [pass] : pass
  Login password : foobar
  
  User rules
  ----------
  nessusd has a rules system which allows you to restrict the hosts
  that astro has the right to test. For instance, you may want
  him to be able to scan his own host only.
  
  Please see the nessus-adduser(8) man page for the rules syntax
  
  Enter the rules for this user, and hit ctrl-D once you are done :
  (the user can have an empty rules set)
  ^D
  
  Login : eberkut
  Password : foobar
  DN :
  Rules :
  
  Is that ok ? (y/n) [y] y
  user added.
  
  Note that the syntax of the access rules is rather simplistic since it counts like rules deny to prevent the scan, accept to authorize it and default to define the policy by defect in deny or accept. For each rule, you specify an address IP possibly followed by a netmask in notation CIDR or the variable client_ip automatically indicating the machine source of the customer. You can moreover to be used you as nessusd.users to define rules by users (authenticated by password or key). See nessusd(8) for more details.
  
  # password
  eberkut:foobar
  # rules
  accept client_ip
  default deny
  
  These rules as of other options are still configurable after nessus-adduser via nessusd.conf that we will decide to preserve in/etc rather than in the repertory nessus.
  
  ($:~)=> cp /usr/local/nessus/etc/ /etc/nessus/ && cd /etc/nessus/
  ($:~)=> ee nessusd.conf
  
  # access path to the plugins
  plugins_folder = /nessus/lib/nessus/plugins
  
  # a many simultaneous tests, must be equal to the number of devices bpf
  max_threads = 20
  track_iothreads = yes
  
  # log file
  logfile = syslog
  
  # log all details of the attacks?
  log_whole_attack = yes
  
  # log names of plugins to their loading?
  log_plugins_names_at_load = yes
  
  # dump file for debugging purpose
  dumpfile = /nessus/var/nessus/nessusd.dump
  
  # rules file
  rules = /etc/nessus/nessusd.rules
  
  # user database
  users = /etc/nessus/nessusd.users
  
  # CGI path
  cgi_path = /cgi-bin
  
  # space ports for nmap
  port_range = 1-32768
  
  # optimize test
  optimize_test = yes
  
  # language (english or French)
  language = francais
  
  # Crypto options
  negot_timeout = 600
  force_pubkey_auth = yes
  # peks has been deprecated, and the author of this document does' NT cuts any
  # box to install Nessus and update this share of the configuration slips by. Sorry
  peks_username = nessusd
  peks_keylen = 1024
  peks_keyfile = /etc/nessus/nessusd.private-keys
  peks_usrkeys = /etc/nessus/nessusd.user-keys
  peks_pwdfail = 3
  cookie_logpipe = /etc/nessus/nessusd.logpipe
  cookie_logpipe_suptmo = 2
  
  # optimization
  # read timeout for the test sockets
  checks_read_timeout = 15
  # space between 2 tests against the same port in seconds
  delay_between_tests = 5
  
  For the totality of the tests implying the use of SSL as if you decided to use the authentification client/server by certificates, you will have to generate a certificate. Nessus lays out with this intention of a script nessus-mkcert (and nessus-mkcert-customer to generate a pair certificat/clé for your customer).
  
  ($:~)=> nessus-mkcert
  This depending script will now ask you the information to create the SSL certificate of Nessus. Note that this information will * NOT * Be feels to anybody (everything stays local), goal anyone with the ability to connect to your Nessus daemon will Be whitebait to retrieve this information.
  
  
  CA certificate life time in days [1460]:
  Server certificate life time in days [365]:
  Your country (two letter code) [CH]: FR
  Your state or province name [none]:
  Your location (e.g. town) [Paris]:
  Your organization [Nessus Users United]: CNS
  
  Congratulations. Your server certificate was properly created.
  
  /usr/local/etc/nessus/nessusd.conf updated
  
  The following files were created :
  
  . Certification authority :
  Certificate = /usr/local/com/nessus/CA/cacert.pem
  Private key = /usr/local/var/nessus/CA/cakey.pem
  
  . Nessus Server :
  Certificate = /usr/local/com/nessus/CA/servercert.pem
  Private key = /usr/local/var/nessus/CA/serverkey.pem
  
  Press [ENTER] to exit
  
  If you do not wish to use SSL, place ssl_version at none in nessusd.conf, or change the makefiles nessus-libraries and nessus-core for add - sayable-cipher to /configure. More information in README_SSL available in nessus-core.
  
  To launch the daemon nessus now configured, it any more but does not remain you to carry out
  
  ($:~)=> nessusd -c /etc/nessus/nessusd.conf -D
  
  Note also the option - L allowing to list the base of users.
  
  As regards customer, you lay out as explained various graphic interfaces previously customer, namely X11 in GTK, Java and even 2 Win32. However, remember that nessusd functions only under Unix. When you launch the customer nessus for the first time, it will deal with generating a pair of keys then will ask you a passphrase. The second time, you will not have any more but to return your passphrase. You are then vis-a-vis a window of login allowing you to connect itself to a distant nessusd (fields Nessusd Host, Port, Encryption and Login). You are then directed towards the Plugins panel allowing you to select the plugins test. The higher list classifies the plugins by types, and are posted in the lower list enabling you to select them or not. You also have the buttons Enable All for a complete scan, Enable all goal dangerous plugins not to carry out the tests like the Backs able to plant a weak machine (i.e. Windows) or Sayable All. For some plugins, you will need to specify additional arguments as for the POP2 overflow, the ftp privilege escalation and especially the configuration queso or nmap -- can be in the future Whisker, the cgi scanner by Rain Forrest Puppy. This can be done in the Prefs panel. You have then the panel Scan options in which you can configure the Port Arranges, the number maximum of threads competitor, or the access path to the cgi - this being already configured in the file configuration nessusd - more some other functionalities and especially the options of the port scanning (with nmap) Then come the panel Target Selection in which you specify, in the form of IP with or without netmask or of field, the machines which you wish scanner, separated by commas. You can also have files very ready specifying these rules and make them read by Nessus. You find then the User panel in which you can manage your key or change your passphrase and also specify here still rules of scanning this time specific to this scan in ' reject' the hosts with not scanner. Once all these panels reviewed, it any more but does not remain you to make a start scan and to await the results which will be presented in the form of trees. You will be able then to safeguard them in the form of the same Nessus carryforward (nsr) or in the form of file HTML with graphs, of file postscript or of LaTeX file and many others. In the versions to come, you will be able even directly to export the results in the form of Snort rules and thus use compatible IDS like Snort or Prelude to monitor your vulnerable machines. We will add finally a small bracket on some functionalities for the moment experimental but which will be officially installation at the time of the release 1.1.0. The first is the safeguard of Knowledge Base. Indeed, the information receuillies and shared through the KB is released from the memory after each scan requiring to remake all the process of information gathering each time. If you wish scanner regularly your network, you will pourez to prefer to use the option of panel KB of the interface allowing to activate the safeguard of the KB Before version 1.1.0, this option exists only if you compiled Nessus-core with
  
  ($:~)=> ./configure --enable-save-kb
  
  In this same panel KB, you can then specify if it is necessary of scanner the totality of the hosts, only those already scannés previously or only the new hosts ever scannés. In addition you can specify the re-use of old the KB which will then be reloaded in memory and with it to specify which plugins you do not want to see re-executed: not to remake the scans, not to remake the stages of information gathering, not to remake the attacks or not to remake the Backs Lastly, you have the possibility of defining a limit of time during which old the KB is valid in seconds. Another enticing experimental functionality is the possibility of carrying out detached scans, without intervention of the customer. After the activation of the safeguard of KB, we have in the panel Scan options new entries: detached scan meaning that the customer will not obtain the data in real time, continuous scan makes start again nessusd after each end of tests, send results to this email adress makes it possible to specify an address to which to send the results and finally delay between two scans definite time in seconds between 2 scans of the option continuous scan. By combining these 2 functionalities and by placant a update plugins in the crontab, we have the capacity from now on to carry out a scan of update regular without more troubling us about Nessus. With this intention, we must activate the options Enable KB saving, Only test hosts that cuts never been tested in the past, Reuse the knowledge bases butt the hosts for the test and the 4 options Do not execute in panel KB; and finally we decide that the KB will be valid for one week is 604800 seconds. Then, in the panel Scan options, us pigs the options detached scan and continuous scan and let us place the deadline between 2 scans at one hour, that is to say 3600 seconds. You can specify quite simply the address root like destination of the reports/ratios. Thus, Nessus will scannera only the hosts who have not already been scanné for the last 7 days, will wait one hour and will start again which more is with up to date plugins thanks to the entry of update in the crontab.
  
  If you have some talents in programming and in safety and/or that you wish to contribute to Nessus, you can learn how to create plugins, which make all the value and the power of Nessus, with the address .http://www.nessus.org/doc/nasl.html.
  
  3.3. lsof
  
  The utility lsof - meaning LiSt Open Slips by - is an advantageous replacement with netstat, fstat and sockstat under FreeBSD. It is able to list all the files opened not all the processes and can thus be used to list open ports and services like their owners. You can install lsof since the ports with/usr/ports/sysutils/lsof.
  
  For example we can list only the files sockets Internet with the option - I, the option - N allowing of not resoudre the addresses.
  
  
  ($:~)=> lsof -ni
  COMMAND    PID    USER    FD   TYPE      DEVICE SIZE/OFF NODE NAME
  portmap    156    daemon  3u   IPv4  0xc3dabf00    0t0   UDP  *:sunrpc (LISTEN)
  ssh        259    root   16u   IPv4  0xc3ddcd80    0t0   TCP  *:ssh (LISTEN)
  sendmail   287    daemon  4u   IPv4  0xc3dddb60    0t0   TCP  *:smtp (LISTEN)
  
  
  You see that the presentation of the listing makes it possible to see the types of sockets, TCP or UDP, in column NODE then the address and the port of listening in column NAME. The lines corresponding to connections in progress are posted with an arrow "- >" separating the addresses and ports sources and destinations. The ports in listening do not have an arrow and do not comprise that an address and a port. In this last case, the address can be a star if the process listens on all the addresses simultaneously.
  
  It is possible to ask lsof to post only one port and/or a given address IP. Note that lsof supports the IPv4 addresses as well as v6, it is enough to adopt the notation correct (loopback = 127.0.0.1 and::1)
  ($:~)=> lsof -ni proto@host:port
  
  But lsof offers many other possibilities. We can for example list the whole of the sockets whatever their field (UNIX or Internet)
  
  ($:~)=> lsof -U -n -i
  
  Or to list open files according to their owner by the option - U or their PID by the option - p like by the options - G to filter starting from the group. We can specify several PID, GID and use while placing commas
  
  ($:~)=> lsof -p pid -g gid -u username
  
  Lsof has finally some quite practical functions. First of all using the option - has, we can filter according to several similar arguments. What on sockets of field Internet, can enable us to seek several quite specific services or addresses.
  
  ($:~)=> lsof -a -n -i proto@host:port -i proto@host:port
  
  It as should be known as lsof can be carried out in repeat mode in order to obtain a constant monitoring or regulière. This is carried out using the option +|- R time when time designe time between each repetition in seconds. The option paramètrée with + instead of - makes it possible to stop lsof when it does not list anything any more in addition to stopping by a SIGINT.
  
  ($:~)=> lsof -ni +r30
  
  3.4. stack smashing
  
  We here will approach 2 Tools extremely practical for FreeBSD allowing to prevent the attacks of the type buffer overflow consisting in exceeding a static buffer memory to write an original code carried out with the rights of the program on which this buffer depends. We have of libparanoia and the GCC protector patch.
  
  libparanoia is a bookshop which intercepts the calls to functions supposed sensitive and replaces them by similar functions in all points and functionalities, with the only difference that these functions are modified to prevent all attempts at corruption of the pile memory what makes it possible to warn us faults of the type stack overflow or return- into-libc very documented and largment widespread these last years. Functions ANSI C supposed sensitive are strcpy, strcat, gets, sprintf and scanf which is known to be often exploited at illegitimate ends. The essential problem comes owing to the fact that the language C does not include aucunes technical native checking when we handle variables in a buffer memory. This behavior makes it possible, on the occasion, to write in this memory in order to make there carry out various orders - being able to involve until the complete compromising of the system so the aforementioned program is carried out with the rights root. The basic idea of libparanoia is never not to carry out new instructions following these functions if the stack were modified. One will then prefer to kill the process or to call a function of exit. The method can appear brutal but this supposes a corruption of the buffer memory of this program and, in this context, to block one moment the good course of a program or a single process appears much less serious than to risk the complete comprimission of the system. We install libparanoia by his port in/usr/ports/security/libparanoia. We then recommendons you to carry out the script Copy-to-libc which allows patcher directly the libc FreeBSD some is the version.
  
  ($:~)=> ./copy-to-libc
  
  The GCC Protector Patch consists, as for him, in a series of checking carried out directly by the GNU Compiler Collection during the compilation of programs. It draws part of its techniques from the work carried out for the patch StackGuard for Immunix OS, a distribution Slackware GNU/Linux reinforced by a series of patchs of safety. Thus, it uses a variable guard inserée just after the pointer of preceding screen. As this guard is higher in the pile than a table or a string likely to be diverted, it protects the arguments, the address return and the pointer of preceding screen. The value of this variable is random thus an attacker cannot calculate it to circumvent it.
  
  
                       |------------------------|
                       |       arguments        |
                       |------------------------|
                       |     return adress      |
                       |------------------------|
                       | previous frame pointer |
                       |------------------------|
                       |         guard          |
                       |------------------------|
                       |        arrays          |
                       |------------------------|
                       |     local variables    |
                       |------------------------|
  
  
  According to this model, the data in memory apart from a function cannot be damaged when the function turns over and the attacks on the pointers outwards or within the function do not pass because of the limitations of use of the pile. The GCC protector patch thus introduces here a model says Safety Protection Model of limitations of use of pile.
  
  All these protections run up of course against the limitations of the language C, for example one cannot protect a pointer being part of a structure also containing a table since réagencement is prohibited. Or, the use of the options of optimization of GCC can involve nonthe use of protections of the patch. However, the GCC Protector Patch remains an interesting option in the fight against the attacks by stack overflow. To install it and build FreeBSD with this protection, we must initially patcher GCC then build it indépendemment system.
  
  ($:~)=> cd /usr
  ($:~)=> patch -p1 < protector.patch
  
  ($:~)=> cd /usr/src/gnu/lib/libgcc
  ($:~)=> make depend && make all install clean
  
  ($:~)=> cd /usr/src/gnu/usr.bin/cc
  ($:~)=> make depend && make all install clean
  
  Then before carrying out the operations of recompiling of FreeBSD, we define the variable of environment CFLAGS indicating the options to be passed to the compiler
  
  ($:~)=> setenv CFLAGS=-O -pipe -fstack-protector
  
  It should be noted that the options - fstack-protector and its opposite - fnostack-protector last with GCC make it possible to activate or not the protection of the patch. We update the libc now.
  
  ($:~)=> cd /usr/src/lib/libc
  ($:~)=> make depend && make all install clean
  
  And we have nothing any more but with recompiler the world! This patch is valid since FreeBSD 4.3 and functions with the versions of GCC 2.95.2, 2.95.3 and 3.0. However, of the problems can appear with the compilation of a program not calling upon the variable of environment CFLAGS like XFree. More information with .http://www.trl.ibm.com/projects/security/ssp/.
  
  3.5. tunneling
  
  We now will study the various methods of tunneling available with FreeBSD. The tunneling enables us to encapsulate sometimes significant applicatives sessions like the handling of mail (POP/SMTP), the IRC, the navigation Web, ftp or any other transmission which can see passing from the passwords, within a crypté tunnel. We adopted 2 methods of them: OpenSSH and OpenSSL/Stunnel.
  
  Since the configuration of sshd higher, you must have OpenSSH of gold and already installed. We thus will satisfy we here to develop its options of tunneling. We carry out the following order
  
  ($:~)=> ssh -N -f -L localport:localhost:remoteport user@remotehost
  
  The option - N puts to us in tunnel only, the option - F makes it possible to make turn ssh in basic spot and - L allows preciser the data of the tunnel which are the local port then the distant port between which the tunnel will be carried out. It then does not remain any more but to return the distant host as usual. Once the established tunnel, any connection with like source the local port indicated in the tunnel and like destination the distant port indicated in the tunnel, will forward within tunnel SSH set up.
  
  The second solution consists to create and use tunnels SSL with stunnel, it is in particular the solution applied in the framework of IRCS, securized network IRC. With this intention, we need OpenSSL which is installed in the catalogue cvsup src-all and Stunnel which we will find in/usr/ports/security.
  
  ($:~)=> cd /usr/ports/security/stunnel && make install clean
  
  Then to launch a distant connection as a customer mode, we executons the following order
  
  ($:~)=> stunnel -c -d localhost:localport -r remotehost:remoteservice
  
  The option - C precise which we are as a customer mode carrying out a tunneling thus, and the option - R allows preciser the data of the distant host which are the distant address - which can be a IP or a field - and the distant service which can as well be a port as a name of service contained in/etc/services (while passing you can make a copier/coller since ).http://www.iana.org/assignments/port-numbers). You also can preciser a certificate allowing to authenticate the distant host (recommended) and the verifier by adding the options - v2 and - A path/to/certificat.pem.
  
  We now approach a last method of tunneling differing from the 2 preceding ones by its operation with bush-hammering OSI 3, and its capacity to be used for the installation of true Virtual Private Network between 2 distant LAN which one wants to rather join together by 2 IPSec footbridges - supposing that you diposez at the same time public and private address - than with a communication end-to-end. We thus now will study the configuration of the options of IPSec safety with IPv4. Under FreeBSD, we are used for ourselves to be made dual stack TCP/IP developed within the framework of the KAME project and which supports IPv6 and IPSec perfectly. You can obtain more information on KAME with .http://www.kame.net.
  
  We must first of all configure an interface GIF for the tunneling IPv6/4 over IPv6/4 in order to create the IPSec tunnel. Not to have to repair it with starting, add an entry ifconfig_gif0 to your rc.conf.
  
  ($:~)=> ifconfig create gif0
  ($:~)=> ifconfig gif0 tunnel localhost_public_IP remote_public_IP
  
  We use interface GIF so that it manages the tunnel between IP public and thus allows us to use our IP deprived for the configuration of the rules of coding. In this manner, the packages will be well routés on the level of the routing table of the kernel, and not via the SPD, according to a traditional forwarding path and connections appear in netstat. With GIF, it is possible to filter and sniffer on the level of interface GIF. Without GIF (i.e. by using the public addresses of the IPSec footbridges), there remains possible to filter on the private interfaces and possibly sniffer via rules tee.
  
  To use IPSec, the kernel handles 2 data bases to knowing Security Policy Database (SPD) which makes it possible to notemment define the implementing rules of the IPSec tunnel with the specification of associations of safety (SA); and Security Association Database (SAD) which contains the corresponding keys of SA. The administrator must first of all configure the policy SPD by the intermediare of the order setkey, the kernel refers then to the SPD to check if a package requires IPSec, if in fact the case, it uses SA specified in the SAD. In the event of error or of impossibility of obtaining the key, the kernel fact calls with the daemon IKE racoon will carry out the exchange of keys in order to normally allow SA by directly modifying the SAD. With a syntax and a use similar to ipfw, we use setkey to empty the databases before adding our news policy to it.
  
  ($:~)=> setkey -FP
  ($:~)=> setkey -F
  
  Then we enter our policy the SPD in the form
  action net_src net_dst upperspec -P direction action \
  protocol/mode/gw_src-gw_dst/level
  
  action can take as value: spdadd, spddelete or spdflush - this last correspondent with - FP. net_src and net_dst indicate the private addresses of the networks which one seeks to join together. uppersec indicates the protocols of the layer OSI 4 for which the rule applies. The field can be TCP, UDP or any. The option - P specifies the policy itself followed by the direction which can be in or out, of the action i.e. ipsec to apply ipsec, none to make a simple tunnel or discard to reject the package; follow-up of the protocol which can be ESP (Encapsulated Security Playload) thus offering confidentiality by encryption or AH (Header Authentification) offering the authentification, or finally IPCOMP. The integrity and the protéction against the rejeu of the data are ensured for ESP and AH. Ensuite comes the mode which can be transport in which IPSec intervenes between layer OSI 4 and 3 thus the final package uses clear IP addresses, or tunnel in which IPSec intervenes after layer OSI 3 by adding a header and by encryptant the totality of the package to the footbridge of destination. We have then the address of the footbridge source and of the footbridge of destination and to finish the level which can take the values default to use the variables kernel by defect, uses to use SA or to normally continue the transmission in the event of failure, or require to impose the use of SA. The first variables sysctl all are put at default, followed by an entry which enables us to reject (discard) the packages trying to use the VPN without IPSec because they do not correspond to the security policy. Then, we will paramètrons an entry sysctl allowing to force the renegotiation via Racoon following the loss of one of the 2 ends of the tunnel (by depreciating old SA). Lastly, we activate compatibility Explicit Congestion Notification for IPSec with the following treatment: with the encapsulation the ToS bits are copied except ECN EC, with the decapsulation, the ToS bits are copied but if ECN EC is present, it is copied with the decapsulé package.
  
  
  ($:~)=> sysctl -w net.inet.ipsec.esp_trans_deflev=1
  ($:~)=> sysctl -w net.inet.ipsec.esp_net_deflev=1
  ($:~)=> sysctl -w net.inet.ipsec.ah_trans_deflev=1
  ($:~)=> sysctl -w net.inet.ipsec.ah_net_deflev=1
  ($:~)=> sysctl -w net.inet.ipsec.def_policy=0
  ($:~)=> sysctl -w net.key.prefered_oldsa=0
  ($:~)=> sysctl -w net.inet.ipsec.ecn=1
  
  ($:~)=> setkey -c << EOF
  spdadd internal_net/24 remote_internal_net/24 any -P out ipsec
          esp/tunnel/localhost_public_IP-remote_public_IP/default;
  spdadd remote_internal_range/24 internal_range/24 any -P in ipsec
          esp/tunnel/remote_public_IP-localhost_public_IP/default;
  
  
  Now that our IPSec tunnel is ready to be useful, it remains us to configure Racoon in order to ensure the exchange of the symmetric keys and SAs. to obtain our configuration IPSec, we modify rc.conf to carry out setkey with starting with the file ipsec.conf in argument.
  
  ...
  ipsec_enable="YES"
  ipsec_file="/etc/ipsec.conf"
  ...
  
  
  flush
  spdflush
  
  # SAD entry
  # SA AH avec cle 160 bits
  add localhost_public_IP remote_public_IP ah 1500 -A hmac-sha1 123ABC456EFG789HIJ10
  add remote_public_IP localhost_public_IP ah 1600 -A hmac-sha1 123ABC456EFG789HIJ10
  # SA ESP avec cle 128 bits
  add localhost_public_IP remote_public_IP esp 1500 -E blowfish-cbc 123ABC456EFG789H
  add remote_public_IP localhost_public_IP esp 1600 -E blowfish-cbc 123ABC456EFG789H
  
  # SPD entry
  spdadd internal_net/24 remote_internal_net/24 any -P out ipsec
          esp/tunnel/localhost_public_IP-remote_public_IP/default;
  spdadd remote_internal_range/24 internal_range/24 any -P in ipsec
          esp/tunnel/remote_public_IP-localhost_public_IP/default;
  
  
  We then define for the configuration of racoon a file psk.txt containing the keys used for the identification in the first phase of the exchange of keys.
  
  
  ($:~)=> cat /etc/racoon/psk.txt
  remote_public_IP    shared_key
  
  Then we deal with racoon.conf itself which we publish starting from the file of configuration by defect.
  
  ($:~)=> cp /usr/local/etc/racoon/racoon.conf.dist /etc/racoon.conf
  ($:~)=> ee racoon.conf
  
  
  path pre_shared_key "/etc/racoon/psk.txt" ;
  path certificate "/usr/local/openssl/certs/";
  
  # Padding options
  padding
  {
       maximum_length 20;
       randomize off;
       strict_check on;
       exclusive_tail off;
  }
  
  # Timing Options.  They can be modified by the distant host.
  timer
  {
       counter 5;
       interval 10 sec;
       persend 1;
       phase1 1 min;
       phase2 30 sec;
  }
  
  # Phase 1. anonymous means that this phase is applied to all the hosts.  
  # You can configure phases 1 and 2 for particular hosts.
  remote anonymous
  {
       exchange_mode main,aggressive ;
       # mode of negotiation, aggressive is faster, but hand offers
       # a mechanism of cookie, the protéction of identity and the fixing of
       # Diffie-Hellman group id
       doi ipsec_doi;
       situation identity_only;
       nonce_size 16;
       lifetime time 1 min;    # sec,min,hour
       lifetime byte 2 MB;     # B,KB,GB
       initial_contact on;
       proposal_check obey;    # obey, strict or claim
       #support_mip6 on; # support of Mobile IPv6 (cf snapshots KAME)
  
       proposal
       {
           encryption_algorithm blowfish;
           hash_algorithm sha1;
           authentication_method pre_shared_key ;
           # group Diffie-Hellman
           dh_group 2 ;
       }
  }
  
  # Phase 2.
  sainfo anonymous
  {
       pfs_group 2;
       lifetime time 2 hour ;
       lifetime byte 100 MB ;
       encryption_algorithm 3des, blowfish, rijndael, twofish ;
       authentication_algorithm hmac_sha1, hmac_md5 ;
       # compression IPCOMP
       compression_algorithm deflate ;
  }
  
  
  You can also use for more safety of the certificates to format PEM instead of psk always prone to the rough force. The use of the certificates of the X.509v3 type supported by racoon enables us to remain perfectly interopérable in conformity with standard PKIX. We will need openssl which is in the FreeBSD base to generate a prive/public pair of keys then a certificate to be signed.
  
  Let us start by generating our pair of keys RSA to 1024 bits and stored with format PEM (Privacy Enhanced Mail).
  
  ($:~)=> openssl genrsa -out privkey.pem 1024
  
  Once this (long) finished operation, the following order enables us to carry out a request PKCS#10 of certification of a public key and a distinguished name even of certain numbers of attributes (see RFC 2986).
  
  ($:~)=> openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout
           privkey.pem -outform PEM -out request.pem
  
  This starts a procedure similar to that of adduser where it will be necessary for you to answer certain fields which will define your certificate. We must now make always sign this certificate either by an authority of certification by sending the result of request PKCS#10 to him or by signing it ourself to the assistance openssl with following syntax
  
  ($:~)=> openssl x509 -req -in request.pem -signkey privkey.pem -out cert.pem
  
  We obtain thus the certificate cert.pem with format PEM stored in
  /usr/local/openssl/certs/.
  
  Maintaining to use the certificates instead of psk, we will have to carry out some modifications of racoon.conf. First of all in the section remote, we must place
  
  ...
  certificate_type x509 "certificat" "cle_privee";
  my_identifier user_fqdn "cns@minithins.net";
  ...
  
  Thus specifying the use of X.509 certificates then the certificate and the private key, with going to seek in the definite path openssl at the beginning of racoon.conf. My_identifier is the single name used during the request. Then in the section proposal, we place
  
  ...
  authentication_method rsasig;
  ...
  
  Indicating the method of authentification, which is signature RSA here, the only available one with X.509 certification for the moment.
  
  We add finally an entry in the crontab so that racoon launches out to each reboot or we can place a script launching racoon in
  /usr/local/etc/rc.d/.
  
  4. Conclusion
  
  Veiled, this paper from now on is finished. You must now be in possession of a FreeBSD machine configured so as to largely reduce the risks of intrusion or compromising. However never forget that absolute safety is not EC world, all that we can do is to manage the risk and to put the most possible sticks in the wheels of the attacker. Ridges also very attention with all the relations of confidence which you establish with distant hosts. Indeed, via what is called the contamination by metastases, you could quickly be compromised if you do not pay any attention to your connections and that you always rely on no matter whom. Remember finally that safety cannot be summarized with a program or a single technique, it is a chain of process whose no link is sure at 100% what gives us with the theorie linear systems an extremely fragile process. The goal is to return the task of possible intruder the most difficult.
  
  -------------------------------------------------------------------------------
  
  Copyright (c) 2001,2002,2003 CNS
  
  Free Document Dissemination Licence -- FDDL version 1
  http://pauillac.inria.fr/~lang/licence/v1/fddl.html
  
  This document may be freely read, stored, reproduced, disseminated, translated
  or quoted by any means and on any medium provided the following conditions are
  met:
  
  
• every reader or user of this document acknowledges that he his aware that no guarantee is given regarding its contents, on any account, and specifically concerning veracity, accuracy and fitness for any purpose;
  
• no modification is made other than cosmetic, change of representation format, translation, correction of obvious syntactic errors, or as permitted by the clauses below;
  
• comments and other additions may be inserted, provided they clearly appear as such; translations or fragments must clearly refer to an original complete version, preferably one that is easily accessed whenever possible;
  
• translations, comments and other additions must be dated and their author(s) must be identifiable (possibly via an alias);
  
• this licence is preserved and applies to the whole document with modifications and additions (except for brief quotes), independently of the representation format;
  
• whatever the mode of storage, reproduction or dissemination, anyone able to access a digitized version of this document must be able to make a digitized copy in a format directly usable, and if possible editable, according to accepted, and publicly documented, public standards;
  
• redistributing this document to a third party requires simultaneous redistribution of this licence, without modification, and in particular without any further condition or restriction, expressed or implied, related or not to this redistribution. In particular, in case of inclusion in a database or collection, the owner or the manager of the database or the collection renounces any right related to this inclusion and concerning the possible uses of the document after extraction from documents.
  
  Any incompatibility of the above clauses with legal, contractual or judiciary decisions or constraints implies a corresponding limitation of reading, usage, or redistribution rights for this document, verbatim or modified.

By syncro
10 Dec 2003