From 0d0e3b3c05b5e3004f526bf0ace02885c36ce2d5 Mon Sep 17 00:00:00 2001 From: Olivier Gayot Date: Sun, 10 May 2015 20:36:08 +0100 Subject: use *.asciidoc(i) extension instead of *.adoc(i) Signed-off-by: Olivier Gayot --- Makefile | 10 +-- apache.adoci | 134 --------------------------------- apache.asciidoci | 134 +++++++++++++++++++++++++++++++++ cover.adoci | 14 ---- cover.asciidoci | 14 ++++ dns.adoci | 161 --------------------------------------- dns.asciidoci | 161 +++++++++++++++++++++++++++++++++++++++ firewall.adoci | 117 ----------------------------- firewall.asciidoci | 117 +++++++++++++++++++++++++++++ ldap1.adoci | 213 ---------------------------------------------------- ldap1.asciidoci | 213 ++++++++++++++++++++++++++++++++++++++++++++++++++++ ldap2.adoci | 156 -------------------------------------- ldap2.asciidoci | 156 ++++++++++++++++++++++++++++++++++++++ pgp.adoci | 75 ------------------ pgp.asciidoci | 75 ++++++++++++++++++ practicals.adoc | 10 --- practicals.asciidoc | 10 +++ smime.adoci | 112 --------------------------- smime.asciidoci | 112 +++++++++++++++++++++++++++ snort.adoci | 66 ---------------- snort.asciidoci | 66 ++++++++++++++++ ssl.adoci | 101 ------------------------- ssl.asciidoci | 101 +++++++++++++++++++++++++ 23 files changed, 1164 insertions(+), 1164 deletions(-) delete mode 100644 apache.adoci create mode 100644 apache.asciidoci delete mode 100644 cover.adoci create mode 100644 cover.asciidoci delete mode 100644 dns.adoci create mode 100644 dns.asciidoci delete mode 100644 firewall.adoci create mode 100644 firewall.asciidoci delete mode 100644 ldap1.adoci create mode 100644 ldap1.asciidoci delete mode 100644 ldap2.adoci create mode 100644 ldap2.asciidoci delete mode 100644 pgp.adoci create mode 100644 pgp.asciidoci delete mode 100644 practicals.adoc create mode 100644 practicals.asciidoc delete mode 100644 smime.adoci create mode 100644 smime.asciidoci delete mode 100644 snort.adoci create mode 100644 snort.asciidoci delete mode 100644 ssl.adoci create mode 100644 ssl.asciidoci diff --git a/Makefile b/Makefile index edec2ca..b0c14d2 100644 --- a/Makefile +++ b/Makefile @@ -1,12 +1,12 @@ -SRC = $(wildcard *.adoc) +SRC = $(wildcard *.asciidoc) -HTML = $(SRC:.adoc=.html) -PDF = $(SRC:.adoc=.pdf) +HTML = $(SRC:.asciidoc=.html) +PDF = $(SRC:.asciidoc=.pdf) all: $(HTML) $(PDF) -%.html: %.adoc $(wildcard *.adoci) +%.html: %.asciidoc $(wildcard *.asciidoci) asciidoc $< -%.pdf: %.adoc $(wildcard *.adoci) +%.pdf: %.asciidoc $(wildcard *.asciidoci) a2x $< -L diff --git a/apache.adoci b/apache.adoci deleted file mode 100644 index 8c3b259..0000000 --- a/apache.adoci +++ /dev/null @@ -1,134 +0,0 @@ -== Apache Practical, Week 4 == - -This practical is about installing and configuring an Apache web server. Since -we need special features (e.g. support for PCRE), we cannot just install the -version provided by our package manager. Instead, we have to build Apache from -source. - -At the end of the practical, we should be able to access public pages on the -web server but also private pages which require HTTP authentication. - -=== Problem 1: Dependencies issue with APR and APR-Util === - -When we try to configure the build of Apache for the first time, it complains -about missing dependencies: APR (Apache Portable Runtime) and APR-util (Apache -Portable Runtime Utility). i.e. a command looking like this: - - $ ./configure --prefix= --with-included-apr --with-pcre=/usr/local/pcre - -gives this output: - - > configure: error: Bundled APR requested but not found at ./srclib/. - > Download and unpack the corresponding apr and apr-util packages to ./srclib/. - -==== Resolution ==== - -Because these two libraries have to be linked with Apache during the build -process, we have to install them in order to be able to build. - -Apache build system already provides us a directory './srclib/' that can be used to -build the libraries along with the Apache itself. It saves us the time of -building them separately. So all we have to do is download the source code of -these two libraries and extract them is './srclib/' - - $ wget -q http://mir2.ovh.net/ftp.apache.org/dist//apr/apr-1.5.1.tar.gz - $ tar xzf apr-1.5.1.tar.gz -C ./srclib/ - $ wget -q http://apache.websitebeheerjd.nl//apr/apr-util-1.5.4.tar.gz - $ tar xzf apr-util-1.5.4.tar.gz -C ./srclib/ - -Since Apache build process expects directories named 'apr' and 'apr-util', we can -create symlinks. - - $ ln -s apr-1.5.1 srclib/apr - $ ln -s apr-util-1.5.4 srclib/apr-util - -Another attempt of running './configure' confirms us that APR and APR-util are -now in place and ready to be built. - -=== Problem 2: pcre-config is not found - -Even though, there is no more dependency issues with APR, the build process now -complains about a missing binary: 'pcre-config' - - > configure: error: pcre-config for libpcre not found. PCRE is required and available from http://pcre.org/ - -==== Resolution ==== - -'pcre-config' and eventually most of '-config' binaries are used by build -processes to portably retrieve linker and compiler flags for a given library. -On Debian and Ubuntu, these binaries are often provided by the '-dev' packages. -In our case, it is 'libpcre3-dev'. - - $ sudo apt-get install libpcre3-dev - -'./configure' now runs without any issue. We can then build and install Apache. - -=== Problem 3: Need of restarting the web server === - -During the configuration of the HTTP authentication, we have to restart the web -server each time we make a single modification because 'httpd.conf' is read at -startup. It becomes very cumbersome when we are not familiar with the syntax on -the configuration file. - -==== Resolution ==== - -Apache provides us a way to use configuration files that are read on the fly. -We often refer to these files as '.htaccess'. In our case, we can configure the -authentication on the fly by replacing in 'httpd.conf' - - AllowOverride None - -by - - AllowOverride AuthConfig - -and restarting the web server. This way, we can write our configuration -directives 'htdocs/private/.htaccess' and test them without reloading Apache. - -=== Problem 4: Web Browsers keep the authentication details === - -Most web browsers, until they are restarted, save your credentials whenever you -successfully pass HTTP authentication so that you do not need to provide them -again when you reload the same page. It is very annoying when we are testing -our HTTP authentication because we need to restart our browser after each -successful attempt. - -==== Resolution ==== - -Instead of using a web browser to test our authentication, we can use 'curl' -which is a tool capable of executing a HTTP request, print the answer and quit -without saving the credentials. - -For that, we first have to install it if it is not already present: - - $ sudo apt-get install curl - -Then we can perform queries to our web server (the '-u' option allows to provide -a 'user:password' pair). - -Only interesting excerpts of the output is shown below - -.Failing to access '/private' without providing user/password: -========== - - $ curl http://csvm2C4E.kent.ac.uk/private/ - > 401 Unauthorized - -========== - -.Failing to access '/private' by providing a wrong password: -========== - - $ curl http://csvm2C4E.kent.ac.uk/private/ -u admin:wrong_pass - > 401 Unauthorized - -========= - -.Successing to access '/private' by providing both a good username and password -========= - - $ curl http://csvm2C4E.kent.ac.uk/private/ -u admin:good_pass - > This content is private. If you can read this message, it means that you have successfully passed HTTP authentication. - -========= - diff --git a/apache.asciidoci b/apache.asciidoci new file mode 100644 index 0000000..8c3b259 --- /dev/null +++ b/apache.asciidoci @@ -0,0 +1,134 @@ +== Apache Practical, Week 4 == + +This practical is about installing and configuring an Apache web server. Since +we need special features (e.g. support for PCRE), we cannot just install the +version provided by our package manager. Instead, we have to build Apache from +source. + +At the end of the practical, we should be able to access public pages on the +web server but also private pages which require HTTP authentication. + +=== Problem 1: Dependencies issue with APR and APR-Util === + +When we try to configure the build of Apache for the first time, it complains +about missing dependencies: APR (Apache Portable Runtime) and APR-util (Apache +Portable Runtime Utility). i.e. a command looking like this: + + $ ./configure --prefix= --with-included-apr --with-pcre=/usr/local/pcre + +gives this output: + + > configure: error: Bundled APR requested but not found at ./srclib/. + > Download and unpack the corresponding apr and apr-util packages to ./srclib/. + +==== Resolution ==== + +Because these two libraries have to be linked with Apache during the build +process, we have to install them in order to be able to build. + +Apache build system already provides us a directory './srclib/' that can be used to +build the libraries along with the Apache itself. It saves us the time of +building them separately. So all we have to do is download the source code of +these two libraries and extract them is './srclib/' + + $ wget -q http://mir2.ovh.net/ftp.apache.org/dist//apr/apr-1.5.1.tar.gz + $ tar xzf apr-1.5.1.tar.gz -C ./srclib/ + $ wget -q http://apache.websitebeheerjd.nl//apr/apr-util-1.5.4.tar.gz + $ tar xzf apr-util-1.5.4.tar.gz -C ./srclib/ + +Since Apache build process expects directories named 'apr' and 'apr-util', we can +create symlinks. + + $ ln -s apr-1.5.1 srclib/apr + $ ln -s apr-util-1.5.4 srclib/apr-util + +Another attempt of running './configure' confirms us that APR and APR-util are +now in place and ready to be built. + +=== Problem 2: pcre-config is not found + +Even though, there is no more dependency issues with APR, the build process now +complains about a missing binary: 'pcre-config' + + > configure: error: pcre-config for libpcre not found. PCRE is required and available from http://pcre.org/ + +==== Resolution ==== + +'pcre-config' and eventually most of '-config' binaries are used by build +processes to portably retrieve linker and compiler flags for a given library. +On Debian and Ubuntu, these binaries are often provided by the '-dev' packages. +In our case, it is 'libpcre3-dev'. + + $ sudo apt-get install libpcre3-dev + +'./configure' now runs without any issue. We can then build and install Apache. + +=== Problem 3: Need of restarting the web server === + +During the configuration of the HTTP authentication, we have to restart the web +server each time we make a single modification because 'httpd.conf' is read at +startup. It becomes very cumbersome when we are not familiar with the syntax on +the configuration file. + +==== Resolution ==== + +Apache provides us a way to use configuration files that are read on the fly. +We often refer to these files as '.htaccess'. In our case, we can configure the +authentication on the fly by replacing in 'httpd.conf' + + AllowOverride None + +by + + AllowOverride AuthConfig + +and restarting the web server. This way, we can write our configuration +directives 'htdocs/private/.htaccess' and test them without reloading Apache. + +=== Problem 4: Web Browsers keep the authentication details === + +Most web browsers, until they are restarted, save your credentials whenever you +successfully pass HTTP authentication so that you do not need to provide them +again when you reload the same page. It is very annoying when we are testing +our HTTP authentication because we need to restart our browser after each +successful attempt. + +==== Resolution ==== + +Instead of using a web browser to test our authentication, we can use 'curl' +which is a tool capable of executing a HTTP request, print the answer and quit +without saving the credentials. + +For that, we first have to install it if it is not already present: + + $ sudo apt-get install curl + +Then we can perform queries to our web server (the '-u' option allows to provide +a 'user:password' pair). + +Only interesting excerpts of the output is shown below + +.Failing to access '/private' without providing user/password: +========== + + $ curl http://csvm2C4E.kent.ac.uk/private/ + > 401 Unauthorized + +========== + +.Failing to access '/private' by providing a wrong password: +========== + + $ curl http://csvm2C4E.kent.ac.uk/private/ -u admin:wrong_pass + > 401 Unauthorized + +========= + +.Successing to access '/private' by providing both a good username and password +========= + + $ curl http://csvm2C4E.kent.ac.uk/private/ -u admin:good_pass + > This content is private. If you can read this message, it means that you have successfully passed HTTP authentication. + +========= + diff --git a/cover.adoci b/cover.adoci deleted file mode 100644 index f7eeb4e..0000000 --- a/cover.adoci +++ /dev/null @@ -1,14 +0,0 @@ -Computer Security Logbook -========================= -Olivier Gayot -v1.0, January 2015 -:doctype: book -:numbered: yes -:toc: yes - -The purpose of this document is to describe and explain how we solved the -problems that we encountered during the practical sessions of computer -security. We are also welcome to share in this document any other thought. Last -but not least, this document will serve as evidence of completion of the -practical. - diff --git a/cover.asciidoci b/cover.asciidoci new file mode 100644 index 0000000..f7eeb4e --- /dev/null +++ b/cover.asciidoci @@ -0,0 +1,14 @@ +Computer Security Logbook +========================= +Olivier Gayot +v1.0, January 2015 +:doctype: book +:numbered: yes +:toc: yes + +The purpose of this document is to describe and explain how we solved the +problems that we encountered during the practical sessions of computer +security. We are also welcome to share in this document any other thought. Last +but not least, this document will serve as evidence of completion of the +practical. + diff --git a/dns.adoci b/dns.adoci deleted file mode 100644 index f426e19..0000000 --- a/dns.adoci +++ /dev/null @@ -1,161 +0,0 @@ -== DNS Practical, Week 8 == - -The purpose of this practical is to install and setup a BIND DNS server on our -virtual machine. - -At the end of the practical, we should be able to use our virtual machine as a -nameserver. Moreover, we should be able to use our new virtual domain. - -=== Problem 1: Setting up an accessible forwarder === - -Whenever our DNS server cannot resolve a domain name, it will query the -forwarders specified in its configuration file. Setting Google Public DNS as a -forwarder is often a good idea. Thus, here is what we put in the 'forwarders' -section of 'named.conf.options'. - - forwarders { - 8.8.8.8; - 8.8.4.4; - }; - -After restarting BIND and trying to resolve 'kent.ac.uk' using 'nslookup' from -the virtual machine, we obtain the following error after some delay: - - $ nslookup isc.org localhost - > ;; connection timed out; no servers could be reached - -==== Resolution ==== - -To diagnose such errors, we often use the tool 'traceroute'. After installing -it with our package manager, we run it this way. - - $ traceroute -n 8.8.8.8 -m 6 - > traceroute to 8.8.8.8 (8.8.8.8), 6 hops max, 60 byte packets - > 1 129.12.44.1 1.975 ms 2.291 ms 2.433 ms - > 2 129.12.254.133 0.488 ms 0.488 ms 0.532 ms - > 3 * * * - > 4 * * * - > 5 * * * - > 6 * * * - -This output confirms that we are unable to communicate with Google Public DNS -servers. Instead, we will use any DNS server of the university that we can -reach: - - $ traceroute -n 129.12.4.56 -m 6 - > traceroute to 129.12.4.56 (129.12.4.56), 6 hops max, 60 byte packets - > 1 129.12.44.1 1.214 ms 1.459 ms 1.829 ms - > 2 129.12.4.56 0.352 ms 0.343 ms 0.273 ms - -Since this server '129.12.4.56' is accessible, we use it instead inside our -'forwarders' section and restart BIND. Now, our 'nslookup' command seems to -work fine. - - $ nslookup isc.org localhost - > Server: localhost - > Address: 127.0.0.1#53 - > - > Non-authoritative answer: - > Name: isc.org - > Address: 149.20.64.69 - -=== Problem 2: Setting our default name server === - -Although it is possible to update our '/etc/resolv.conf' directly, it is -advised not to do so because it is very likely to be overwritten. - -==== Resolution ==== - -Instead of messing up with '/etc/resolv.conf' directly, we will use the tool -'resolvconf' which is a safe way to achieve what we want to do. - -First, delete the existing configuration: - - $ sudo resolvconf -d eth0.inet - -And then append our new configuration: - - $ cat | sudo resolvconf -a custom - nameserver 127.0.0.1; - -We can check that everything worked properly: - - $ cat /etc/resolv.conf - > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) - > # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN - > nameserver 127.0.0.1; - -Now our DNS queries are all using our local DNS server: - - $ nslookup isc.org - > Server: 127.0.0.1 - > Address: 127.0.0.1#53 - > - > Non-authoritative answer: - > Name: isc.org - > Address: 149.20.64.69 - -=== Problem 3: Using our name server from another machine === - -From another machine connected to the university network, we try to use our new -name server. Unfortunately, we get the same error as explained in the first -problem. - - $ nslookup isc.org csvm2C4E.kent.ac.uk - > ;; connection timed out; no servers could be reached - -Using 'traceroute' again, we see that our machines are actually unable to -communicate this way. Although it is possible to use 'ssh' from our own machine -to the virtual machine. - -==== Resolution ==== - -The problem is quite nasty: a machine connected to the university network -behind the VPN cannot be accessed from the inside. Nevertheless, SSH still -works because it uses the TCP protocol (which is connection oriented). Since -DNS queries use the UDP protocol, both machines must be able to connect to each -other. - -Thus, to test our name server, we will connect to the machine 'raptor' from our -own machine using SSH. - -Then, from 'raptor', we can test our name server (only revelant excerpts of the -output are shown below). - -.trying to resolve 'google.com' -====== - - $ nslookup google.com csvm2c4e.kent.ac.uk - > Name: google.com - > Address: 216.58.208.46 - -====== - -.trying to resolve 'foobarbaz.ac.uk' (our virtual domain) -====== - - $ nslookup foobarbaz.ac.uk csvm2c4e.kent.ac.uk - > Name: foobarbaz.ac.uk - > Address: 129.12.44.78 - -====== - -.trying to resolve 'www.foobarbaz.ac.uk' (one of our canonical names) -====== - - $ nslookup www.foobarbaz.ac.uk csvm2c4e.kent.ac.uk - > www.foobarbaz.ac.uk canonical name = foobarbaz.ac.uk. - > Name: foobarbaz.ac.uk - > Address: 129.12.44.78 - -====== - -.trying to resolve '129.12.44.78' -====== - - $ nslookup 129.12.44.78 csvm2c4e.kent.ac.uk - > 78.44.12.129.in-addr.arpa name = 44.12.129.in-addr.arpa. - > 78.44.12.129.in-addr.arpa name = ns.foobarbaz.ac.uk. - -====== - diff --git a/dns.asciidoci b/dns.asciidoci new file mode 100644 index 0000000..f426e19 --- /dev/null +++ b/dns.asciidoci @@ -0,0 +1,161 @@ +== DNS Practical, Week 8 == + +The purpose of this practical is to install and setup a BIND DNS server on our +virtual machine. + +At the end of the practical, we should be able to use our virtual machine as a +nameserver. Moreover, we should be able to use our new virtual domain. + +=== Problem 1: Setting up an accessible forwarder === + +Whenever our DNS server cannot resolve a domain name, it will query the +forwarders specified in its configuration file. Setting Google Public DNS as a +forwarder is often a good idea. Thus, here is what we put in the 'forwarders' +section of 'named.conf.options'. + + forwarders { + 8.8.8.8; + 8.8.4.4; + }; + +After restarting BIND and trying to resolve 'kent.ac.uk' using 'nslookup' from +the virtual machine, we obtain the following error after some delay: + + $ nslookup isc.org localhost + > ;; connection timed out; no servers could be reached + +==== Resolution ==== + +To diagnose such errors, we often use the tool 'traceroute'. After installing +it with our package manager, we run it this way. + + $ traceroute -n 8.8.8.8 -m 6 + > traceroute to 8.8.8.8 (8.8.8.8), 6 hops max, 60 byte packets + > 1 129.12.44.1 1.975 ms 2.291 ms 2.433 ms + > 2 129.12.254.133 0.488 ms 0.488 ms 0.532 ms + > 3 * * * + > 4 * * * + > 5 * * * + > 6 * * * + +This output confirms that we are unable to communicate with Google Public DNS +servers. Instead, we will use any DNS server of the university that we can +reach: + + $ traceroute -n 129.12.4.56 -m 6 + > traceroute to 129.12.4.56 (129.12.4.56), 6 hops max, 60 byte packets + > 1 129.12.44.1 1.214 ms 1.459 ms 1.829 ms + > 2 129.12.4.56 0.352 ms 0.343 ms 0.273 ms + +Since this server '129.12.4.56' is accessible, we use it instead inside our +'forwarders' section and restart BIND. Now, our 'nslookup' command seems to +work fine. + + $ nslookup isc.org localhost + > Server: localhost + > Address: 127.0.0.1#53 + > + > Non-authoritative answer: + > Name: isc.org + > Address: 149.20.64.69 + +=== Problem 2: Setting our default name server === + +Although it is possible to update our '/etc/resolv.conf' directly, it is +advised not to do so because it is very likely to be overwritten. + +==== Resolution ==== + +Instead of messing up with '/etc/resolv.conf' directly, we will use the tool +'resolvconf' which is a safe way to achieve what we want to do. + +First, delete the existing configuration: + + $ sudo resolvconf -d eth0.inet + +And then append our new configuration: + + $ cat | sudo resolvconf -a custom + nameserver 127.0.0.1; + +We can check that everything worked properly: + + $ cat /etc/resolv.conf + > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) + > # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN + > nameserver 127.0.0.1; + +Now our DNS queries are all using our local DNS server: + + $ nslookup isc.org + > Server: 127.0.0.1 + > Address: 127.0.0.1#53 + > + > Non-authoritative answer: + > Name: isc.org + > Address: 149.20.64.69 + +=== Problem 3: Using our name server from another machine === + +From another machine connected to the university network, we try to use our new +name server. Unfortunately, we get the same error as explained in the first +problem. + + $ nslookup isc.org csvm2C4E.kent.ac.uk + > ;; connection timed out; no servers could be reached + +Using 'traceroute' again, we see that our machines are actually unable to +communicate this way. Although it is possible to use 'ssh' from our own machine +to the virtual machine. + +==== Resolution ==== + +The problem is quite nasty: a machine connected to the university network +behind the VPN cannot be accessed from the inside. Nevertheless, SSH still +works because it uses the TCP protocol (which is connection oriented). Since +DNS queries use the UDP protocol, both machines must be able to connect to each +other. + +Thus, to test our name server, we will connect to the machine 'raptor' from our +own machine using SSH. + +Then, from 'raptor', we can test our name server (only revelant excerpts of the +output are shown below). + +.trying to resolve 'google.com' +====== + + $ nslookup google.com csvm2c4e.kent.ac.uk + > Name: google.com + > Address: 216.58.208.46 + +====== + +.trying to resolve 'foobarbaz.ac.uk' (our virtual domain) +====== + + $ nslookup foobarbaz.ac.uk csvm2c4e.kent.ac.uk + > Name: foobarbaz.ac.uk + > Address: 129.12.44.78 + +====== + +.trying to resolve 'www.foobarbaz.ac.uk' (one of our canonical names) +====== + + $ nslookup www.foobarbaz.ac.uk csvm2c4e.kent.ac.uk + > www.foobarbaz.ac.uk canonical name = foobarbaz.ac.uk. + > Name: foobarbaz.ac.uk + > Address: 129.12.44.78 + +====== + +.trying to resolve '129.12.44.78' +====== + + $ nslookup 129.12.44.78 csvm2c4e.kent.ac.uk + > 78.44.12.129.in-addr.arpa name = 44.12.129.in-addr.arpa. + > 78.44.12.129.in-addr.arpa name = ns.foobarbaz.ac.uk. + +====== + diff --git a/firewall.adoci b/firewall.adoci deleted file mode 100644 index 6839aa3..0000000 --- a/firewall.adoci +++ /dev/null @@ -1,117 +0,0 @@ -== Firewall Practical, Week 10 == - -The purpose of this practical is to make us create and modify rules of iptables -firewall. - -At the end of this practical, we should be able to add rules to block or allow -different IP addresses on different ports. - -=== Problem 1: Take the necessary precautions === - -When playing with a firewall (especially on a remote machine), we must -always assume that the worst will happen. Indeed, it is very easy to completely -lose access to our machine by making a single mistake. - -==== Resolution ==== - -We will first create an executable file named 'iptables-allow-ssh' that will -create rules allowing a SSH connection from outside. When executed, this file -should be able to allow-ssh a connection no matter what we put in our 'INPUT' -table. If everything is completely messed up, we even prefer performing a -reboot than leaving our machine unreachable. - -...... -#/bin/sh - -# accept ssh as input - -/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT || /sbin/reboot -/sbin/iptables -A INPUT -p tcp --dport ssh -j ACCEPT || /sbin/reboot -...... - -In case we lose our connection, we want this file to be executed. We will use -'cron' to schedule its execution every minute. - -Here is the content that we put in our 'crontab' file. - -...... -* * * * * /home/student/iptables-allow-ssh -...... - -After waiting one minute, we can notice that our scheduled task has been -executed. - - $ sudo iptables -L INPUT - > Chain INPUT (policy ACCEPT) - > target prot opt source destination - > ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED - > ACCEPT tcp -- anywhere anywhere tcp dpt:ssh - -We can now modify our 'INPUT' chain almost safely. When we will stop making -modifications, we will be able to remove the duplicate iptables rules and then -delete the 'crontab' file. - -=== Problem 2: Write the proper rules === - -All we have to do now is to create our rules to allow or deny HTTP and HTTPS -access. We have to keep in mind that it is better to write as less rules as -possible. - -==== Resolution ==== - -Since we do not want to block multiple ports, we will leave the policy of -'INPUT' to 'ACCEPT'. - -The rule to block HTTPS is quite simple: - - $ sudo /sbin/iptables -A INPUT -p tcp --dport https -j REJECT - -Result: - - $ curl https://csvm2c4e.kent.ac.uk - > curl: (7) couldn't connect to host - $ curl http://csvm2c4e.kent.ac.uk - >

It works!

- -The rule to only allow HTTPS is almost the same (but first, we delete our -previous rule): - - $ sudo /sbin/iptables -D INPUT -p tcp --dport https -j REJECT - $ sudo /sbin/iptables -A INPUT -p tcp --dport http -j REJECT - -Result: - - $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt - >

It works!

- $ curl http://csvm2c4e.kent.ac.uk - > curl: (7) couldn't connect to host - -To block both HTTP and HTTPS in only one rule we can use a match extension (but -first, we delete our previous rule): - - $ sudo /sbin/iptables -D INPUT -p tcp --dport http -j REJECT - $ sudo /sbin/iptables -A INPUT -p tcp -m multiport --dports http,https -j REJECT - -Result: - - $ curl https://csvm2c4e.kent.ac.uk - > curl: (7) couldn't connect to host - $ curl http://csvm2c4e.kent.ac.uk - > curl: (7) couldn't connect to host - -Last but not least, to deny only one host (but first, we delete our previous -rule): - - $ sudo /sbin/iptables -D INPUT -p tcp -m multiport --dports http,https -j REJECT - $ sudo /sbin/iptables -A INPUT -p tcp --source raptor.kent.ac.uk -m multiport --dports http,https -j REJECT - -Result from our VM - - $ curl http://localhost - >

It works!

- -Result from 'raptor.kent.ac.uk' - - $ curl http://csvm2c4e.kent.ac.uk - > curl: (7) Failed to connect to csvm2c4e.kent.ac.uk port 80: Connection refused - diff --git a/firewall.asciidoci b/firewall.asciidoci new file mode 100644 index 0000000..6839aa3 --- /dev/null +++ b/firewall.asciidoci @@ -0,0 +1,117 @@ +== Firewall Practical, Week 10 == + +The purpose of this practical is to make us create and modify rules of iptables +firewall. + +At the end of this practical, we should be able to add rules to block or allow +different IP addresses on different ports. + +=== Problem 1: Take the necessary precautions === + +When playing with a firewall (especially on a remote machine), we must +always assume that the worst will happen. Indeed, it is very easy to completely +lose access to our machine by making a single mistake. + +==== Resolution ==== + +We will first create an executable file named 'iptables-allow-ssh' that will +create rules allowing a SSH connection from outside. When executed, this file +should be able to allow-ssh a connection no matter what we put in our 'INPUT' +table. If everything is completely messed up, we even prefer performing a +reboot than leaving our machine unreachable. + +...... +#/bin/sh + +# accept ssh as input + +/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT || /sbin/reboot +/sbin/iptables -A INPUT -p tcp --dport ssh -j ACCEPT || /sbin/reboot +...... + +In case we lose our connection, we want this file to be executed. We will use +'cron' to schedule its execution every minute. + +Here is the content that we put in our 'crontab' file. + +...... +* * * * * /home/student/iptables-allow-ssh +...... + +After waiting one minute, we can notice that our scheduled task has been +executed. + + $ sudo iptables -L INPUT + > Chain INPUT (policy ACCEPT) + > target prot opt source destination + > ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED + > ACCEPT tcp -- anywhere anywhere tcp dpt:ssh + +We can now modify our 'INPUT' chain almost safely. When we will stop making +modifications, we will be able to remove the duplicate iptables rules and then +delete the 'crontab' file. + +=== Problem 2: Write the proper rules === + +All we have to do now is to create our rules to allow or deny HTTP and HTTPS +access. We have to keep in mind that it is better to write as less rules as +possible. + +==== Resolution ==== + +Since we do not want to block multiple ports, we will leave the policy of +'INPUT' to 'ACCEPT'. + +The rule to block HTTPS is quite simple: + + $ sudo /sbin/iptables -A INPUT -p tcp --dport https -j REJECT + +Result: + + $ curl https://csvm2c4e.kent.ac.uk + > curl: (7) couldn't connect to host + $ curl http://csvm2c4e.kent.ac.uk + >

It works!

+ +The rule to only allow HTTPS is almost the same (but first, we delete our +previous rule): + + $ sudo /sbin/iptables -D INPUT -p tcp --dport https -j REJECT + $ sudo /sbin/iptables -A INPUT -p tcp --dport http -j REJECT + +Result: + + $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt + >

It works!

+ $ curl http://csvm2c4e.kent.ac.uk + > curl: (7) couldn't connect to host + +To block both HTTP and HTTPS in only one rule we can use a match extension (but +first, we delete our previous rule): + + $ sudo /sbin/iptables -D INPUT -p tcp --dport http -j REJECT + $ sudo /sbin/iptables -A INPUT -p tcp -m multiport --dports http,https -j REJECT + +Result: + + $ curl https://csvm2c4e.kent.ac.uk + > curl: (7) couldn't connect to host + $ curl http://csvm2c4e.kent.ac.uk + > curl: (7) couldn't connect to host + +Last but not least, to deny only one host (but first, we delete our previous +rule): + + $ sudo /sbin/iptables -D INPUT -p tcp -m multiport --dports http,https -j REJECT + $ sudo /sbin/iptables -A INPUT -p tcp --source raptor.kent.ac.uk -m multiport --dports http,https -j REJECT + +Result from our VM + + $ curl http://localhost + >

It works!

+ +Result from 'raptor.kent.ac.uk' + + $ curl http://csvm2c4e.kent.ac.uk + > curl: (7) Failed to connect to csvm2c4e.kent.ac.uk port 80: Connection refused + diff --git a/ldap1.adoci b/ldap1.adoci deleted file mode 100644 index 4c8b452..0000000 --- a/ldap1.adoci +++ /dev/null @@ -1,213 +0,0 @@ -== OpenLDAP Practical, Week 5 == - -This practical is about installing and configuring an OpenLDAP LDAP server on -our virtual machine. We want to setup it from source and link it with Berkeley -DB backend. - -At the end of the practical, we should have a working LDAP -directory reflecting more or less what we could have in the LDAP server of the -university. - -=== Problem 1: Unsupported version of Java VM === - -When running the './configure' command for the first time, it fails with - - > checking if java works... configure: error: The Java VM java failed (see config.log, check the CLASSPATH?) - -After having a look inside 'config.log', we find this error: - - > java.lang.UnsupportedClassVersionError unsupported major.minor version 51.0 - -==== Resolution ==== - -This exception ('unsupported major.minor version xx.y') arises when there is a -version mismatch between the Java compiler and Virtual Machine. We verifiy this -assertion by issuing the following commands and checking their output: - - $ javac -version; java -version - > javac 1.7.0_65 - > java version "1.6.0_33" - -The output confirms that something is messed up so we fix this error by -removing the package 'openjdk-6-jre-headless' which was installed for some -reason. - -=== Problem 2: schema files are read-only === - -When willing to modify 'etc/openldap/schema/core.schema', it turns out that the -file is actually read-only. - -==== Resolution ==== - -It is actually not advisable to directly modify the default schema files -present in 'etc/openldap/schema/'. Installing them read-only is a way to tell -the user not to modify them because they are likely to be overriden by an -automatic process (especially by running 'make install' again). - -In our case, instead of modifying 'schema/core.schema', we will extend our -schema by creating a 'schema/local.schema' file and write our additional schema -inside. - -Last but not least, we have to instruct 'slapd' to include this file by adding -this line in 'slapd.conf' (after replacing '' with slapd's -configuration directory). - - include /schema/local.schema - -=== Problem 3: writing the proper command line to add the DIT === - -Since we prefer using command line interfaces, we will use 'ldapadd' instead of -'Jxplorer' to create our DIT. Thus we have to understand how to use 'ldapadd' -properly. - -==== Resolution ==== - -After having a glance at the manual page 'ldapadd (1)', we find out that: - -- the option '-W' tells 'ldapadd' to prompt for our password but we can also - supply it directly using '-w'. -- the option '-D' allows us to pass the Distinguished Name -- the option '-f' allows us to pass a LDIF file - -Thus, our command line can look something like: - - $ ldapadd -w secret -D 'cn=Manager,c=gb' -f file.ldif - -=== Problem 4: writing the LDIF file === - -To construct our DIT, we need to write its description in the LDIF file that we -will pass to 'ldapadd'. The reason why the practical advise us to create the -DIT using a LDAP browser is certainly because writing a LDIF file is rather -tricky the first time. - -==== Resolution ==== - -Though the manpage of 'ldapadd' gives us a basic example of LDIF file for -adding an entry, it is rather insufficient. - -The documentation of OpenLDAP, especially the section _LDIF text entry format_ -available at the link below gives us more information, including an example -with children and parent nodes. - -http://www.openldap.org/doc/admin24/dbtools.html#The%20LDIF%20text%20entry%20format - -After a few tries with different syntaxes, we finally get this error: - - ldap_add: Invalid syntax (21) - additional info: objectClass: value #0 invalid per syntax - -Here, the 'objectClass' refered to is 'organisation'. The problem is that it is -misspelled in the practical. The real class is actually 'organization' as -stated here: - -http://www.zytrax.com/books/ldap/ape/ - -The issue is actually the same with 'organisationalUnit' and -'organisationalPerson'. - -At this point, our LDIF file looks something like: - - dn: o=University of Kent,c=gb - objectClass: organization - - dn: ou=MSc ISB,o=University of Kent,c=gb - objectClass: organizationalUnit - - dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb - objectClass: organizationalPerson - objectClass: pkiUser - objectClass: pmiUser - -After trying to add it using 'ldapadd', the LDAP server sends us this error: - - adding new entry "cn=Olivier Gayot,ou=MSc ISB,o=KENT,c=gb" - ldap_add: Object class violation (65) - additional info: object class 'organizationalPerson' requires attribute 'sn' - -What we understand here is that we need to add an extra attribute 'sn'. To -figure out what it actually means, we can have a look in the file -'schema/core.schema', especially this section: - - attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) - DESC 'RFC2256: last (family) name(s) for which the entity is known by' - SUP name ) - -With that information, we can edit our LDIF file and supply our new attribute: - - dn: o=University of Kent,c=gb - objectClass: organization - - dn: ou=MSc ISB,o=University of Kent,c=gb - objectClass: organizationalUnit - - dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb - objectClass: organizationalPerson - objectClass: pkiUser - objectClass: pmiUser - sn: Gayot - -By using the command line below, our DIT is successfully created (the option -'-c' is used here because, without it, 'ldapadd' stops because our parent nodes -have already been created) - - $ ldapadd -w secret -D 'cn=Manager,c=gb' -f file.ldif -c - -=== Problem 5: Modifying an entry to add other classes === - -To add new attributes (uid, password and role), to our freshly created user -without deleting it, we need to modify its entry. Since 'ldapadd' does not -permit to override an entry, we have to find another way. - -==== Resolution ==== - -We start by having a look inside the schema files to figure out what classes -and attributes we need to store our new informations. - -Here is a list of what we need: - -- an 'uidObject' class which requires a 'uid' attribute -- a 'permisRole' attribute which we can be set to our desired value -- a 'userPassword' attribute which will store a password in a non-plaintext format - -Then, by reading the manpage 'ldif (5)', we learn about the syntax of a LDIF file to -modify an entry. In our case, we create another '.ldif' to handle our -modification and add this content inside: - - dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb - changetype: modify - add: objectClass - objectClass: uidObject - - - add: uid - uid: ojgg2 - - - add: permisRole - permisRole: student - - - add: userPassword - userPassword: fooBar - -By running 'ldapmodify' the same way we used 'ldapadd', our entry is -successfully modified. - -After reading the manpage 'ldapsearch (1)', we can check our result by issuing -the command below and reading its output (only the interesting excerpt of the -output is shown below). - - $ ldapsearch -H ldap://csvm2C4E.kent.ac.uk -x -b 'c=gb' '(cn=Olivier Gayot)' - - > # Olivier Gayot, MSc ISB, University of Kent, gb - > dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb - > objectClass: organizationalPerson - > objectClass: pkiUser - > objectClass: pmiUser - > objectClass: uidObject - > sn: gayot - > cn: Olivier Gayot - > uid: ojgg2 - > permisRole: student - > userPassword:: Zm9vQmFy - -That's it! By the way, we can note that our password 'fooBar' is stored as -'Zm9vQmFy' (its NT-OWF hashed format). - diff --git a/ldap1.asciidoci b/ldap1.asciidoci new file mode 100644 index 0000000..4c8b452 --- /dev/null +++ b/ldap1.asciidoci @@ -0,0 +1,213 @@ +== OpenLDAP Practical, Week 5 == + +This practical is about installing and configuring an OpenLDAP LDAP server on +our virtual machine. We want to setup it from source and link it with Berkeley +DB backend. + +At the end of the practical, we should have a working LDAP +directory reflecting more or less what we could have in the LDAP server of the +university. + +=== Problem 1: Unsupported version of Java VM === + +When running the './configure' command for the first time, it fails with + + > checking if java works... configure: error: The Java VM java failed (see config.log, check the CLASSPATH?) + +After having a look inside 'config.log', we find this error: + + > java.lang.UnsupportedClassVersionError unsupported major.minor version 51.0 + +==== Resolution ==== + +This exception ('unsupported major.minor version xx.y') arises when there is a +version mismatch between the Java compiler and Virtual Machine. We verifiy this +assertion by issuing the following commands and checking their output: + + $ javac -version; java -version + > javac 1.7.0_65 + > java version "1.6.0_33" + +The output confirms that something is messed up so we fix this error by +removing the package 'openjdk-6-jre-headless' which was installed for some +reason. + +=== Problem 2: schema files are read-only === + +When willing to modify 'etc/openldap/schema/core.schema', it turns out that the +file is actually read-only. + +==== Resolution ==== + +It is actually not advisable to directly modify the default schema files +present in 'etc/openldap/schema/'. Installing them read-only is a way to tell +the user not to modify them because they are likely to be overriden by an +automatic process (especially by running 'make install' again). + +In our case, instead of modifying 'schema/core.schema', we will extend our +schema by creating a 'schema/local.schema' file and write our additional schema +inside. + +Last but not least, we have to instruct 'slapd' to include this file by adding +this line in 'slapd.conf' (after replacing '' with slapd's +configuration directory). + + include /schema/local.schema + +=== Problem 3: writing the proper command line to add the DIT === + +Since we prefer using command line interfaces, we will use 'ldapadd' instead of +'Jxplorer' to create our DIT. Thus we have to understand how to use 'ldapadd' +properly. + +==== Resolution ==== + +After having a glance at the manual page 'ldapadd (1)', we find out that: + +- the option '-W' tells 'ldapadd' to prompt for our password but we can also + supply it directly using '-w'. +- the option '-D' allows us to pass the Distinguished Name +- the option '-f' allows us to pass a LDIF file + +Thus, our command line can look something like: + + $ ldapadd -w secret -D 'cn=Manager,c=gb' -f file.ldif + +=== Problem 4: writing the LDIF file === + +To construct our DIT, we need to write its description in the LDIF file that we +will pass to 'ldapadd'. The reason why the practical advise us to create the +DIT using a LDAP browser is certainly because writing a LDIF file is rather +tricky the first time. + +==== Resolution ==== + +Though the manpage of 'ldapadd' gives us a basic example of LDIF file for +adding an entry, it is rather insufficient. + +The documentation of OpenLDAP, especially the section _LDIF text entry format_ +available at the link below gives us more information, including an example +with children and parent nodes. + +http://www.openldap.org/doc/admin24/dbtools.html#The%20LDIF%20text%20entry%20format + +After a few tries with different syntaxes, we finally get this error: + + ldap_add: Invalid syntax (21) + additional info: objectClass: value #0 invalid per syntax + +Here, the 'objectClass' refered to is 'organisation'. The problem is that it is +misspelled in the practical. The real class is actually 'organization' as +stated here: + +http://www.zytrax.com/books/ldap/ape/ + +The issue is actually the same with 'organisationalUnit' and +'organisationalPerson'. + +At this point, our LDIF file looks something like: + + dn: o=University of Kent,c=gb + objectClass: organization + + dn: ou=MSc ISB,o=University of Kent,c=gb + objectClass: organizationalUnit + + dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb + objectClass: organizationalPerson + objectClass: pkiUser + objectClass: pmiUser + +After trying to add it using 'ldapadd', the LDAP server sends us this error: + + adding new entry "cn=Olivier Gayot,ou=MSc ISB,o=KENT,c=gb" + ldap_add: Object class violation (65) + additional info: object class 'organizationalPerson' requires attribute 'sn' + +What we understand here is that we need to add an extra attribute 'sn'. To +figure out what it actually means, we can have a look in the file +'schema/core.schema', especially this section: + + attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) + DESC 'RFC2256: last (family) name(s) for which the entity is known by' + SUP name ) + +With that information, we can edit our LDIF file and supply our new attribute: + + dn: o=University of Kent,c=gb + objectClass: organization + + dn: ou=MSc ISB,o=University of Kent,c=gb + objectClass: organizationalUnit + + dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb + objectClass: organizationalPerson + objectClass: pkiUser + objectClass: pmiUser + sn: Gayot + +By using the command line below, our DIT is successfully created (the option +'-c' is used here because, without it, 'ldapadd' stops because our parent nodes +have already been created) + + $ ldapadd -w secret -D 'cn=Manager,c=gb' -f file.ldif -c + +=== Problem 5: Modifying an entry to add other classes === + +To add new attributes (uid, password and role), to our freshly created user +without deleting it, we need to modify its entry. Since 'ldapadd' does not +permit to override an entry, we have to find another way. + +==== Resolution ==== + +We start by having a look inside the schema files to figure out what classes +and attributes we need to store our new informations. + +Here is a list of what we need: + +- an 'uidObject' class which requires a 'uid' attribute +- a 'permisRole' attribute which we can be set to our desired value +- a 'userPassword' attribute which will store a password in a non-plaintext format + +Then, by reading the manpage 'ldif (5)', we learn about the syntax of a LDIF file to +modify an entry. In our case, we create another '.ldif' to handle our +modification and add this content inside: + + dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb + changetype: modify + add: objectClass + objectClass: uidObject + - + add: uid + uid: ojgg2 + - + add: permisRole + permisRole: student + - + add: userPassword + userPassword: fooBar + +By running 'ldapmodify' the same way we used 'ldapadd', our entry is +successfully modified. + +After reading the manpage 'ldapsearch (1)', we can check our result by issuing +the command below and reading its output (only the interesting excerpt of the +output is shown below). + + $ ldapsearch -H ldap://csvm2C4E.kent.ac.uk -x -b 'c=gb' '(cn=Olivier Gayot)' + + > # Olivier Gayot, MSc ISB, University of Kent, gb + > dn: cn=Olivier Gayot,ou=MSc ISB,o=University of Kent,c=gb + > objectClass: organizationalPerson + > objectClass: pkiUser + > objectClass: pmiUser + > objectClass: uidObject + > sn: gayot + > cn: Olivier Gayot + > uid: ojgg2 + > permisRole: student + > userPassword:: Zm9vQmFy + +That's it! By the way, we can note that our password 'fooBar' is stored as +'Zm9vQmFy' (its NT-OWF hashed format). + diff --git a/ldap2.adoci b/ldap2.adoci deleted file mode 100644 index 76ee056..0000000 --- a/ldap2.adoci +++ /dev/null @@ -1,156 +0,0 @@ -== OpenLDAP Practical 2, Week 7 == - -This practical is about configuring Apache so that it uses our OpenLDAP -directory to accept or deny HTTP authentication requests. - -At the end of the practical, we should be able to add or remove users that are -allowed to authenticate on the website by adding or removing LDAP entries. - -=== Problem 1: Avoiding obsolete commands === - -The practical provides us some commands to, inter alia, configure Apache. -Nevertheless some of them are obsolete or deprecated. Here is a list of -obsolete ways and their prefered substitute: - -- enabling an Apache module by creating symlinks by hand. The recommended way - is to use the command 'a2enmod' which takes the name of the module (i.e. -without file extension) and generate the symlink(s) to the proper file(s) -itself. In our case, the command is: - - $ sudo a2enmod ldap - -- stopping, starting (that to say restarting) a service (i.e. Apache) on - Debian-like distributions can be achieved by using the command 'service'. In -addition to avoiding any risk of messing up anything inside the '/etc/init.d/' -directory, this tool first checks in '/etc/init' if there is an upstart job of -the same name. In our case, the command for restarting Apache is: - - $ sudo service apache2 restart - -- enabling an Apache site can be achieved using the command 'a2ensite' which is - very similar to 'a2enmod'. The advantage of this method is that it avoids the -risk of messing up with the precedence of the configuration files when enabling -multiple sites. - -=== Problem 2: Enabling the LDAP authentication module === - -After having a look at the documentation of 'mod_auth_ldap' (provided in the -'Supporting Information' section of the practical), we try to activate the -module with the command below but we are indeed facing an error: - - $ sudo a2enmod auth_ldap - > ERROR: Module auth_ldap does not exist! - -==== Resolution ==== - -The answer is actually somehow given at the very beginning of the documentation -of 'mod_auth_ldap': - -[verse] -This document refers to the 2.0 version of Apache httpd, which is no longer maintained. Upgrade, and refer to the current version of httpd instead, documented at [...] - -Following the given link and browsing to 'Authentication and Authorization' -suggests us another module (which we have): 'mod_authnz_ldap' which we can -successfully activate by issuing the following command and then restarting -Apache. - - $ sudo a2enmod authnz_ldap - -=== Problem 3: Configuring the authentication mechanism === - -After configuring Apache so that the authentication can be overriden in -'.htaccess' files (similarly to what we did in Apache Practical), we have to -figure out what directives to write in our '.htaccess' file to handle HTTP -authentication using LDAP. - -The documentation of 'mod_authnz_ldap' covers almost every information we need. -Since we think that allowing only the users whose 'permisRole' is set to -'staff' to access the website, we construct our '.htaccess' file this way: - - AuthBasicProvider ldap - AuthLDAPURL "ldap://localhost/ou=MSc ISB,o=University of Kent,c=gb?uid?one" - Require ldap-attribute permisRole=staff - -Nevertheless, when we try to access the website, we get an 'Internal Server -Error'. - -==== Resolution ==== - -To understand what is going wrong, we can read the end of the file -'/var/log/apache2/error.log'. More preferably, we can run the following command -on another terminal (or as a background process) so that we will be informed of -any other error that we will encounter afterwards: - - $ tail -f /var/log/apache2/error.log - > configuration error: couldn't perform authentication. AuthType not set!: / - -The output is rather clear, we need to add the authentication type (which is -still 'Basic' in our case). - -After another attempt with another 'Internal Server Error', our 'tail' running -process gives us this output - - > need AuthName: / - -The output is once again rather clear, we just have to add a authentication -name of our choice. - -After those modifications, our '.htaccess' looks something like this: - - AuthType Basic - AuthName "You need to authenticate with a LDAP entry" - AuthBasicProvider ldap - AuthLDAPURL "ldap://localhost/ou=MSc ISB,o=University of Kent,c=gb?uid?one" - Require ldap-attribute permisRole=staff - -=== Problem 4: Testing our authentication === - -We still need to test our authentication to validate its proper functioning. -For that purpose, we have to add at least another entry in the LDAP directory -and run some tests using 'curl'. - -==== Resolution ==== - -First, we will add another user (whose 'permisRole' is 'staff'). The input that -we have to provide to 'ldapadd' is the following: - - dn: cn=Olivier Gayot Staff,ou=MSc ISB,o=University of Kent,c=gb - objectClass: organizationalPerson - objectClass: pkiUser - objectClass: pmiUser - objectClass: uidObject - sn: gayot - uid: ojgg - userPassword: fooBar - permisRole: staff - -Using 'curl' the same way we did in the Apache practical, we can run some tests (only interesting excerpts of the output are shown below): - -.trying (with success) to authenticate using the staff account -====== - - $ curl http://csvm2c4e.kent.ac.uk -u 'ojgg:fooBar' - >

It works!

- -====== - -.trying (without success) to authenticate using the student account -====== - - $ curl http://csvm2c4e.kent.ac.uk -u 'ojgg2:fooBar' - > 401 Authorization Required - -====== - -.trying (without success) to authenticate with a wrong password -====== - - $ curl http://csvm2c4e.kent.ac.uk -u 'ojgg:wrongPassword' - > 401 Authorization Required - -In the meanwhile our 'tail' process gives us: - - > user ojgg: authentication failure for "/": Password Mismatch - -====== - diff --git a/ldap2.asciidoci b/ldap2.asciidoci new file mode 100644 index 0000000..76ee056 --- /dev/null +++ b/ldap2.asciidoci @@ -0,0 +1,156 @@ +== OpenLDAP Practical 2, Week 7 == + +This practical is about configuring Apache so that it uses our OpenLDAP +directory to accept or deny HTTP authentication requests. + +At the end of the practical, we should be able to add or remove users that are +allowed to authenticate on the website by adding or removing LDAP entries. + +=== Problem 1: Avoiding obsolete commands === + +The practical provides us some commands to, inter alia, configure Apache. +Nevertheless some of them are obsolete or deprecated. Here is a list of +obsolete ways and their prefered substitute: + +- enabling an Apache module by creating symlinks by hand. The recommended way + is to use the command 'a2enmod' which takes the name of the module (i.e. +without file extension) and generate the symlink(s) to the proper file(s) +itself. In our case, the command is: + + $ sudo a2enmod ldap + +- stopping, starting (that to say restarting) a service (i.e. Apache) on + Debian-like distributions can be achieved by using the command 'service'. In +addition to avoiding any risk of messing up anything inside the '/etc/init.d/' +directory, this tool first checks in '/etc/init' if there is an upstart job of +the same name. In our case, the command for restarting Apache is: + + $ sudo service apache2 restart + +- enabling an Apache site can be achieved using the command 'a2ensite' which is + very similar to 'a2enmod'. The advantage of this method is that it avoids the +risk of messing up with the precedence of the configuration files when enabling +multiple sites. + +=== Problem 2: Enabling the LDAP authentication module === + +After having a look at the documentation of 'mod_auth_ldap' (provided in the +'Supporting Information' section of the practical), we try to activate the +module with the command below but we are indeed facing an error: + + $ sudo a2enmod auth_ldap + > ERROR: Module auth_ldap does not exist! + +==== Resolution ==== + +The answer is actually somehow given at the very beginning of the documentation +of 'mod_auth_ldap': + +[verse] +This document refers to the 2.0 version of Apache httpd, which is no longer maintained. Upgrade, and refer to the current version of httpd instead, documented at [...] + +Following the given link and browsing to 'Authentication and Authorization' +suggests us another module (which we have): 'mod_authnz_ldap' which we can +successfully activate by issuing the following command and then restarting +Apache. + + $ sudo a2enmod authnz_ldap + +=== Problem 3: Configuring the authentication mechanism === + +After configuring Apache so that the authentication can be overriden in +'.htaccess' files (similarly to what we did in Apache Practical), we have to +figure out what directives to write in our '.htaccess' file to handle HTTP +authentication using LDAP. + +The documentation of 'mod_authnz_ldap' covers almost every information we need. +Since we think that allowing only the users whose 'permisRole' is set to +'staff' to access the website, we construct our '.htaccess' file this way: + + AuthBasicProvider ldap + AuthLDAPURL "ldap://localhost/ou=MSc ISB,o=University of Kent,c=gb?uid?one" + Require ldap-attribute permisRole=staff + +Nevertheless, when we try to access the website, we get an 'Internal Server +Error'. + +==== Resolution ==== + +To understand what is going wrong, we can read the end of the file +'/var/log/apache2/error.log'. More preferably, we can run the following command +on another terminal (or as a background process) so that we will be informed of +any other error that we will encounter afterwards: + + $ tail -f /var/log/apache2/error.log + > configuration error: couldn't perform authentication. AuthType not set!: / + +The output is rather clear, we need to add the authentication type (which is +still 'Basic' in our case). + +After another attempt with another 'Internal Server Error', our 'tail' running +process gives us this output + + > need AuthName: / + +The output is once again rather clear, we just have to add a authentication +name of our choice. + +After those modifications, our '.htaccess' looks something like this: + + AuthType Basic + AuthName "You need to authenticate with a LDAP entry" + AuthBasicProvider ldap + AuthLDAPURL "ldap://localhost/ou=MSc ISB,o=University of Kent,c=gb?uid?one" + Require ldap-attribute permisRole=staff + +=== Problem 4: Testing our authentication === + +We still need to test our authentication to validate its proper functioning. +For that purpose, we have to add at least another entry in the LDAP directory +and run some tests using 'curl'. + +==== Resolution ==== + +First, we will add another user (whose 'permisRole' is 'staff'). The input that +we have to provide to 'ldapadd' is the following: + + dn: cn=Olivier Gayot Staff,ou=MSc ISB,o=University of Kent,c=gb + objectClass: organizationalPerson + objectClass: pkiUser + objectClass: pmiUser + objectClass: uidObject + sn: gayot + uid: ojgg + userPassword: fooBar + permisRole: staff + +Using 'curl' the same way we did in the Apache practical, we can run some tests (only interesting excerpts of the output are shown below): + +.trying (with success) to authenticate using the staff account +====== + + $ curl http://csvm2c4e.kent.ac.uk -u 'ojgg:fooBar' + >

It works!

+ +====== + +.trying (without success) to authenticate using the student account +====== + + $ curl http://csvm2c4e.kent.ac.uk -u 'ojgg2:fooBar' + > 401 Authorization Required + +====== + +.trying (without success) to authenticate with a wrong password +====== + + $ curl http://csvm2c4e.kent.ac.uk -u 'ojgg:wrongPassword' + > 401 Authorization Required + +In the meanwhile our 'tail' process gives us: + + > user ojgg: authentication failure for "/": Password Mismatch + +====== + diff --git a/pgp.adoci b/pgp.adoci deleted file mode 100644 index ec226e1..0000000 --- a/pgp.adoci +++ /dev/null @@ -1,75 +0,0 @@ -== PGPv8 Practical, Week 11 == - -The purpose of this practical is to learn how to use PGP for encrypting and -decrypting data. - -At the end of the practical, we should be able to verify the authenticity of -emails using digital signatures. Moreover, we should be able to encrypt emails -so that only the desired people can decrypt them. - -=== Problem 1: generating enough entropy === - -Because entropy is mainly generated by hardware components, it is quite -difficult to generate it quickly on a virtual machine which lacks hardware -access. - -To generate our key quickly, we generate it (using 'gpg --gen-key') on a -dedicated machine. But then we have to find a way to export it to our VM (using -a trusted channel). - -==== Resolution ==== - -A quick look at the manpage 'gpg (1)' gives us the following commands -('D417B848' being our key ID). 'gpg' will prompt us our passphrase. - - $ gpg --export-secret-keys D417B348 > key.asc - -Then, using 'rsync', we can upload our 'key.asc' file. - -Last but not least, back to our virtual machine, we can import the key using: - - $ gpg --import key.asc - -=== Problem 2: testing the key to sign an email === - -We will now try to sign an email with our private key and see if a client can -verify our signature depending if he possesses our public key or not. - -==== Resolution ==== - -Using 'mutt', we send en email signed with our private key. On another machine, -we use it again to fetch the new emails. 'mutt' gives us the following warning: - - > gpg: Signature made Sat 17 Jan 2015 14:45:31 GMT using RSA key ID D417B348 - > gpg: Can't check signature: public key not found - -That output confirms us that this client cannot verify our signature because he -does not possess our public key. We will now install it on his machine using: - - $ gpg --recv-keys --keyserver keyserver.ubuntu.com D417B348 - -This time, 'mutt' gives us the following information: - - > PGP signature successfully verified. - -=== Problem 3: testing the key to encrypt an email === - -This time, we want to encrypt an email with someone's public key so that only -the ones possessing the associated private key will be able to decrypt it. - -==== Resolution ==== - -Using, 'mutt', we encrypt the following email using the public key 'D417B348' -and send it to an account accessible from our virtual machine. - - > Can you see this content ? - -On the virtual machine, 'mutt' prompts us our passphrase. After entering it, we -obtain the following decrypted output which confirms that we just succeeded. - - > [-- The following data is PGP/MIME encrypted --] - > - > Can you see this content? - > - > [-- End of PGP/MIME encrypted data --] - diff --git a/pgp.asciidoci b/pgp.asciidoci new file mode 100644 index 0000000..ec226e1 --- /dev/null +++ b/pgp.asciidoci @@ -0,0 +1,75 @@ +== PGPv8 Practical, Week 11 == + +The purpose of this practical is to learn how to use PGP for encrypting and +decrypting data. + +At the end of the practical, we should be able to verify the authenticity of +emails using digital signatures. Moreover, we should be able to encrypt emails +so that only the desired people can decrypt them. + +=== Problem 1: generating enough entropy === + +Because entropy is mainly generated by hardware components, it is quite +difficult to generate it quickly on a virtual machine which lacks hardware +access. + +To generate our key quickly, we generate it (using 'gpg --gen-key') on a +dedicated machine. But then we have to find a way to export it to our VM (using +a trusted channel). + +==== Resolution ==== + +A quick look at the manpage 'gpg (1)' gives us the following commands +('D417B848' being our key ID). 'gpg' will prompt us our passphrase. + + $ gpg --export-secret-keys D417B348 > key.asc + +Then, using 'rsync', we can upload our 'key.asc' file. + +Last but not least, back to our virtual machine, we can import the key using: + + $ gpg --import key.asc + +=== Problem 2: testing the key to sign an email === + +We will now try to sign an email with our private key and see if a client can +verify our signature depending if he possesses our public key or not. + +==== Resolution ==== + +Using 'mutt', we send en email signed with our private key. On another machine, +we use it again to fetch the new emails. 'mutt' gives us the following warning: + + > gpg: Signature made Sat 17 Jan 2015 14:45:31 GMT using RSA key ID D417B348 + > gpg: Can't check signature: public key not found + +That output confirms us that this client cannot verify our signature because he +does not possess our public key. We will now install it on his machine using: + + $ gpg --recv-keys --keyserver keyserver.ubuntu.com D417B348 + +This time, 'mutt' gives us the following information: + + > PGP signature successfully verified. + +=== Problem 3: testing the key to encrypt an email === + +This time, we want to encrypt an email with someone's public key so that only +the ones possessing the associated private key will be able to decrypt it. + +==== Resolution ==== + +Using, 'mutt', we encrypt the following email using the public key 'D417B348' +and send it to an account accessible from our virtual machine. + + > Can you see this content ? + +On the virtual machine, 'mutt' prompts us our passphrase. After entering it, we +obtain the following decrypted output which confirms that we just succeeded. + + > [-- The following data is PGP/MIME encrypted --] + > + > Can you see this content? + > + > [-- End of PGP/MIME encrypted data --] + diff --git a/practicals.adoc b/practicals.adoc deleted file mode 100644 index ba3da4b..0000000 --- a/practicals.adoc +++ /dev/null @@ -1,10 +0,0 @@ -include::cover.adoci[] -include::apache.adoci[] -include::ldap1.adoci[] -include::ldap2.adoci[] -include::dns.adoci[] -include::ssl.adoci[] -include::firewall.adoci[] -include::pgp.adoci[] -include::smime.adoci[] -include::snort.adoci[] diff --git a/practicals.asciidoc b/practicals.asciidoc new file mode 100644 index 0000000..96f54c7 --- /dev/null +++ b/practicals.asciidoc @@ -0,0 +1,10 @@ +include::cover.asciidoci[] +include::apache.asciidoci[] +include::ldap1.asciidoci[] +include::ldap2.asciidoci[] +include::dns.asciidoci[] +include::ssl.asciidoci[] +include::firewall.asciidoci[] +include::pgp.asciidoci[] +include::smime.asciidoci[] +include::snort.asciidoci[] diff --git a/smime.adoci b/smime.adoci deleted file mode 100644 index 1ecf8e4..0000000 --- a/smime.adoci +++ /dev/null @@ -1,112 +0,0 @@ -== S/MIME Practical, Week 11 == - -As for PGP, the purpose of this practical is to show us how to use S/MIME to -encrypt, decrypt and digitally sign our emails. - -At the end of this practical, we should be able to send and receive emails with -assurance of the identity of the senders. We will also be able not to worry -whether someone else was able to read their content. - -=== Problem 1: Configuring S/MIME with mutt === - -Though the support of S/MIME is present in 'mutt', it appears that it is very -cumbersome to use. 'mutt' is expecting 'pkcs12' files (that we can produce with -'openssl pkcs12'). Nevertheless, for some reason, it complains about our -'pkcs12' files being not completely bagged. - -There is very few information about this issue on the web and most of the -results are quite irrelevant. - -==== Resolution ==== - -We will not use the builtin support of 'S/MIME' in 'mutt'. Instead, the manual -pages 'openssl (1)' and 'smime (1)' describe us how to generate our emails -using 'openssl smime'. - -The following command will create our email and encrypt it using -ojgg2@kent.ac.uk's public key. - - $ openssl smime -encrypt -out mail.p7m -from olivier.gayot@sigexec.com -to ojgg2@kent.ac.uk -subject "Encrypted message" -des3 certif.crt - This content is encrypted, can you read it? - -We can check that our email file is encrypted: - - $ cat mail.p7m - > To: ojgg2@kent.ac.uk - > From: olivier.gayot@sigexec.com - > Subject: Encrypted message - > MIME-Version: 1.0 - > Content-Disposition: attachment; filename="smime.p7m" - > Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" - > Content-Transfer-Encoding: base64 - > - > MIIBswYJKoZIhvcNAQcDoIIBpDCCAaACAQAxggFEMIIBQAIBADCBqDCBmjELMAkG - > A1UEBhMCRlIxETAPBgNVBAgMCExvcnJhaW5lMRMwEQYDVQQHDApCYXIgbGUgRHVj - > MSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFjAUBgNVBAMMDU9s - > aXZpZXIgR2F5b3QxKDAmBgkqhkiG9w0BCQEWGW9saXZpZXIuZ2F5b3RAc2lnZXhl - > Yy5jb20CCQD94c8uK91F/zANBgkqhkiG9w0BAQEFAASBgLOKi60Rw/B0ZJDk78/x - > T0lmSSYhzaIfRJp5SMiH0zFodQFYVW7qBXFI1mXveD0e2k+jLl3phlQb/MXz47AH - > 6pj4OeE4Q0N+0NHmmoFKbN5s8xwH/0hBaLkEAes+ZCG1YjaEoIkPcc5VrGIMceJm - > Vh9GZRSQWo77J8q4EGzpTkZtMFMGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQICCUR - > p0WUvGeAMMTU8q/foeWR6W+w9Wu0jBxHnEOEkjbTqDHasMbL6e0j1sGtKVY3eqtG - > uRoDPyq44Q== - -Using 'mutt', we can now send this email. We will then use 'openssl smime' -again on our recipient's machine to decrypt it using his private key. - - $ openssl smime -inkey private.key -decrypt -in mail.p7m - > This content is encrypted, can you read it? - - -=== Problem 2: Combining encryption and signature === - -What we want now is to encrypt the content of our message and sign it so that -the receiver can read the email and be sure as well that it comes from us. - -==== Resolution ==== - -We will start by encrypting our message the same way we did before. But then, -we will use 'openssl' again to sign it before actually sending it. For this -purpose, we could also use 'mutt'. However, we will use 'openssl smime' in this -example. - -Still having 'mail.p7m' be our encrypted message, the following command will -digitally sign it using the sender's private key: - - $ openssl smime -sign -inkey private.key -signer certif.pem -in mail.p7m -out signed_mail.p7m - -On the receiver's machine, we can now authenticate the sender using its public -certificate as a Certificate Authority: - - $ openssl smime -CAfile certif.pem -verify -in mail.p7m - > To: ojgg2@kent.ac.uk - > From: olivier.gayot@sigexec.com - > Subject: Encrypted message - > MIME-Version: 1.0 - > Content-Disposition: attachment; filename="smime.p7m" - > Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" - > Content-Transfer-Encoding: base64 - > - > MIIBswYJKoZIhvcNAQcDoIIBpDCCAaACAQAxggFEMIIBQAIBADCBqDCBmjELMAkG - > A1UEBhMCRlIxETAPBgNVBAgMCExvcnJhaW5lMRMwEQYDVQQHDApCYXIgbGUgRHVj - > MSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFjAUBgNVBAMMDU9s - > aXZpZXIgR2F5b3QxKDAmBgkqhkiG9w0BCQEWGW9saXZpZXIuZ2F5b3RAc2lnZXhl - > Yy5jb20CCQD94c8uK91F/zANBgkqhkiG9w0BAQEFAASBgHRgbsuN8NugJAzynX+9 - > tC300W0aqATHMsqXEzFJS4yA3PQDmgPpAL86iH/C5vAk9XQ1Fmnv0soIYaBTwqSH - > BraNZNKA90KvZPOAymGMVttCC7giWuBxzNOiruaPTnj9md0n9ps7/issftcj7VH6 - > DZ1ic+9pjn8bgThqFoxmsGkMMFMGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIHxER - > UbQa6bqAMEOXZgXTurgcRt74OMS4xeSf1j2Z5abj1PSWBg60ldsbyhVuR2+8wllN - > wNi5FtbKFg== - > - > Verification successful - -By reusing the same command as before to decrypt the file using 'openssl -smime', we can extract its content: - - > This content is encrypted, can you read it? - -Using this technique, we can be certain that the message comes from the people -we think and that no one was able to read the content unless they have our -private key. - - diff --git a/smime.asciidoci b/smime.asciidoci new file mode 100644 index 0000000..1ecf8e4 --- /dev/null +++ b/smime.asciidoci @@ -0,0 +1,112 @@ +== S/MIME Practical, Week 11 == + +As for PGP, the purpose of this practical is to show us how to use S/MIME to +encrypt, decrypt and digitally sign our emails. + +At the end of this practical, we should be able to send and receive emails with +assurance of the identity of the senders. We will also be able not to worry +whether someone else was able to read their content. + +=== Problem 1: Configuring S/MIME with mutt === + +Though the support of S/MIME is present in 'mutt', it appears that it is very +cumbersome to use. 'mutt' is expecting 'pkcs12' files (that we can produce with +'openssl pkcs12'). Nevertheless, for some reason, it complains about our +'pkcs12' files being not completely bagged. + +There is very few information about this issue on the web and most of the +results are quite irrelevant. + +==== Resolution ==== + +We will not use the builtin support of 'S/MIME' in 'mutt'. Instead, the manual +pages 'openssl (1)' and 'smime (1)' describe us how to generate our emails +using 'openssl smime'. + +The following command will create our email and encrypt it using +ojgg2@kent.ac.uk's public key. + + $ openssl smime -encrypt -out mail.p7m -from olivier.gayot@sigexec.com -to ojgg2@kent.ac.uk -subject "Encrypted message" -des3 certif.crt + This content is encrypted, can you read it? + +We can check that our email file is encrypted: + + $ cat mail.p7m + > To: ojgg2@kent.ac.uk + > From: olivier.gayot@sigexec.com + > Subject: Encrypted message + > MIME-Version: 1.0 + > Content-Disposition: attachment; filename="smime.p7m" + > Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" + > Content-Transfer-Encoding: base64 + > + > MIIBswYJKoZIhvcNAQcDoIIBpDCCAaACAQAxggFEMIIBQAIBADCBqDCBmjELMAkG + > A1UEBhMCRlIxETAPBgNVBAgMCExvcnJhaW5lMRMwEQYDVQQHDApCYXIgbGUgRHVj + > MSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFjAUBgNVBAMMDU9s + > aXZpZXIgR2F5b3QxKDAmBgkqhkiG9w0BCQEWGW9saXZpZXIuZ2F5b3RAc2lnZXhl + > Yy5jb20CCQD94c8uK91F/zANBgkqhkiG9w0BAQEFAASBgLOKi60Rw/B0ZJDk78/x + > T0lmSSYhzaIfRJp5SMiH0zFodQFYVW7qBXFI1mXveD0e2k+jLl3phlQb/MXz47AH + > 6pj4OeE4Q0N+0NHmmoFKbN5s8xwH/0hBaLkEAes+ZCG1YjaEoIkPcc5VrGIMceJm + > Vh9GZRSQWo77J8q4EGzpTkZtMFMGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQICCUR + > p0WUvGeAMMTU8q/foeWR6W+w9Wu0jBxHnEOEkjbTqDHasMbL6e0j1sGtKVY3eqtG + > uRoDPyq44Q== + +Using 'mutt', we can now send this email. We will then use 'openssl smime' +again on our recipient's machine to decrypt it using his private key. + + $ openssl smime -inkey private.key -decrypt -in mail.p7m + > This content is encrypted, can you read it? + + +=== Problem 2: Combining encryption and signature === + +What we want now is to encrypt the content of our message and sign it so that +the receiver can read the email and be sure as well that it comes from us. + +==== Resolution ==== + +We will start by encrypting our message the same way we did before. But then, +we will use 'openssl' again to sign it before actually sending it. For this +purpose, we could also use 'mutt'. However, we will use 'openssl smime' in this +example. + +Still having 'mail.p7m' be our encrypted message, the following command will +digitally sign it using the sender's private key: + + $ openssl smime -sign -inkey private.key -signer certif.pem -in mail.p7m -out signed_mail.p7m + +On the receiver's machine, we can now authenticate the sender using its public +certificate as a Certificate Authority: + + $ openssl smime -CAfile certif.pem -verify -in mail.p7m + > To: ojgg2@kent.ac.uk + > From: olivier.gayot@sigexec.com + > Subject: Encrypted message + > MIME-Version: 1.0 + > Content-Disposition: attachment; filename="smime.p7m" + > Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" + > Content-Transfer-Encoding: base64 + > + > MIIBswYJKoZIhvcNAQcDoIIBpDCCAaACAQAxggFEMIIBQAIBADCBqDCBmjELMAkG + > A1UEBhMCRlIxETAPBgNVBAgMCExvcnJhaW5lMRMwEQYDVQQHDApCYXIgbGUgRHVj + > MSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxFjAUBgNVBAMMDU9s + > aXZpZXIgR2F5b3QxKDAmBgkqhkiG9w0BCQEWGW9saXZpZXIuZ2F5b3RAc2lnZXhl + > Yy5jb20CCQD94c8uK91F/zANBgkqhkiG9w0BAQEFAASBgHRgbsuN8NugJAzynX+9 + > tC300W0aqATHMsqXEzFJS4yA3PQDmgPpAL86iH/C5vAk9XQ1Fmnv0soIYaBTwqSH + > BraNZNKA90KvZPOAymGMVttCC7giWuBxzNOiruaPTnj9md0n9ps7/issftcj7VH6 + > DZ1ic+9pjn8bgThqFoxmsGkMMFMGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIHxER + > UbQa6bqAMEOXZgXTurgcRt74OMS4xeSf1j2Z5abj1PSWBg60ldsbyhVuR2+8wllN + > wNi5FtbKFg== + > + > Verification successful + +By reusing the same command as before to decrypt the file using 'openssl +smime', we can extract its content: + + > This content is encrypted, can you read it? + +Using this technique, we can be certain that the message comes from the people +we think and that no one was able to read the content unless they have our +private key. + + diff --git a/snort.adoci b/snort.adoci deleted file mode 100644 index 7592940..0000000 --- a/snort.adoci +++ /dev/null @@ -1,66 +0,0 @@ -== Snort Practical, Week 12 == - -The goal of this practical is to let us discover what intrusion detection -systems are and start to practice using the Snort implementation. - -At the end of the practical, we should be able to write and understand simple -rules to detect and react to abnormal behaviour on our network. - -=== Problem 1: Fresh install configuration issues === - -After installing Snort using our package manager, the configuration check fails -because a variable in the file '/etc/snort/snort.conf' appears not to be set to -a valid value. - -==== Resolution ==== - -The header of the so called file describes us the steps to create our -configuration. A 'README.variables' file is advised to be read. However, it is -not present on our machine. To get it, we have to install the package -'snort-doc' (we can use 'apt-get' to achieve that). - -We can fix the configuration issue by setting 'HOME_NET' to our IP address -given by 'ifconfig eth0'. - -=== Problem 2: Creating our own rules === - -The manpage 'snort (8)' tells us that we can use the '-c' option to use our own -rules. In our case, the command line to start 'snort' with our own rules is: - - $ sudo snort -c 'custom.rules' -l $HOME/logs -i eth0 - -All we have to do now is fill the file 'custom.rules' with our custom rules. - -==== Resolution ==== - -The file 'Snort.pdf' from 'www.seren.net' and linked in the practical provides -us the syntax of a rule, which is: - ----- - function protocol source_ip source_port -> dest_ip dest_port [options] ----- - -To create a rule which simply alerts whenever a TCP packet is transmitted to -our HTTP server, we don't need any option so we will leave the field blank. The -following rule does what we intend. - - alert tcp any any -> $HOME_NET 80 - -Doing the same for HTTPS is very similar. We will append the message 'secured -website' to the alert though. - - alert tcp any any -> $HOME_NET 443 (msg:"secured website"; sid:1) - -Using the following rule, we can alert whenever a TCP packet is transmitted to -our web server using SSL or not. - - alert tcp any any -> $HOME_NET [80,443] - -Last but not least, if we want to alert only when packets are transmitted to -our port 443 and come from outside the university, we will use: - - alert tcp 129.12.0.0/16 any -> $HOME_net 443 - -Having '129.12.0.0/16' be an alternate notation of '129.12.0.0' with a mask of -'255.255.0.0'. - diff --git a/snort.asciidoci b/snort.asciidoci new file mode 100644 index 0000000..7592940 --- /dev/null +++ b/snort.asciidoci @@ -0,0 +1,66 @@ +== Snort Practical, Week 12 == + +The goal of this practical is to let us discover what intrusion detection +systems are and start to practice using the Snort implementation. + +At the end of the practical, we should be able to write and understand simple +rules to detect and react to abnormal behaviour on our network. + +=== Problem 1: Fresh install configuration issues === + +After installing Snort using our package manager, the configuration check fails +because a variable in the file '/etc/snort/snort.conf' appears not to be set to +a valid value. + +==== Resolution ==== + +The header of the so called file describes us the steps to create our +configuration. A 'README.variables' file is advised to be read. However, it is +not present on our machine. To get it, we have to install the package +'snort-doc' (we can use 'apt-get' to achieve that). + +We can fix the configuration issue by setting 'HOME_NET' to our IP address +given by 'ifconfig eth0'. + +=== Problem 2: Creating our own rules === + +The manpage 'snort (8)' tells us that we can use the '-c' option to use our own +rules. In our case, the command line to start 'snort' with our own rules is: + + $ sudo snort -c 'custom.rules' -l $HOME/logs -i eth0 + +All we have to do now is fill the file 'custom.rules' with our custom rules. + +==== Resolution ==== + +The file 'Snort.pdf' from 'www.seren.net' and linked in the practical provides +us the syntax of a rule, which is: + +---- + function protocol source_ip source_port -> dest_ip dest_port [options] +---- + +To create a rule which simply alerts whenever a TCP packet is transmitted to +our HTTP server, we don't need any option so we will leave the field blank. The +following rule does what we intend. + + alert tcp any any -> $HOME_NET 80 + +Doing the same for HTTPS is very similar. We will append the message 'secured +website' to the alert though. + + alert tcp any any -> $HOME_NET 443 (msg:"secured website"; sid:1) + +Using the following rule, we can alert whenever a TCP packet is transmitted to +our web server using SSL or not. + + alert tcp any any -> $HOME_NET [80,443] + +Last but not least, if we want to alert only when packets are transmitted to +our port 443 and come from outside the university, we will use: + + alert tcp 129.12.0.0/16 any -> $HOME_net 443 + +Having '129.12.0.0/16' be an alternate notation of '129.12.0.0' with a mask of +'255.255.0.0'. + diff --git a/ssl.adoci b/ssl.adoci deleted file mode 100644 index 87c9ef1..0000000 --- a/ssl.adoci +++ /dev/null @@ -1,101 +0,0 @@ -== SSL Practical, Week 9 == - -The purpose of this practical is to provide a secure way to communicate with -our website. We will use SSL over HTTP for this purpose. - -At this end of the practical, we should be able to avoid any attempt of -intercepting or altering our communications with our website when using the -SSL layer. - -=== Problem 1: Passing the certificate out of band === - -Using HTTP in order to send our certificate seems to be a very bad idea. -Indeed, if a user is tampering our connection at the time the certificate is -sent, he will be able to send to replace our certificate with a rogue crafted -one. - -Since the purpose of using SSL over HTTP is exactly to avoid this king of -attack, it seems very important to use a secure channel to send our -certificate. - -==== Resolution ==== - -Instead of using HTTP to send our certificate, we will use a trusted channel. -Since we use SSH to access our virtual machine, we will use it to retrieve the -certificate as well. - - $ rsync csvm2c4e.kent.ac.uk:rootCA.crt . - > rootCA.crt - > 1,415 100% 1.35MB/s 0:00:00 (xfr#1, to-chk=0/1) - -Now we can add our 'rootCA.crt' file to the list of trusted CA of our web -browser. - -Otherwise, we can use 'curl' directly: - -.trying to access the secure website without giving the CA certificate -====== - - $ curl https://csvm2c4e.kent.ac.uk - > curl: (60) SSL certificate problem: self signed certificate - -====== - -.trying to access the secure website using the CA certificate -====== - - $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt - >

It works!

Common Name (e.g. server FQDN or YOUR name) []: - -we actually need to enter our FQDN (Fully Qualified Domain Name) so that -'Firefox' stops complaining. We can figure our what our FQDN is by issuing the -following command on our virtual machine. - - $ hostname --fqdn - > csvm2C4E.kent.ac.uk - -Then, by regenerating our certificate with 'csvm2C4E.kent.ac.uk' as 'Common -Name', 'Firefox' feels better. - -=== Problem 3: Testing our security === - -What we would like to know now is what would happen if someones is altering our -connection and trying to redirect our traffic to a rogue web server. - -==== Resolution ==== - -We will use the file '/etc/hosts' to override the IP address of our web server. -By adding the following line inside, we force our resolver to assume that the -IP address of 'csvm2c4e.kent.ac.uk' is '104.130.219.184' (which is in fact the -IP address of 'httpd.apache.org'). - - 104.130.219.184 csvm2c4e.kent.ac.uk - -We can check that our entry has been taken into account: - - $ resolveip csvm2c4e.kent.ac.uk - > IP address of csvm2c4e.kent.ac.uk is 104.130.219.184 - -So now, we try to access the website using our CA certificate: - - $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt - > curl: (60) SSL certificate problem: unable to get local issuer certificate - -Our security layer seems to work! - diff --git a/ssl.asciidoci b/ssl.asciidoci new file mode 100644 index 0000000..87c9ef1 --- /dev/null +++ b/ssl.asciidoci @@ -0,0 +1,101 @@ +== SSL Practical, Week 9 == + +The purpose of this practical is to provide a secure way to communicate with +our website. We will use SSL over HTTP for this purpose. + +At this end of the practical, we should be able to avoid any attempt of +intercepting or altering our communications with our website when using the +SSL layer. + +=== Problem 1: Passing the certificate out of band === + +Using HTTP in order to send our certificate seems to be a very bad idea. +Indeed, if a user is tampering our connection at the time the certificate is +sent, he will be able to send to replace our certificate with a rogue crafted +one. + +Since the purpose of using SSL over HTTP is exactly to avoid this king of +attack, it seems very important to use a secure channel to send our +certificate. + +==== Resolution ==== + +Instead of using HTTP to send our certificate, we will use a trusted channel. +Since we use SSH to access our virtual machine, we will use it to retrieve the +certificate as well. + + $ rsync csvm2c4e.kent.ac.uk:rootCA.crt . + > rootCA.crt + > 1,415 100% 1.35MB/s 0:00:00 (xfr#1, to-chk=0/1) + +Now we can add our 'rootCA.crt' file to the list of trusted CA of our web +browser. + +Otherwise, we can use 'curl' directly: + +.trying to access the secure website without giving the CA certificate +====== + + $ curl https://csvm2c4e.kent.ac.uk + > curl: (60) SSL certificate problem: self signed certificate + +====== + +.trying to access the secure website using the CA certificate +====== + + $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt + >

It works!

Common Name (e.g. server FQDN or YOUR name) []: + +we actually need to enter our FQDN (Fully Qualified Domain Name) so that +'Firefox' stops complaining. We can figure our what our FQDN is by issuing the +following command on our virtual machine. + + $ hostname --fqdn + > csvm2C4E.kent.ac.uk + +Then, by regenerating our certificate with 'csvm2C4E.kent.ac.uk' as 'Common +Name', 'Firefox' feels better. + +=== Problem 3: Testing our security === + +What we would like to know now is what would happen if someones is altering our +connection and trying to redirect our traffic to a rogue web server. + +==== Resolution ==== + +We will use the file '/etc/hosts' to override the IP address of our web server. +By adding the following line inside, we force our resolver to assume that the +IP address of 'csvm2c4e.kent.ac.uk' is '104.130.219.184' (which is in fact the +IP address of 'httpd.apache.org'). + + 104.130.219.184 csvm2c4e.kent.ac.uk + +We can check that our entry has been taken into account: + + $ resolveip csvm2c4e.kent.ac.uk + > IP address of csvm2c4e.kent.ac.uk is 104.130.219.184 + +So now, we try to access the website using our CA certificate: + + $ curl https://csvm2c4e.kent.ac.uk --cacert rootCA.crt + > curl: (60) SSL certificate problem: unable to get local issuer certificate + +Our security layer seems to work! + -- cgit v1.2.3