We will lean on certain Tools more or less in direct connection with the system but who are not inevitably available by defect or then by the ports but not up to date, or which is caracteristic quite specific system. Thus we here will decouvrir some Tools allowing to reinforce our safety as well proactive manner as reactive.
3.1. TCPdump
TCPdump is the ultimate tool for sniffer the traffic of a network in order to carry out its debugging. It will enable us to capture whole or part of the traffic local area network in order to enable us to analyze it in order to check the correct operation of our configurations network. With this intention TCPdump bases itself on the layer system BPF for Berkeley Packet Filter in order to intercept the Ethernet screens and packages IP forwarding by the machine in promiscuous mode (mode where Network Interface Card or NIC can see the whole of the traffic network) according to expressions' bpf similar to the concepts of expressions regulières. This method of capture by BPF east provides by the bookshop libpcap facilitating the development of sniffers enormously advanced.
TCPdump provides a number of options impressive of which we will approach most useful here. First of all with each capture we recommend following syntax to you:
($:~)=> tcpdump -X -s 1500 -e -n -i fxp0
This line of order makes it possible to obtain a dump at the same time in hexa and ASCII, a length of 1500 bytes, posting information of heading on the level of the connection layer which will be generally Ethernet, we do not carry out a resolution of names in order to gain in speed, discretion and facilitated of analysis; and finally we specify the NIC on which to listen what can avèrer useful when the console admin has several interfaces or is used as footbridge.
The exit as for it is appeared - in the case of a package TCP here - as a timestamp, then Initial the Number Sequence followed by the number of sequence of the package, the size of the package between brackets, flags TCP, the number of acknowledgment, the window size, flag IP informing about the state of fragmentation and finally options TCP. The exit can of course vary if one captures a package UDP or ICMP (with in this last case type ICMP). With the options already presented, we also obtain in the dump the headers layer connection, you can of course remove this option for more simplicity.
A combination of also interesting options and if required to use with the options already seen, is as follows:
($:~)=> tcpdump -i fxp0 -l > file && tail -f file
This entry enables us to redirect the traffic captured on the interface specified towards a file ' file' that we will be able to then see to be brought up to date by group of 10 lines using tail. This allows a monitoring
Of course, we do not need to capture the totality of the packages when we seek only one particular transmission in order to carry out debugging or other analyzes. For that we have the possibility of using expressions BPF introduced higher. They enable us to test a given byte of a package IP or even of its part TCP/UDP/ICMP. It is also possible, thanks to expressions boolénnes to test one or more bits of each byte. Expressions BPF are placed simply at the end of the options of the line of TCPdump order. Traditional expressions BPF are subdivided in 3 groups which can be combined between them to carry out any (or almost:) matching.
The first group is consisted of the ' types' which can be host for matcher an address IP or a field, Net for matcher a class network - this field can be refined by specifying a mask with its continuation - and port for matcher a port. These types are the core operators of the capture. We have then the ' dir' which specifies the direction to be sought. We have here at our disposal the key words src for the origin and dst for the destination. Lastly, we have the group ' proto' which makes it possible to seek corresponding packages. We find there ether or FDDI for the layers Ethernet connections and assimilated, arp and RARP for the protocols of the same name, IP and ip6 for the versions of IP v4 and v6, ICMP and icmp6 in a similar way and finally TCP and UDP. With these 3 groups, it is necessary for us to add several additional expressions to knowing gateway which allows matcher a package whose Ethernet address corresponds to the expression but not address IP source nor destination and thus to obtain the packages coming from a certain router. We also have less and greater in order to capture the packages lower or higher than a given length. Finally we have the traditional logical operators but, and and not representing inclusion, the concatenation or exclusion.
ping of death ($:~)=> tcpdump -Xni fxp0 icmp greater 65535
traffic HTTPS and IRCS ($:~)=> tcpdump -Xni fxp0 (tcp port 443) or (tcp port 994)
There are also advanced expressions making it possible to carry out finer operations of capture on the packages. The syntax of an expression BPF is as follows
proto[offset:longuor ] logical operation
where proto is similar to one of the fields of the group ' proto' referred to above, offset indicates the shift of the field to be tested, the length indicates the length of the field to be intended and the logical operation the test itself. This requires a precise knowledge of the fields of the various protocols what can be done after a study of the RFC corresponding. To seek a precise field, it is wise to point out the structure of a datagram IP and a segment TCP by considering the dump according to:
4 = IP Version 5 = IP header length 003c = IP total length 0a66 = IP ID 4000 = IP fragmentation (flags then multiple offset of 8) 40 = IP TTL 06 = IP Protocol a320 = IP checksum c0a8 0001 = IP source c0a8 0002 = IP destination 04c5 = TCP source port 0016 = TCP destination port 801e 78e3 = TCP sequence number a = TCP data offset 002 = TCP Control bits (flags, ici SYN) 3fc4 = TCP Window Size fe70 = TCP Checksum 0000 = Urgent Pointer 0204 05cc = TCP Maximum Segment Size (only with SYN) 0402 = TCP SackOK Permitted (only with SYN) 080a 0014 7e59 0000 0000 = TCP Timestamp (field reply to 0, since SYN) 0103 = Padding 0300 = TCP Window Scale (only with SYN)
Not to have to retain this heavy diagram (who is right that of a traditional flow), you can carry out following your order tcpdump and after a Unix pipe, tcpdumpx writes by Wietse Venema which precisely comments on the dumpées data. You will be able to find this prorgramme with .ftp://ftp.porcupine.org/pub/debugging/.
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
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.
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.
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.
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.
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
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
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.
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.
($:~)=> 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.
# 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.
# 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)
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).
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
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
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.
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.
