summaryrefslogtreecommitdiffstats
path: root/notFinishedCode/Report/test.tex~
diff options
context:
space:
mode:
Diffstat (limited to 'notFinishedCode/Report/test.tex~')
-rw-r--r--notFinishedCode/Report/test.tex~32
1 files changed, 21 insertions, 11 deletions
diff --git a/notFinishedCode/Report/test.tex~ b/notFinishedCode/Report/test.tex~
index 8bf4a2d..40dc5c1 100644
--- a/notFinishedCode/Report/test.tex~
+++ b/notFinishedCode/Report/test.tex~
@@ -98,7 +98,7 @@ Prof. Dr. Gerhard Schneider\\ \vspace{1\baselineskip} Supervisors: \\ Konrad Mei
% first chapter
\section{Introduction and Motivation} % chapter 1
-\Large In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of: our own internal GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for landline calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems and infer the results out of our findings.
+\large In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of: our own internal GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for landline calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems and infer the results out of our findings.
Before we had started working on our project, we had to analyze the overall network to come up with test cases that contain the highest information content. The next step in our procedure was to implement our ideas into a working piece of software.
Gradually we implemented a bit-by-bit of the final software. Every single step was accompanied by testing and validation procedures. At the end we connected all the ``black-boxes'' into one big piece of software. We have fulfilled our requests and goals and made a fully working and operable test software. Despite developing a working software, all the way along we thought about the simplicity of the usage of the software. In the following chapters we will describe in more detail our approach and how each subsystem works.
\newpage
@@ -136,27 +136,27 @@ Gradually we implemented a bit-by-bit of the final software. Every single step w
%\newpage
\section{Security and safety of the test system}
-\Large Safety and security of the software plays a major role in our project.
+\large Safety and security of the software plays a major role in our project.
It is of vital importance that only as few as possible people have access to our test system since the resulting data could be exploited to plan an attack
(e.g. assume the University alarm system uses the SIP gateway to connect to the outside world and to alarm the police, if one knows that the SIP gateway is not working properly, a burglar could plan to rob the University building just at that moment.) Therefore the choice to go Open Source is justified due to the fact that one should know how every single detail of the system works.
All the time, while we were working on the project, we were made aware of this issue by Denis and Konrad.
We decided to use asymmetric key cryptography, where each side has two keys (private and public.) In the next sections we will explain in more details how we applied the methods.
\subsection{Encryption of the communication channels}
-At first we thoought to encrypt the data before sending them but since none of us was an expert on encryption standards the idea was rejected. Alongside the fact that none of us had been an expert in the field of cryptography, we were not experts in the field of internet programming either. One could find maybe a way to disable our server software with various hacking methods (e.g.
-trying to open the port until the system runs out of memory and in our case the system which we used on the server side was a BeagleBoard with ARM architecture running on a single chip TI OMAP processor, refer to the picture on figure 1.)
+At first we thoought to encrypt the data before sending them but since none of us was an expert on encryption standards the idea was rejected. Alongside the fact that none of us had been an expert in the field of cryptography, we were neither experts in the field of internet programming. One could find maybe a way to disable our server software with various hacking methods (e.g.
+trying to open the port until the system runs out of memory and in our case the system which we used on the handler side was a BeagleBoard with ARM architecture running on a single chip TI OMAP processor, refer to the picture in figure 1.)
We had to eliminate even the slightest possible threat in return for spending more time for debugging the test software system. Despite we were aware of all these facts, we had to choose one of the plenty implemented encryption standards on Linux.
Denis and Konrad suggested using the SSH Tunneling method.
\begin{figure}[ht!]
\centering
\includegraphics[width=120mm]{sshTunnel.png}
- \caption[]{SSH Tunnel, }
+ \caption[]{SSH Tunnel, all the communication inside the tunnel is encrypted }
\end{figure}
-Using the SSH Tunnel port forwading method we could hide the real port we use for our socket connection on the other hand we could force the socket to accept only local connections (i.e. from the machine where the handler software was running.)
-The first problem we faced was that SSH required the username and password everytime we tried to make an SSH Tunnel port forwarding. We could avoid this problem by copying the public key from our server (where our test software runs) to the BeagleBoard \cite{sshTunnel}.
+Using the SSH Tunnel port forwading method we could hide the real port we had used for our socket connection. On the other hand we could force the socket to accept only local connections (i.e. from the machine where the handler software was running.)
+The SSH Tunnel port forwarind method creates an encrypted tunnel between the two computers and then it creates two ports, one on the local and remote computer. All the data sent through the port on the local machine appear on the port at the remote machine. \newline The first problem we faced was that SSH required the username and password everytime we tried to make an SSH connection. We could avoid this problem by copying the public key from our server (where our test software runs) to the BeagleBoard \cite{sshTunnel}.
This can be performed by executing the following commands in the terminal shell.
-One has to create first the private and public keys on the local machine(i.e. server machine, where the test software runs):
+One has to create first the private and public keys on the local machine(i.e. server computer, where the test software runs):
\begin{lstlisting}
jsmith@local-host$ [Note: You are on local-host here]
@@ -193,9 +193,16 @@ Last login: Sun Nov 16 17:22:33 2008 from 192.168.1.2
jsmith@remote-host$ [Note: You are on remote-host here]
\end{lstlisting}
-
-
-
+The test was successful. We tested it with our SSH Tunnel port forwarding class and it worked perfectly.
+\subsection{Security on the web site}
+Securing the communication channels without making certain the web site is safe would be worthless.
+We decided to use the \emph{https} protocol instead of the \emph{http} since a person in the middle
+could sniff our data (e.g. a person is connected with his/her smart-phone over an unprotected WiFi network).
+At the same time the web site should be accessible only by the authorized personel. Our first approach to this
+problem was to build an PHP page with \emph{MD5} hashed passwords, however we got a suggestion by Konrad and Denis to
+use a safer encryption method implemented in the Apache web server software, \emph{.htaccess}. By using
+these two techniques we protected the web site of some vulnerabilities known to us. If the web site
+will be only accessed from our local university network, we can additionally add an IP filter mask as well.
\newpage
\section{Web page}
@@ -219,6 +226,9 @@ Hypothesis}, preprint (2003), available at
\bibitem{sshTunnel} R. Natarajan, \emph{3 Steps to perform SSH login without password using ssh-keygen \& ssh-copy-id}, accessed on 18.08.2011, available at
\url{http://goo.gl/fX68N}.
+\bibitem{https} P. Bramscher, \emph{Creating Certificate Authorities and self-signed SSL certificates}, accessed on 05.09.2011, available at
+\url{http://www.tc.umn.edu/~brams006/selfsign.html}.
+
%bibliography end
\end{thebibliography}