Initial Overleaf Import
This commit is contained in:
Luke Tainton
commit
d7eaffe354
1700
bib/BCU.bst
Normal file
1700
bib/BCU.bst
Normal file
File diff suppressed because it is too large
Load Diff
368
bib/bibliography.bib
Normal file
368
bib/bibliography.bib
Normal file
@ -0,0 +1,368 @@
|
|||||||
|
@inproceedings {211239,
|
||||||
|
author = {Li Chen and Jiacheng Xia and Bairen Yi and Kai Chen},
|
||||||
|
title = {PowerMan: An Out-of-Band Management Network for Datacenters Using Power Line Communication},
|
||||||
|
booktitle = {15th {USENIX} Symposium on Networked Systems Design and Implementation ({NSDI} 18)},
|
||||||
|
year = {2018},
|
||||||
|
isbn = {978-1-939133-01-4},
|
||||||
|
address = {Renton, WA},
|
||||||
|
pages = {561--578},
|
||||||
|
url = {https://www.usenix.org/conference/nsdi18/presentation/chen-li},
|
||||||
|
publisher = {{USENIX} Association},
|
||||||
|
month = apr,
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{emmert_out--band_2015,
|
||||||
|
title = {Out-of-{Band} {Network} {Management}},
|
||||||
|
volume = {69},
|
||||||
|
url = {https://doi.org/10.2313/NET-2015-03-1_10},
|
||||||
|
doi = {10.2313/NET-2015-03-1_10},
|
||||||
|
journal = {Network Architectures and Services},
|
||||||
|
author = {Emmert, Felix},
|
||||||
|
collaborator = {Gasser, Oliver},
|
||||||
|
month = mar,
|
||||||
|
year = {2015},
|
||||||
|
pages = {69--75}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{pruett_bladecenter_2005,
|
||||||
|
title = {{BladeCenter} systems management software},
|
||||||
|
volume = {49},
|
||||||
|
issn = {00188646},
|
||||||
|
url = {https://search-proquest-com.ezproxy.bcu.ac.uk/docview/220687956},
|
||||||
|
language = {English},
|
||||||
|
number = {6},
|
||||||
|
journal = {IBM Journal of Research and Development},
|
||||||
|
author = {Pruett, G. and Abbondanzio, A. and Bielski, J. and Fadale, T. D. and Merkin, A. E. and Rafalovich, Z. and Riedle, L. A. and Simpson, J. W.},
|
||||||
|
month = nov,
|
||||||
|
year = {2005},
|
||||||
|
note = {tex.isbn: 00188646},
|
||||||
|
pages = {963--975}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{7027493,
|
||||||
|
address = {London, UK},
|
||||||
|
title = {The continuity of out-of-band remote management across virtual machine migration in clouds},
|
||||||
|
isbn = {978-1-4799-7881-6},
|
||||||
|
url = {https://ieeexplore-ieee-org.ezproxy.bcu.ac.uk/document/7027493},
|
||||||
|
doi = {10.1109/UCC.2014.26},
|
||||||
|
urldate = {11 March 2020},
|
||||||
|
booktitle = {2014 {IEEE}/{ACM} 7th international conference on utility and cloud computing},
|
||||||
|
publisher = {IEEE},
|
||||||
|
author = {Kawahara, S. and Kourai, K.},
|
||||||
|
month = dec,
|
||||||
|
year = {2014},
|
||||||
|
pages = {176--185}
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{outpost_sentinel_band_2004,
|
||||||
|
type = {Blog},
|
||||||
|
title = {In {Band} / {Out} of {Band} {Network} {Access}},
|
||||||
|
url = {http://www.outpostsentinel.com/inband.shtml},
|
||||||
|
urldate = {30 November 2019},
|
||||||
|
journal = {Outpost Sentinel},
|
||||||
|
author = {{Outpost Sentinel}},
|
||||||
|
month = feb,
|
||||||
|
year = {2004}
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{educba_c_2018,
|
||||||
|
type = {Blog},
|
||||||
|
title = {C++ vs {Java} - {Know} {The} {Top} 8 {Most} {Important} {Differences}},
|
||||||
|
url = {https://www.educba.com/c-plus-plus-vs-java/},
|
||||||
|
abstract = {In this article C++ vs Java , we will look after their meaning, head to head comparisons, Key differences, conclusion in a relatively easy and simple ways},
|
||||||
|
language = {en-US},
|
||||||
|
urldate = {28 November 2019},
|
||||||
|
journal = {EDUCBA},
|
||||||
|
author = {{EDUCBA}},
|
||||||
|
month = jun,
|
||||||
|
year = {2018},
|
||||||
|
note = {Library Catalog: www.educba.com
|
||||||
|
Section: Top Differences Tutorial}
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{mcafee_what_2014,
|
||||||
|
type = {Blog},
|
||||||
|
title = {What is {Wardriving}?},
|
||||||
|
url = {https://securingtomorrow.mcafee.com/blogs/consumer/identity-protection/wardriving},
|
||||||
|
language = {en-US},
|
||||||
|
urldate = {28 November 2019},
|
||||||
|
journal = {McAfee Blogs},
|
||||||
|
author = {{McAfee}},
|
||||||
|
month = jun,
|
||||||
|
year = {2014},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{386580,
|
||||||
|
title = {Network management's impact on managed networks},
|
||||||
|
url = {https://ieeexplore-ieee-org.ezproxy.bcu.ac.uk/document/386580},
|
||||||
|
doi = {10.1109/LCN.1994.386580},
|
||||||
|
booktitle = {Proceedings of 19th conference on local computer networks},
|
||||||
|
author = {Amley, C.},
|
||||||
|
month = oct,
|
||||||
|
year = {1994},
|
||||||
|
pages = {404-410}
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{lonergan_agile_2016,
|
||||||
|
type = {Blog},
|
||||||
|
title = {Agile versus {Waterfall}: pros and cons \& difference between them},
|
||||||
|
shorttitle = {Agile versus {Waterfall}},
|
||||||
|
url = {https://www.pmis-consulting.com/agile-versus-waterfall/},
|
||||||
|
language = {en-GB},
|
||||||
|
urldate = {22 November 2019},
|
||||||
|
journal = {Agile versus Waterfall: pros and cons \& difference between them},
|
||||||
|
author = {Lonergan, Kevin},
|
||||||
|
month = may,
|
||||||
|
year = {2016},
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{ieee-5975176,
|
||||||
|
title = {What do we know about the effectiveness of software design patterns?},
|
||||||
|
volume = {38},
|
||||||
|
issn = {2326-3881},
|
||||||
|
doi = {10.1109/TSE.2011.79},
|
||||||
|
number = {5},
|
||||||
|
journal = {IEEE Transactions on Software Engineering},
|
||||||
|
author = {Zhang, Cheng and Budgen, David},
|
||||||
|
month = sep,
|
||||||
|
year = {2012},
|
||||||
|
pages = {1213-1231}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{gonccales2019comparison,
|
||||||
|
title = {Comparison of software design models: {An} extended systematic mapping study},
|
||||||
|
volume = {52},
|
||||||
|
issn = {0360-0300},
|
||||||
|
url = {https://doi.org/10.1145/3313801},
|
||||||
|
doi = {10.1145/3313801},
|
||||||
|
number = {3},
|
||||||
|
journal = {ACM Computing Surveys (CSUR)},
|
||||||
|
author = {Gonçales, Lucian José and Farias, Kleinner and Oliveira, Toacy Cavalcante De and Scholl, Murilo},
|
||||||
|
month = jul,
|
||||||
|
year = {2019},
|
||||||
|
note = {tex.publisher: ACM New York, NY, USA},
|
||||||
|
pages = {1-41}
|
||||||
|
}
|
||||||
|
|
||||||
|
@book{budgen2003software,
|
||||||
|
address = {Essex, UK},
|
||||||
|
edition = {2},
|
||||||
|
title = {Software {Design}},
|
||||||
|
isbn = {0-201-72219-4},
|
||||||
|
publisher = {Pearson Education},
|
||||||
|
author = {Budgen, David},
|
||||||
|
year = {2003}
|
||||||
|
}
|
||||||
|
|
||||||
|
@incollection{sep-physics-experiment,
|
||||||
|
edition = {Winter 2019},
|
||||||
|
title = {Experiment in {Physics}},
|
||||||
|
url = {https://plato.stanford.edu/archives/win2019/entries/physics-experiment},
|
||||||
|
booktitle = {The {Stanford} {Encyclopedia} of {Philosophy}},
|
||||||
|
publisher = {Metaphysics Research Lab, Stanford University},
|
||||||
|
author = {Franklin, Allan and Perovic, Slobodan},
|
||||||
|
editor = {Zalta, Edward N.},
|
||||||
|
year = {2019}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{1274255,
|
||||||
|
address = {Penang, Malaysia},
|
||||||
|
title = {Transport layer security protocol in {Telnet}},
|
||||||
|
volume = {3},
|
||||||
|
url = {https://ieeexplore.ieee.org/abstract/document/1274255},
|
||||||
|
doi = {10.1109/APCC.2003.1274255},
|
||||||
|
publisher = {IEEE},
|
||||||
|
author = {Haslina Binti Mahmood},
|
||||||
|
month = {September},
|
||||||
|
year = {2003},
|
||||||
|
pages = {1033--1037},
|
||||||
|
booktitle = {9th Asia-Pacific Conference on Communications},
|
||||||
|
}
|
||||||
|
|
||||||
|
@techreport{cisco-ha,
|
||||||
|
title = {How {Cisco} {IT}-{LAN}-{SJ} achieved high availability},
|
||||||
|
url = {https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/downloads/ciscoitatwork/pdf/cisco_it_high_availability.pdf},
|
||||||
|
urldate = {09 November 2019},
|
||||||
|
institution = {Cisco Systems},
|
||||||
|
author = {{Cisco IT}},
|
||||||
|
year = {2003}
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{stormboard_your_2018,
|
||||||
|
type = {Blog},
|
||||||
|
title = {Your {Guide} to {Using} {Stormboard} {For} {Kanban}},
|
||||||
|
url = {https://stormboard.com/blog-archive/your-guide-to-using-stormboard-for-kanban},
|
||||||
|
urldate = {08 November 2019},
|
||||||
|
journal = {Stormboard Blog},
|
||||||
|
author = {{Stormboard}},
|
||||||
|
month = sep,
|
||||||
|
year = {2018}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{eweek_cyclades_2005,
|
||||||
|
title = {Cyclades {Extends} {Out}-of-{Band} {Management} to {Remote} {Offices}},
|
||||||
|
issn = {15306283},
|
||||||
|
url = {https://link.gale.com/apps/doc/A132116999/AONE?u=uce&sid=AONE&xid=3ca148f9},
|
||||||
|
language = {English},
|
||||||
|
urldate = {06 November 2019},
|
||||||
|
journal = {eWeek},
|
||||||
|
author = {{eWeek}},
|
||||||
|
month = may,
|
||||||
|
year = {2005},
|
||||||
|
keywords = {Cyclades Corp., Remote access software, Software industry}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{202829608,
|
||||||
|
title = {{MRV} {DEBUTS} {OUT}-{OF}-{BAND} {MANAGEMENT} {SYSTEM} {WITH} {SECURITY}},
|
||||||
|
volume = {19},
|
||||||
|
url = {https://search-proquest-com.ezproxy.bcu.ac.uk/docview/202829608},
|
||||||
|
language = {English},
|
||||||
|
number = {8},
|
||||||
|
journal = {Computer Protocols},
|
||||||
|
author = {{MRV Communications}},
|
||||||
|
month = aug,
|
||||||
|
year = {2006},
|
||||||
|
note = {tex.isbn: 0899126X},
|
||||||
|
keywords = {Computers},
|
||||||
|
pages = {N/A}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{194355400,
|
||||||
|
title = {Managing out-of-band management},
|
||||||
|
volume = {27},
|
||||||
|
url = {https://search-proquest-com.ezproxy.bcu.ac.uk/docview/194355400},
|
||||||
|
language = {English},
|
||||||
|
number = {50},
|
||||||
|
journal = {InfoWorld},
|
||||||
|
author = {Chee, Brian},
|
||||||
|
month = dec,
|
||||||
|
year = {2005},
|
||||||
|
note = {tex.isbn: 01996649},
|
||||||
|
pages = {14}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{informationweek_out--band_2005,
|
||||||
|
title = {Out-{Of}-{Band} {Systems} {Management} {Helps} {Businesses} {Expand}; {Uplogix} introduces a new version of its network management software for centralized and remote management that makes use of out-of-band techniques to gain access to servers and other {IT} systems that have crashed, lost power, or have faulty network connections},
|
||||||
|
issn = {87506874},
|
||||||
|
url = {https://link.gale.com/apps/doc/A137823043/AONE?u=uce&sid=AONE&xid=e8820255},
|
||||||
|
language = {English},
|
||||||
|
urldate = {06 November 2019},
|
||||||
|
journal = {InformationWeek},
|
||||||
|
author = {{InformationWeek}},
|
||||||
|
month = oct,
|
||||||
|
year = {2005},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{1606042,
|
||||||
|
address = {Atlantic City, NJ},
|
||||||
|
title = {Enhancing network survivability with out of band},
|
||||||
|
volume = {4},
|
||||||
|
doi = {10.1109/MILCOM.2005.1606042},
|
||||||
|
booktitle = {{MILCOM} 2005 - 2005 {IEEE} military communications conference},
|
||||||
|
publisher = {IEEE},
|
||||||
|
author = {Brenkosh, J. P. and Witzke, E. L. and Kellogg, B. R. and Olsberg, R. R.},
|
||||||
|
month = oct,
|
||||||
|
year = {2005},
|
||||||
|
note = {ISSN: 2155-7586},
|
||||||
|
pages = {2494--2498}
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{kolaks2003securing,
|
||||||
|
title = {Securing out-of-band device management},
|
||||||
|
volume = {21},
|
||||||
|
url = {https://www.sans.org/reading-room/whitepapers/networkdevs/securing-out-of-band-device-management-906},
|
||||||
|
journal = {SANS Institute},
|
||||||
|
author = {Kolaks, Marc S},
|
||||||
|
year = {2003},
|
||||||
|
urldate = {11 November 2019}
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{10.1145/2591971.2592009,
|
||||||
|
author = {Suneja, Sahil and Isci, Canturk and Bala, Vasanth and de Lara, Eyal and Mummert, Todd},
|
||||||
|
title = {Non-Intrusive, out-of-Band and out-of-the-Box Systems Monitoring in the Cloud},
|
||||||
|
year = {2014},
|
||||||
|
isbn = {9781450327893},
|
||||||
|
publisher = {Association for Computing Machinery},
|
||||||
|
address = {New York, NY, USA},
|
||||||
|
url = {https://doi.org/10.1145/2591971.2592009},
|
||||||
|
doi = {10.1145/2591971.2592009},
|
||||||
|
booktitle = {The 2014 ACM International Conference on Measurement and Modeling of Computer Systems},
|
||||||
|
pages = {249–261},
|
||||||
|
numpages = {13},
|
||||||
|
keywords = {cloud, analytics, mon- itoring, data center, virtualization, vmi, virtual machine, agentless},
|
||||||
|
location = {Austin, Texas, USA},
|
||||||
|
series = {SIGMETRICS ’14}
|
||||||
|
}
|
||||||
|
|
||||||
|
@INPROCEEDINGS{ieee-4753503,
|
||||||
|
author={Bruce Bennett and Shane Transue},
|
||||||
|
booktitle={MILCOM 2008 - 2008 IEEE Military Communications Conference},
|
||||||
|
title={Remote IP SATCOM monitoring and management},
|
||||||
|
year={2008},
|
||||||
|
volume={},
|
||||||
|
number={},
|
||||||
|
pages={1-5},
|
||||||
|
doi={10.1109/MILCOM.2008.4753503},
|
||||||
|
ISSN={2155-7586},
|
||||||
|
month={Nov},
|
||||||
|
}
|
||||||
|
|
||||||
|
@techreport{geant-bpd-101,
|
||||||
|
title = {Network Monitoring and Management Recommendations},
|
||||||
|
author = {Ivan Ivanović and Esad Saitović},
|
||||||
|
url = {https://services.geant.net/sites/cbp/Knowledge_Base/Network_Monitoring/Documents/gn3-na3-t4-abpd101.pdf},
|
||||||
|
urldate = {09 November 2019},
|
||||||
|
institution = {GÉANT},
|
||||||
|
year = {2011},
|
||||||
|
month = {February},
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{auvik-oobm-network,
|
||||||
|
title = {Out-of-Band Management},
|
||||||
|
url = {https://www.auvik.com/franklymsp/blog/out-of-band-management},
|
||||||
|
urldate = {06 April 2020},
|
||||||
|
journal = {Auvik Frankly MSP Blog},
|
||||||
|
author = {Kevin Dooley},
|
||||||
|
month = {May 12},
|
||||||
|
year = {2014},
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{plixer-vrf,
|
||||||
|
title = {What is VRF: Virtual Routing and Forwarding},
|
||||||
|
url = {https://www.plixer.com/blog/what-is-vrf-virtual-routing-and-forwarding/},
|
||||||
|
urldate = {09 November 2019},
|
||||||
|
journal = {Plixer},
|
||||||
|
author = {Plixer},
|
||||||
|
month = {December 10},
|
||||||
|
year = {2009},
|
||||||
|
}
|
||||||
|
|
||||||
|
@manual{multitech-dev-rs232,
|
||||||
|
title = {MTAC-MFSER Usage},
|
||||||
|
author = {{Multi-Tech Systems}},
|
||||||
|
organization = {Multi-Tech Systems},
|
||||||
|
month = {September 4},
|
||||||
|
year = {2019},
|
||||||
|
urldate = {11 February 2020},
|
||||||
|
url = {http://www.multitech.net/developer/software/mlinux/using-mlinux/mlinux-using-accessory-cards/mtac-mfser-usage}
|
||||||
|
}
|
||||||
|
|
||||||
|
@manual{multitech-dev-osupgrade,
|
||||||
|
title = {Upgrading mLinux},
|
||||||
|
author = {{Multi-Tech Systems}},
|
||||||
|
organization = {Multi-Tech Systems},
|
||||||
|
month = {September 3},
|
||||||
|
year = {2019},
|
||||||
|
urldate = {9 February 2020},
|
||||||
|
url = {http://www.multitech.net/developer/software/mlinux/upgrading-mlinux}
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{multitech-mfser,
|
||||||
|
author = {{Multi-Tech Systems}},
|
||||||
|
title = {MTAC-MFSER},
|
||||||
|
howpublished = {online},
|
||||||
|
month = {March 18},
|
||||||
|
year = {2019},
|
||||||
|
urldate = {12 April 2020},
|
||||||
|
url = {http://www.multitech.net/developer/products/multiconnect-conduit-platform/accessory-cards/mtac-mfser}
|
||||||
|
}
|
||||||
BIN
img/3-design/physical.png
Normal file
BIN
img/3-design/physical.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 540 KiB |
BIN
img/4-development/multitech-mtac-mfser.png
Normal file
BIN
img/4-development/multitech-mtac-mfser.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 218 KiB |
BIN
img/4-development/ssh-oobm-prompt.png
Normal file
BIN
img/4-development/ssh-oobm-prompt.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
BIN
img/4-development/ssh-std-prompt.png
Normal file
BIN
img/4-development/ssh-std-prompt.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
BIN
img/cover/bcu.png
Normal file
BIN
img/cover/bcu.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 110 KiB |
81
main.tex
Normal file
81
main.tex
Normal file
@ -0,0 +1,81 @@
|
|||||||
|
\documentclass[a4paper]{scrreprt}
|
||||||
|
\usepackage{graphicx}
|
||||||
|
\usepackage{titlepic}
|
||||||
|
\usepackage{subfig}
|
||||||
|
\usepackage{titling}
|
||||||
|
\usepackage[a4paper,left=3.5cm,right=2cm,top=2cm,bottom=2cm]{geometry}
|
||||||
|
\usepackage{helvet}
|
||||||
|
\usepackage{natbib}
|
||||||
|
\usepackage[breaklinks]{hyperref}
|
||||||
|
\usepackage{rotating}
|
||||||
|
% \usepackage{lscape}
|
||||||
|
\usepackage{pdfpages}
|
||||||
|
\usepackage{setspace}
|
||||||
|
\usepackage{subfiles}
|
||||||
|
% \renewcommand\thefigure{\arabic{figure}}
|
||||||
|
% \setcounter{figure}{0}
|
||||||
|
\setcounter{chapter}{0}
|
||||||
|
\newcommand*{\urlprefix}{Available at: }
|
||||||
|
\newcommand*{\urldateprefix}{Accessed }
|
||||||
|
\setcitestyle{notesep={: }}
|
||||||
|
\bibliographystyle{bib/BCU.bst}
|
||||||
|
\doublespacing
|
||||||
|
|
||||||
|
\begin{document}
|
||||||
|
\title{{LoRaWAN} Gateways as Remote Access Servers: \\ Designing a secure remote access solution for \\ branch office network devices}
|
||||||
|
\author{Luke Dominic Tainton \\ 16114711}
|
||||||
|
|
||||||
|
{\fontfamily{phv}\selectfont
|
||||||
|
|
||||||
|
\begin{titlingpage}
|
||||||
|
\newgeometry{left=2cm,right=2cm,top=2cm,bottom=2cm}
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[width=10cm]{img/cover/bcu.png} \\
|
||||||
|
\vspace{0.5cm}
|
||||||
|
\begin{large}
|
||||||
|
Birmingham City University \\
|
||||||
|
School of Computing and Digital Technology \\
|
||||||
|
Bachelor of Science with Honours Computer Networks \\
|
||||||
|
\end{large}
|
||||||
|
\vspace{4cm}
|
||||||
|
\begin{large}
|
||||||
|
\textbf{\thetitle} \\
|
||||||
|
Final Year Project Dissertation \\
|
||||||
|
\end{large}
|
||||||
|
\vspace{1cm}
|
||||||
|
\theauthor\\[0.2cm]
|
||||||
|
\date{June 2020}
|
||||||
|
\vspace{1cm}
|
||||||
|
A report submitted as part of the requirements for the degree of BSc (Hons) \\ Computer Networks at the School of Computing and Digital Technology, \\ Birmingham City University. \\
|
||||||
|
\vspace{1cm}
|
||||||
|
\thedate \\
|
||||||
|
\vspace{1cm}
|
||||||
|
\textbf{Supervisor:} Dalia El-Banna \\
|
||||||
|
\vspace{1cm}
|
||||||
|
% \thedate \\
|
||||||
|
\vspace{1cm}
|
||||||
|
\end{center}
|
||||||
|
\end{titlingpage}
|
||||||
|
|
||||||
|
\newgeometry{left=3.5cm,right=2cm,top=2cm,bottom=2cm}
|
||||||
|
\newpage
|
||||||
|
\chapter*{Abstract}
|
||||||
|
\subfile{sections/0-1-abstract}
|
||||||
|
|
||||||
|
\chapter*{Acknowledgements}
|
||||||
|
\subfile{sections/0-2-acknowledgements}
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
\tableofcontents
|
||||||
|
\listoffigures
|
||||||
|
|
||||||
|
\subfile{sections}
|
||||||
|
|
||||||
|
\newpage
|
||||||
|
\addcontentsline{toc}{chapter}{Bibliography}
|
||||||
|
\raggedright
|
||||||
|
\nocite{*} % List all references
|
||||||
|
\bibliography{bib/bibliography.bib}
|
||||||
|
|
||||||
|
} % end font
|
||||||
|
\end{document}
|
||||||
32
sections.tex
Normal file
32
sections.tex
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
\newpage
|
||||||
|
\chapter{Introduction}
|
||||||
|
\label{chap:intro}
|
||||||
|
\subfile{sections/1-intro}
|
||||||
|
|
||||||
|
\chapter{Literature Review}
|
||||||
|
\label{chap:litreview}
|
||||||
|
\subfile{sections/2-litreview}
|
||||||
|
|
||||||
|
% \chapter{Planning and Research}
|
||||||
|
% \subfile{sections/planning}
|
||||||
|
|
||||||
|
\chapter{Design}
|
||||||
|
\label{chap:design}
|
||||||
|
\subfile{sections/3-design}
|
||||||
|
|
||||||
|
\chapter{Development}
|
||||||
|
\label{chap:development}
|
||||||
|
\subfile{sections/4-development}
|
||||||
|
|
||||||
|
\chapter{Testing}
|
||||||
|
\label{chap:testing}
|
||||||
|
\subfile{sections/5-testing}
|
||||||
|
|
||||||
|
\chapter{Conclusion}
|
||||||
|
\label{chap:conclusion}
|
||||||
|
\subfile{sections/6-conclusion}
|
||||||
|
|
||||||
|
\appendix
|
||||||
|
\chapter{Appendix}
|
||||||
|
\label{chap:appendix}
|
||||||
|
\subfile{sections/7-appendix}
|
||||||
0
sections/0-1-abstract.tex
Normal file
0
sections/0-1-abstract.tex
Normal file
1
sections/0-2-acknowledgements.tex
Normal file
1
sections/0-2-acknowledgements.tex
Normal file
@ -0,0 +1 @@
|
|||||||
|
% I would like to take this opportunity to pay thanks to my project supervisor, Dalia El-Banna, for her support and guidance throughout the project. I would also like to thank Campbell Elder from Multi-Tech for providing equipment and technical assistance during the testing and build phases of the project. Finally, I would like to thank my family and friends for their support.
|
||||||
33
sections/1-intro.tex
Normal file
33
sections/1-intro.tex
Normal file
@ -0,0 +1,33 @@
|
|||||||
|
\section{Problem definition}
|
||||||
|
\label{section:intro-definition}
|
||||||
|
The Faculty was approached by Multi-Tech Systems and was tasked with designing and building a replacement for their ageing remote access solution using analog modems, namely the MT9234ZBA. Due to the ageing, the hardware that is currently offered to customers has reached the end of its life and is no longer supported, meaning that Multi-Tech support engineers are severely limited in the support they can give to end users if the hardware develops a fault. Some functionality and security concerns were also raised in the project proposal which needed to be fixed. \\\\
|
||||||
|
It is expected that the end product of this project will be developed further by Multi-Tech and marketed to their customer base as a replacement of, and an alternative to, the current offering.
|
||||||
|
|
||||||
|
\section{Scope}
|
||||||
|
\label{section:intro-scope}
|
||||||
|
% This section identifies the boundaries of the project, what was included and what was excluded from the final project. This should be justified and underpinned by research.
|
||||||
|
\textcolor{red}{TO DO}
|
||||||
|
|
||||||
|
\section{Rationale}
|
||||||
|
\label{section:intro-rationale}
|
||||||
|
% Why has the topic been chosen? This may be because of lack of research in the area, to shed more ideas and opinion, in response to a request, e.g. from company or organisation, or a relevant current issue. It should be more than for personal interest – you should be able to identify a company, organisation or other defined group that will benefit from the work. What benefits can be identified from doing the project. \\\\
|
||||||
|
This project was given to the University by Multi-Tech Systems, who directly sponsored and supported the research, development, and build phases. As a result of this, the main motivator for the project is commercialisation - the company is seeking to benefit directly from the outcome of the project, likely by marketing the solution on their product catalogue. \\\\
|
||||||
|
However, there are flaws in the out of band management method that this project is aiming to replace (using modems to 'dial in' to a network device), and this is the secondary motivator of the project. There is a lack of research into the security and functionality issues of using out of band management systems to access network devices, while the way in which modems are designed to operate have security implications when paired with a device such as a Cisco router - something which vendors such as Cisco have had to build protections for.
|
||||||
|
|
||||||
|
\section{Project aims and objectives}
|
||||||
|
\label{section:intro-aims}
|
||||||
|
\subsection{Aim}
|
||||||
|
The aim of this project was to design and implement a method of using a Multi-Tech Conduit LoRaWAN Gateway as a Remote Access server, to be used to remotely access the console line of a networking device such as a Cisco router.
|
||||||
|
\subsection{Objectives}
|
||||||
|
A list of objectives were identified that needed to be met to ensure that the aim was reached. These are listed below:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Identify the functionality and security issues that exist regarding remote access to devices via a console session.
|
||||||
|
\item Evaluate the robustness of the current solution in comparison to the issues identified in the previous objective.
|
||||||
|
\item Create the new RAS solution for the Multi-Tech Conduit gateway.
|
||||||
|
\item Test the functionality and security of the new solution against the existing product.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\section{Background information}
|
||||||
|
\label{section:intro-background}
|
||||||
|
\subsection{Multi-Tech Systems}
|
||||||
|
Multi-Tech Systems manufactures equipment for use cases in the industrial Internet of Things. Founded in 1970, Multi-Tech holds over 80 US patents in technologies ranging from DSL modems to proxy servers. The company has offices in the United States, the United Kingdom, and Japan, allowing it to reach customers from anywhere in the world. Their fast-selling product ranges are in the areas of 4G and LoRaWAN, as companies start to use IoT devices and sensors in their business processes.
|
||||||
34
sections/2-litreview.tex
Normal file
34
sections/2-litreview.tex
Normal file
@ -0,0 +1,34 @@
|
|||||||
|
To ensure that the design of the new out-of-band management solution fit the needs not only of Multi-Tech but of the industry in general, research was conducted using literature that was related to the following set of four topics:
|
||||||
|
\begin{itemize}
|
||||||
|
\item How is out-of-band management defined and why is it used?
|
||||||
|
\item What types of out-of band management are there?
|
||||||
|
\item What are the functionality issues?
|
||||||
|
\item What are the security issues?
|
||||||
|
\end{itemize}
|
||||||
|
The review of this literature will emphasise the reasons why out-of-band management systems are used in industry, the different forms in which they appear, and the positive and negative effects of using such systems to manage networks ranging from small businesses to large global enterprises. \\\\
|
||||||
|
This review, and therefore the report as a whole, will take research centred around "in-band' management into account, but will not go into any depth analysing it as it is beyond the scope of the project. While large-scale out-of-band networks were not originally in the scope of this project, a lack of available research on branch office out-of-band management systems required that the scope of the research phase be expanded to include this.
|
||||||
|
|
||||||
|
\section{Definition of out-of-band management}
|
||||||
|
\label{section:lit-definition}
|
||||||
|
All industry experts and academics define out-of-band management in a similar manner, as a separate, parallel network that grants engineers remote access to managed devices. However, most articles are focused on a specific use for the technology and therefore define it specifically for their use case; \cite{1606042} added specifics for managing military networks, whereas \cite{211239} described it in a way more related to managing servers in a data centre.
|
||||||
|
|
||||||
|
\section{Types of out-of band management}
|
||||||
|
\label{section:lit-types}
|
||||||
|
Most research into out-of-band management systems was focused on rack-mount servers and virtual machines instead of networking devices such as switches and routers. This is likely due to disaster recovery methods for networks being well defined, even if they are poorly documented. \\\\
|
||||||
|
Where research was focused on network out-of-band management, it was aimed at large enterprises which have the capability to deploy large, scalable dedicated networks for their out-of-band facility. There was a lack of research into small business and branch office management using modems, which is the main focus for this project. \\\\
|
||||||
|
Out of band networks, while functionally the same between use cases, will be physically different from each other dependant on the types of system they are connecting to. As an example, \cite{cisco-ha} uses console servers in their out-of-band network to access the console of network devices using a serial connection. In contrast, \cite{pruett_bladecenter_2005} uses IBM's \textit{BladeCenter} software to manage a blade chassis remotely via a web GUI.
|
||||||
|
|
||||||
|
\section{Functionality issues}
|
||||||
|
\label{section:lit-functionality}
|
||||||
|
As stated by Multi-Tech in section \ref{section:appendix-proposal}, the main functionality issue that is present in this method of out-of-band device management is the ability for an administrator to accidentally place the modem into command mode, rendering the connection unusable until someone can physically power cycle the modem. \\\\
|
||||||
|
There is a lack of research into this area, both in academic journals and online. While there is no clear reason as to why this is, it is possible that this issue is specific to Multi-Tech's solution and there are no wider functional issues that would warrant investigation.
|
||||||
|
|
||||||
|
\section{Security issues}
|
||||||
|
\label{section:lit-security}
|
||||||
|
Most journals mentioned the failings of Telnet in terms of keeping management traffic secure, with some suggesting workarounds and alternative methods of accessing the intended device. \cite{geant-bpd-101} provide an example of this in their best practice document published by the pan-European research network GÉANT, where they detail Telnet's non-encrypted nature and suggest that secure shell (SSH) is used instead; \cite{1274255} suggests using TLS as an encryption layer to Telnet instead of SSH, which would essentially achieve the same result. \\\\
|
||||||
|
Many network administrators mitigate these issues by segmenting management traffic from the main production network \citep{auvik-oobm-network}. This network can be physically separate, or run on the same physical hardware but be separated logically. \cite{plixer-vrf} suggests a method of logical separation involving VLANs at Layer 2 and VRFs at Layer 3, and explains the differences between them.
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textcolor{red}{Network ACLs \citep{geant-bpd-101}}
|
||||||
|
\item \textcolor{red}{SNMP - polling vs. traps \citep{386580}}
|
||||||
|
\item \textcolor{red}{Mention in all sub-sections}
|
||||||
|
\end{itemize}
|
||||||
41
sections/3-design.tex
Normal file
41
sections/3-design.tex
Normal file
@ -0,0 +1,41 @@
|
|||||||
|
% This section shows the development and justification of the design of your artefact from requirements through to final design.
|
||||||
|
% \section{Research}
|
||||||
|
% \subsection{In-band management systems}
|
||||||
|
% \subsection{Out-of-band management systems}
|
||||||
|
\section{Methodology}
|
||||||
|
\label{section:design-methodology}
|
||||||
|
As chapter \ref{chap:litreview} proves, little academic research exists around out-of-band management of network devices, and specifically the security risks associated with it. Therefore, an inductive approach was taken during the research phase to create a base theory that was used as part of the evaluation of the finished product. \\\\
|
||||||
|
The Kanban development and task management methodology was used during this project. Kanban was designed originally for software development, where a list of tasks is kept in a Backlog, and developers pull tasks from this list into their 'in progress' queue. Once a task is complete, the developer will move the task into either a 'in review' queue, or a 'complete' queue. This allows the entire development team to easily visualise the status of tasks in the project. \\\\
|
||||||
|
While Kanban is designed for software development, in the case of this project, no software was developed so this system was used to easily see what tasks were completed and what still needed to be done. It was mainly used during the design and development phases. When designing the final product, functionality and security ideas were added to an 'Ideas' column, similar to the 'Backlog' in standard Kanban. If an idea was selected it was moved to a 'Confirmed' column, while other ideas were moved to a 'Rejected' column. This helped to prevent repetition of ideas during the design phase, and allowed previously rejected ideas to be approved if it was found that they were actually needed.
|
||||||
|
|
||||||
|
\subsection{Possible approaches}
|
||||||
|
\label{subsection:design-methodology-approaches}
|
||||||
|
Three potential approaches to the problem were identified and are described below. The project proposal issued by Multi-Tech (appendix \ref{section:appendix-proposal}) had some influence over the decision to choose one method over the others, however, user experience was the key driving factor behind the method of choice, based on which method would provide the easiest overall experience for a network engineer.
|
||||||
|
|
||||||
|
\subsubsection{Write the remote access software from scratch}
|
||||||
|
% \textcolor{red}{Learn C and C++, then write custom software that would run commands given by the admin over the serial connection and return the result(s). This would most likely have been interfaced via a web UI.}\\\
|
||||||
|
This approach requires the administrator to interface with the remote device via a web portal. The portal allows the administrator to enter commands to send to the device, and returns the output of that command to the administrator. A new connection to the device would be established for each command sent. \\\\
|
||||||
|
All software that is available for the Conduit gateways is written in either \textit{C} or \textit{C++}. Therefore, this approach requires an understanding of these programming languages and of software development and compilation workflows. The Multi-Tech Conduit is based on an ARM processor which also requires some prior knowledge, as compiling software for this architecture follows a different process to that of x86 architecture software compilation.
|
||||||
|
|
||||||
|
\subsubsection{Develop a web portal that invoked terminal emulation software}
|
||||||
|
This approach is similar to the approach above and also requires the network administrator to remotely access the Conduit gateway via a web interface. The interface contains an input field and a section for returned output to be displayed. The main difference between this approach and the previous approach is that the administrator would be required to click a button to start a pre-installed terminal emulator in the background (likely to be either GNU Screen or Minicom). They would then would enter commands they wish to execute, one at a time, into a form field and click another button to send them. The application would send the command to the terminal emulator in the background, and would return the output of the executed command to the administrator.
|
||||||
|
|
||||||
|
\subsubsection{Invoke terminal emulation software via a standard SSH connection}
|
||||||
|
This approach requires the network administrator to remotely access the Conduit gateway via a standard SSH connection. Once they are connected, and assuming that they have the rights to do so on the gateway, the administrator would then execute the terminal emulation software on the attached serial card, opening a console session to the attached device.\\\\
|
||||||
|
While it is possible to manually execute the terminal emulation software each time an administrator connects, this is cumbersome. An administrator could overcome this by writing a script that could be executed each time they login, but this would require each administrator to do this on their first login. The more elegant solution is to run a second SSH server alongside the pre-existing server, which automatically executes the terminal emulator upon connection by an authorised user.
|
||||||
|
|
||||||
|
\subsection{Chosen approach}
|
||||||
|
\label{subsection:design-methodology-approach}
|
||||||
|
The most feasible approach to the problem was to use a standard SSH connection to the Conduit, then execute terminal emulation software inside the SSH session. This allows the administrator full access to the console of the attached device. It was decided that the terminal emulation software should be invoked automatically by the SSH server when a user session is established, requiring an additional SSH server to run alongside the primary instance. \\\\
|
||||||
|
While no tests were completed to prove this, approaching the problem using a web application would have likely overwhelmed the available system resources. As the Conduit is intended for IoT use cases, it does not generally have a large amount of resources built-in and upgrading it is not recommended. This system would require a web server to be installed which would take up system resources in addition to the application itself and the terminal emulator it would execute on the administrator's behalf.
|
||||||
|
|
||||||
|
\section{Product design}
|
||||||
|
\label{section:design-productdesign}
|
||||||
|
The physical design of the product is similar to that of the current solution and can be shown in a diagram in a similar manner to a network topology. Figure \ref{fig:3-physical} shows the differences in hardware between the current and new solution, but the main difference is that the modem that forms the main section of the original architecture has been replaced by the Multi-Tech Conduit and a router (any router can be used), replacing outdated connectivity via a phone line with Ethernet.\\\\
|
||||||
|
The Conduit connects to the console port of the network device being managed using a rollover cable, either via the MTAC-MFSER serial card, or via USB. It then uses a standard Ethernet connection via a router or firewall to gain Internet access. The administrator establishes a connection to the Conduit using SSH on a non-standard port for security, and once the user passes authentication and authorisation, the SSH server automatically executes the terminal emulator in the user's shell.
|
||||||
|
%\textcolor{red}{Describe the diagram and the difference between the current system and the new one.}
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[scale=0.7]{img/3-design/physical.png}
|
||||||
|
\captionof{figure}{Physical solution design}
|
||||||
|
\label{fig:3-physical}
|
||||||
|
\end{center}
|
||||||
81
sections/4-development.tex
Normal file
81
sections/4-development.tex
Normal file
@ -0,0 +1,81 @@
|
|||||||
|
\section{System preparation}
|
||||||
|
\label{section:dev-sysprep}
|
||||||
|
\subsection{Installing the hardware}
|
||||||
|
\label{subsection:dev-sysprep-hardware}
|
||||||
|
% \textcolor{red}{Acquisition and installation of mCard modules}
|
||||||
|
\begin{center}
|
||||||
|
\includegraphics[scale=0.7]{img/4-development/multitech-mtac-mfser.png}
|
||||||
|
\captionof{figure}{Multi-Tech MTAC-MFSER mCards \citep{multitech-mfser}}
|
||||||
|
\label{fig:4-mfser}
|
||||||
|
\end{center}
|
||||||
|
The Conduit gateway is shipped by default with the MTAC-LORA accessory card installed. For this project the LoRa capability is not required, so this mCard was removed from the Conduit and replaced with an MTAC-MFSER-DCE card (supplied on loan by Multi-Tech), which provides a female DB9 connector. These cards are easy to install - a single screw holds them in place, and once the screw is removed the card can be removed or installed by sliding it in or out of the Conduit. For the purposes of the project only one mCard was installed and the other slot was covered by a blanking panel, however for production use a second mCard can be installed, allowing the Conduit to provide access to two devices.
|
||||||
|
|
||||||
|
\subsection{Updating the Conduit}
|
||||||
|
\label{subsection:dev-sysprep-updates}
|
||||||
|
The next stage of development was to ensure that the Conduit gateway was in a good state to work with. Writing software and editing configuration files while the operating system and its packages are out of date may cause issues later on in the project or when used in production, where any updates that are installed can break configurations in a way that is not easily recoverable.\\\\
|
||||||
|
The Multi-Tech Conduit uses a custom distribution of Linux, although there are similarities between it and Debian. The installed package manager was not one of these similarities, however. Most Debian-based distributions use Aptitude package manager which is managed with the \verb|apt-get| command, but this distribution of Linux uses Opkg package manager, which is managed with the \verb|opkg| command. Aptitude can update the operating system and installed packages by running commands such as \verb|apt-get upgrade|, whereas Opkg can only install and update packages, the install files of which (\verb|.ipk| files) must be passed to Opkg as parameters upon command execution. \\\\
|
||||||
|
According to \cite{multitech-dev-osupgrade}, upgrading the operating system on the Conduit requires that the upgrade files are placed in a specific directory (\verb|/var/volatile| at the time of writing), then executing the upgrade executable with root privileges. It is recommended that this is done via a console connection to the gateway rather than a remote connection as the upgrade causes the gateway to reboot.
|
||||||
|
|
||||||
|
\section{Compiling GNU Screen for ARM}
|
||||||
|
\label{section:dev-screenonarm}
|
||||||
|
GNU Screen was chosen as the terminal emulation software that would be used for this project. Installing Screen using the Opkg package manager was impossible as there was no available install package, meaning that the software had to be installed by compiling the binary from the source code. This proved more difficult than normal as, while most desktops and laptops use an x86 architecture, the Conduit is based on an ARM architecture. This required cross-compilation of the source code - that is, an x86-based computer was used to produce an ARM-compatible executable.\\\\
|
||||||
|
Multi-Tech provides a C/C++ toolchain for Linux-based computers, which aids developers with compiling software for ARM-based processors by automatically setting environment variables, installing dependencies, and installing libraries that are required for the compilation to complete. This requires that compilation takes place on a Linux PC, therefore the compilation was completed on a virtual machine running Ubuntu 19.10. The latest version of the toolchain (5.1.8 at the time of writing) was used to ensure that any potential bugs that had been identified in previous versions were patched, and it was installed by downloading and executing the installation script from the Multi-Tech Developer portal. This script saved the toolchain to \verb|/opt/mlinux/5.1.8/environment-setup-arm926ejste-mlinux-linux-gnueabi|. The command \verb|source .../environment-setup-arm926ejste-mlinux-linux-gnueabi| was added to the \verb|.zshrc| file that executes each time a command line is launched, meaning that the toolchain did not need to be manually activated each time a command line session was started.\\\\
|
||||||
|
3
|
||||||
|
|
||||||
|
\section{Running a second SSH daemon}
|
||||||
|
\label{section:dev-sshdaemon}
|
||||||
|
The decision was taken to run a second SSH daemon alongside the pre-existing one specifically for out of band access. Although a second SSH server wasn't required for the system to function, implementing it makes connecting to the managed device easier for the network engineers that need to do so. The alternative to running a secondary daemon is that an engineer must connect normally to the gateway via SSH and manually execute the terminal emulation software.
|
||||||
|
\subsection{Creating the second daemon}
|
||||||
|
\label{subsection:dev-sshdaemon-creating}
|
||||||
|
In this distribution of Linux, in keeping with older versions of Debian, system services (daemons) are defined within the \verb|/etc/init.d| directory. A default OpenSSH service is installed when the operating system is installed and is defined in the \verb|/etc/init.d/sshd| file. This definition file was duplicated to \verb|/etc/init.d/sshd-oobm| to create a second OpenSSH service specifically for out of band device access, ensuring that as much of the configuration as possible was kept the same to ensure consistency. The service definition file for the out of band service is included in Appendix \ref{section:appendix-sshdoobminitd}.\\\\
|
||||||
|
To ensure the two SSH daemons acted independently of each other, separate PID files were used. PID files store the process identifier for a given process, which is a unique integer for each running process. Using different PID files should force the default and custom SSH daemons to start under different process IDs and therefore force the custom service to act without reliance on the default service.\\\\
|
||||||
|
Once the service definition files were created, the configuration files for the custom SSH server were copied from the original files used by the default daemon:
|
||||||
|
\begin{verbatim}
|
||||||
|
/
|
||||||
|
etc/
|
||||||
|
init.d/
|
||||||
|
sshd
|
||||||
|
sshd-oobm
|
||||||
|
ssh/
|
||||||
|
sshd_banner
|
||||||
|
sshd_config
|
||||||
|
sshd_oobm_banner
|
||||||
|
sshd_oobm_cmd
|
||||||
|
sshd_oobm_config
|
||||||
|
\end{verbatim}
|
||||||
|
\captionof{figure}{Filesystem tree of changed files}
|
||||||
|
\label{fig:4-filetree}
|
||||||
|
The files in \verb|/etc/init.d| define the services themselves, whereas the files in \verb|/etc/ssh| define the configuration parameters for the service. The location of these files is specified in the service definition file.
|
||||||
|
|
||||||
|
\subsection{Configuration}
|
||||||
|
\label{subsection:dev-sshdaemon-configuration}
|
||||||
|
The configuration parameters for the second SSH daemon will be kept the same as the original server as much as possible to ensure consistency in their configurations and to prevent crashes.
|
||||||
|
\subsubsection{Sudoers file}
|
||||||
|
\label{subsubsection:dev-sshdaemon-configuration-sudoers}
|
||||||
|
The \verb|/etc/sudoers| file, which controls who can execute commands with root privileges, required editing to allow network administrators to reconfigure the serial card to work in RS-232 mode \citep{multitech-dev-rs232}. The \verb|mts-io-sysfs| command must be executed with root privileges and therefore requires the use of \verb|sudo|. However, it was important that non-administrator users on the gateway were only able to execute that specific command with root privileges, and also that it did not prompt the user for their password. This was accomplished with \verb|%oobm ALL=(ALL:ALL) NOPASSWD: /usr/sbin/mts-io-sysfs|, which specifies that all users in the \verb|oobm| group can become any user, not be asked for their password, and execute only that command.
|
||||||
|
\subsubsection{Service definition file}
|
||||||
|
\label{subsubsection:dev-sshdaemon-configuration-initd}
|
||||||
|
The \verb|/etc/init.d/sshd-oobm| is the service definition file for the \verb|sshd-oobm| service. This file was initially copied from \verb|/etc/init.d/sshd| (the definition file for the standard SSH server), but required some editing to allow the OOBM service to function independently. The PID file that should be used by the service is defined by the variable \verb|PIDFILE| in the service definition. In this instance, the PID file was changed to \verb|/var/run/sshd-oobm.pid|, instead of \verb|/var/run/sshd.pid| which is used by the standard server. The \verb|CONFFILE| variable, which defines where the service should look for its configuration parameters, was also changed to \verb|/etc/ssh/sshd_oobm_config| instead of \verb|/etc/ssh/sshd_config|. The \verb|check_for_no_start| function was modified to check for the existence of \verb|/etc/ssh/sshd_oobm_not_to_be_run| instead of \verb|/etc/ssh/sshd_not_to_be_run|. This function will prevent the server from being started if this file exists. The \verb|check_privsep_dir| function, which checks for the existence of the Privilege Separation home directory, was changed to look for the \verb|/var/run/sshd-oobm| directory as opposed to \verb|/var/run/sshd|. The start, restart, and stop functions were updated to point to OOBM-specific configuration files or PIDs, and the console output (where present) was edited to remind the user that they were changing the behaviour of the OOBM SSH server instead of the standard server.
|
||||||
|
\subsubsection{Connection banners}
|
||||||
|
\label{subsubsection:dev-sshdaemon-configuration-banners}
|
||||||
|
Two files, \verb|/etc/ssh/sshd_banner| and \verb|/etc/ssh/sshd_oobm_banner|, were created to define connection banners. These banners are presented to the user upon connection and are intended to remind the user which SSH server they have connected to. Figures \ref{fig:4-sshbannerstd} and \ref{fig:4-sshbanneroobm} show the banners in operation.
|
||||||
|
\begin{center}
|
||||||
|
\begin{minipage}{.5\textwidth}
|
||||||
|
\includegraphics[scale=0.4]{img/4-development/ssh-std-prompt.png}
|
||||||
|
\captionof{figure}{Banner: standard server}
|
||||||
|
\label{fig:4-sshbannerstd}
|
||||||
|
\end{minipage}
|
||||||
|
\begin{minipage}{.4\textwidth}
|
||||||
|
\includegraphics[scale=0.4]{img/4-development/ssh-oobm-prompt.png}
|
||||||
|
\captionof{figure}{Banner: OOBM server}
|
||||||
|
\label{fig:4-sshbanneroobm}
|
||||||
|
\end{minipage}
|
||||||
|
\end{center}
|
||||||
|
\subsubsection{Server configuration}
|
||||||
|
\label{subsubsection:dev-sshdaemon-configuration-sshdoobmconfig}
|
||||||
|
The configuration parameters for the servers are stored in \verb|/etc/ssh/sshd_config| and \verb|/etc/ssh/sshd_oobm_config|. The \verb|/etc/ssh/sshd_oobm_config| file was created by copying the original file. This helped to save time as all required parameters were already present and only required modification. If starting from scratch, the OpenSSH documentation would have been required to identify the parameters that were required. Many of the parameters in the OOBM configuration were removed as OpenSSH mostly works on the basis that parameters only need to be present if their default value needs to be overridden. \\\\
|
||||||
|
The \verb|Port| parameter, which controls which TCP port the server listens on, was changed from 22 to 1024, as port 22 is used by the standard SSH server. In a production scenario the chosen port would most likely be changed to a larger number, at least above 10,000. This would help to defend against port scanning attacks which usually associate SSH servers with port 22.\\\\
|
||||||
|
The Authentication parameters were changed to ensure that authorised users are able to access the connected networking device. A group named \verb|oobm| was created where authorised user accounts can be added. The \verb|AllowGroups| parameter was set to \verb|oobm|, which will ensure that only users in the \verb|oobm| are allowed access to the device. This includes any accounts that have administrative rights on the gateway but are not authorised to access the network device. The \verb|ForceCommand| parameter configures the SSH server to run a command or script upon connection and close the remote connection when the command exits. For the purposes of the OOBM server, this parameter was set to \verb|/etc/ssh/sshd_oobm_cmd| (included in Appendix \ref{section:appendix-ssh-sshdoobmcmd}). This script configures the serial card to operate in RS232 mode, then executes the GNU Screen terminal emulation software. When the user exists GNU Screen, their SSH session is automatically closed.
|
||||||
|
|
||||||
|
% \verb|| \verb|| \verb|| \verb||
|
||||||
|
% \textcolor{red}{See https://github.com/luketainton/oobm-serial for configuration files.}
|
||||||
24
sections/5-testing.tex
Normal file
24
sections/5-testing.tex
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
% This section focuses on learning outcome 4 - Critically evaluate the implementation of the artefact and the overall project. \\[0.2cm]
|
||||||
|
% You should provide an evaluation of the artefact and overall project,. This will express ideas in answer any research question, recognising the limitations of the project and areas for potential development or further work. It must take into consideration appropriate and relevant academic, ethical and professional requirements. \\[0.2cm]
|
||||||
|
% There should be a comprehensive discussion comprising interpretation of the findings and substantiated observations and judgements about them. This discussion should include reflection on the issues raised in the project. Depending on the nature of the project, and particularly with certain business topics for which the main outcomes are recommendations on various management related aspects, the results and discussion chapters may be integrated within chapter(s) of findings covering the relevant project objectives. In this case this chapter could be entitled Recommendations.
|
||||||
|
\textcolor{red}{
|
||||||
|
Is the final product a suitable replacement for the now End of Life product? What metrics can be used to compare the two solutions? \\\\
|
||||||
|
Unable to get the modem to work, so information from Multi-Tech was used as a baseline instead. \\\\
|
||||||
|
Measure packet loss, delay, jitter, etc.
|
||||||
|
}
|
||||||
|
|
||||||
|
\section{Functionality}
|
||||||
|
\label{section:testing-functionality}
|
||||||
|
\subsection{SSH daemon}
|
||||||
|
\label{subsection:testing-functionality-sshdaemon}
|
||||||
|
\subsection{Connecting to the device}
|
||||||
|
\label{subsection:testing-functionality-connection}
|
||||||
|
|
||||||
|
\section{Performance}
|
||||||
|
\label{section:testing-performance}
|
||||||
|
\subsection{Testing methodology}
|
||||||
|
\label{subsection:testing-performance-methodology}
|
||||||
|
\subsection{Packet loss}
|
||||||
|
\label{subsection:testing-performance-packetloss}
|
||||||
|
\subsection{Delay}
|
||||||
|
\label{subsection:testing-performance-delay}
|
||||||
23
sections/6-conclusion.tex
Normal file
23
sections/6-conclusion.tex
Normal file
@ -0,0 +1,23 @@
|
|||||||
|
% The conclusions should be a short summary of the important results and findings arising from the results and discussion. It is important to ensure that the conclusions address the original project objectives and reflect the main discussion. You should not include any new information or discussion in this section.
|
||||||
|
|
||||||
|
% Many projects follow on from previous work and, owing to time constraints and the generation of ideas whilst undertaking the work, lead on to the possibility of further work. These recommendations should be summarised briefly.
|
||||||
|
\section{Further work}
|
||||||
|
\label{section:conclusion-furtherwork}
|
||||||
|
\subsection{SSH daemon}
|
||||||
|
\label{subsection:conclusion-furtherwork-sshdaemon}
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textcolor{red}{The second SSH daemon still isn't running as an entirely separate entity from the main one}
|
||||||
|
\item \textcolor{red}{The second SSH daemon is not currently automatically starting on boot}
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{System security}
|
||||||
|
\label{subsection:conclusion-furtherwork-security}
|
||||||
|
\textcolor{red}{Fail2ban etc.}
|
||||||
|
|
||||||
|
\subsection{Deployment script}
|
||||||
|
\label{subsection:conclusion-furtherwork-script}
|
||||||
|
\textcolor{red}{Create a script that automates the setup of the OOBM server}
|
||||||
|
|
||||||
|
\subsection{Research into branch office management}
|
||||||
|
\label{subsection:conclusion-furtherwork-branchoffice}
|
||||||
|
\textcolor{red}{Lack of research}
|
||||||
547
sections/7-appendix.tex
Normal file
547
sections/7-appendix.tex
Normal file
@ -0,0 +1,547 @@
|
|||||||
|
\section{Multi-Tech project proposal}
|
||||||
|
\label{section:appendix-proposal}
|
||||||
|
\subsection{Scope}
|
||||||
|
Many companies still use analogue modems for out-of-band management for devices such as Cisco routers and telephone systems so they can have management companies (or themselves) dial into remote locations to make changes. This is then a protected connection as it does not necessitate use of the internal network to access the hardware. The modems they traditionally use is the Multi-Tech MT9234ZBA analogue modem. \\\\
|
||||||
|
Accessing Cisco routers though a console port is known to have some issues:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Escape sequences can be passed to the device through data uploads, that can put modems into command mode (breaking the connection to a non-recoverable state without power cycling the modem)
|
||||||
|
\item The modem generates characters when a remote device connects, that can put a Cisco router in to command mode.
|
||||||
|
\end{itemize}
|
||||||
|
The Multi-Tech MT9234ZBA modem is going end of life, and along with it some built in features to protect against the above. The entire solution is now end of life, including the legacy chips inside, with no replacement options from any manufacturer.
|
||||||
|
|
||||||
|
\subsection{Proposed solution}
|
||||||
|
There is a potential ‘older’ solution that could be re-engineered - the RAS or remote access server. Using Multi-Tech Conduit gateways:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Build a RAS application into the gateway
|
||||||
|
\item Attach two serial ports to it (Accessory cards) you could attach a still manufactured modem to one port – giving RAS dial in access and an IP connection.
|
||||||
|
\item With the IP connection, you could then enable a terminal to the second serial port and whatever terminal is connected to it (like a Cisco router), thus recovering out of band management capabilities via the requested analogue phone lines with a secured connection (username and password in the RAS) and separation from the terminal.
|
||||||
|
\end{itemize}
|
||||||
|
This could then be offered as an alternative solution to the customer base that will soon have no alternative.
|
||||||
|
|
||||||
|
\section{Configuration: /etc/sudoers}
|
||||||
|
\label{section:appendix-sudoers}
|
||||||
|
\begin{verbatim}
|
||||||
|
## sudoers file.
|
||||||
|
##
|
||||||
|
## This file MUST be edited with the 'visudo' command as root.
|
||||||
|
## Failure to use 'visudo' may result in syntax or file permission errors
|
||||||
|
## that prevent sudo from running.
|
||||||
|
##
|
||||||
|
## See the sudoers man page for the details on how to write a sudoers file.
|
||||||
|
##
|
||||||
|
|
||||||
|
##
|
||||||
|
## Host alias specification
|
||||||
|
##
|
||||||
|
## Groups of machines. These may include host names (optionally with wildcards),
|
||||||
|
## IP addresses, network numbers or netgroups.
|
||||||
|
# Host_Alias WEBSERVERS = www1, www2, www3
|
||||||
|
|
||||||
|
##
|
||||||
|
## User alias specification
|
||||||
|
##
|
||||||
|
## Groups of users. These may consist of user names, uids, Unix groups,
|
||||||
|
## or netgroups.
|
||||||
|
# User_Alias ADMINS = millert, dowdy, mikef
|
||||||
|
|
||||||
|
##
|
||||||
|
## Cmnd alias specification
|
||||||
|
##
|
||||||
|
## Groups of commands. Often used to group related commands together.
|
||||||
|
# Cmnd_Alias PROCESSES = /usr/bin/nice, /bin/kill, /usr/bin/renice, \
|
||||||
|
# /usr/bin/pkill, /usr/bin/top
|
||||||
|
# Cmnd_Alias REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff
|
||||||
|
|
||||||
|
##
|
||||||
|
## Defaults specification
|
||||||
|
##
|
||||||
|
## You may wish to keep some of the following environment variables
|
||||||
|
## when running commands via sudo.
|
||||||
|
##
|
||||||
|
## Locale settings
|
||||||
|
# Defaults env_keep += "LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET"
|
||||||
|
##
|
||||||
|
## Run X applications through sudo; HOME is used to find the
|
||||||
|
## .Xauthority file. Note that other programs use HOME to find
|
||||||
|
## configuration files and this may lead to privilege escalation!
|
||||||
|
# Defaults env_keep += "HOME"
|
||||||
|
##
|
||||||
|
## X11 resource path settings
|
||||||
|
# Defaults env_keep += "XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH"
|
||||||
|
##
|
||||||
|
## Desktop path settings
|
||||||
|
# Defaults env_keep += "QTDIR KDEDIR"
|
||||||
|
##
|
||||||
|
## Allow sudo-run commands to inherit the callers' ConsoleKit session
|
||||||
|
# Defaults env_keep += "XDG_SESSION_COOKIE"
|
||||||
|
##
|
||||||
|
## Uncomment to enable special input methods. Care should be taken as
|
||||||
|
## this may allow users to subvert the command being run via sudo.
|
||||||
|
# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
|
||||||
|
##
|
||||||
|
## Uncomment to use a hard-coded PATH instead of the user's to find commands
|
||||||
|
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
|
||||||
|
##
|
||||||
|
## Uncomment to send mail if the user does not enter the correct password.
|
||||||
|
# Defaults mail_badpass
|
||||||
|
##
|
||||||
|
## Uncomment to enable logging of a command's output, except for
|
||||||
|
## sudoreplay and reboot. Use sudoreplay to play back logged sessions.
|
||||||
|
# Defaults log_output
|
||||||
|
# Defaults!/usr/bin/sudoreplay !log_output
|
||||||
|
# Defaults!/usr/local/bin/sudoreplay !log_output
|
||||||
|
# Defaults!REBOOT !log_output
|
||||||
|
|
||||||
|
##
|
||||||
|
## Runas alias specification
|
||||||
|
##
|
||||||
|
|
||||||
|
##
|
||||||
|
## User privilege specification
|
||||||
|
##
|
||||||
|
root ALL=(ALL) ALL
|
||||||
|
|
||||||
|
## Uncomment to allow members of group wheel to execute any command
|
||||||
|
# %wheel ALL=(ALL) ALL
|
||||||
|
|
||||||
|
## Same thing without a password
|
||||||
|
# %wheel ALL=(ALL) NOPASSWD: ALL
|
||||||
|
|
||||||
|
## Uncomment to allow members of group sudo to execute any command
|
||||||
|
%sudo ALL=(ALL) ALL
|
||||||
|
|
||||||
|
## OOBM
|
||||||
|
%sudo ALL=(ALL:ALL) NOPASSWD: /usr/sbin/mts-io-sysfs
|
||||||
|
%oobm ALL=(ALL:ALL) NOPASSWD: /usr/sbin/mts-io-sysfs
|
||||||
|
|
||||||
|
## Uncomment to allow any user to run sudo if they know the password
|
||||||
|
## of the user they are running the command as (root by default).
|
||||||
|
# Defaults targetpw # Ask for the password of the target user
|
||||||
|
# ALL ALL=(ALL) ALL # WARNING: only use this together with 'Defaults targetpw'
|
||||||
|
|
||||||
|
## Read drop-in files from /etc/sudoers.d
|
||||||
|
## (the '#' here does not indicate a comment)
|
||||||
|
#includedir /etc/sudoers.d
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
\section{Configuration: /etc/init.d/sshd-oobm}
|
||||||
|
\label{section:appendix-sshdoobminitd}
|
||||||
|
\begin{verbatim}
|
||||||
|
#! /bin/sh
|
||||||
|
set -e
|
||||||
|
|
||||||
|
PIDFILE=/var/run/sshd-oobm.pid
|
||||||
|
CONFFILE=/etc/ssh/sshd_oobm_config
|
||||||
|
|
||||||
|
# source function library
|
||||||
|
. /etc/init.d/functions
|
||||||
|
|
||||||
|
# /etc/init.d/sshd-oobm: start and stop the OpenBSD "secure shell" daemon for OOBM
|
||||||
|
|
||||||
|
test -x /usr/sbin/sshd || exit 0
|
||||||
|
( /usr/sbin/sshd -\? 2>&1 | grep -q OpenSSH ) 2>/dev/null || exit 0
|
||||||
|
|
||||||
|
# /etc/default/ssh may set SYSCONFDIR and SSHD_OPTS
|
||||||
|
if test -f /etc/default/ssh; then
|
||||||
|
. /etc/default/ssh
|
||||||
|
fi
|
||||||
|
|
||||||
|
[ -z "$SYSCONFDIR" ] && SYSCONFDIR=/etc/ssh
|
||||||
|
mkdir -p $SYSCONFDIR
|
||||||
|
|
||||||
|
HOST_KEY_RSA=$SYSCONFDIR/ssh_host_rsa_key
|
||||||
|
HOST_KEY_DSA=$SYSCONFDIR/ssh_host_dsa_key
|
||||||
|
HOST_KEY_ECDSA=$SYSCONFDIR/ssh_host_ecdsa_key
|
||||||
|
HOST_KEY_ED25519=$SYSCONFDIR/ssh_host_ed25519_key
|
||||||
|
|
||||||
|
check_for_no_start() {
|
||||||
|
# forget it if we're trying to start, and /etc/ssh/sshd_oobm_not_to_be_run exists
|
||||||
|
if [ -e $SYSCONFDIR/sshd_oobm_not_to_be_run ]; then
|
||||||
|
echo "OpenBSD Secure Shell server for OOBM not in use"
|
||||||
|
exit 0
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
|
||||||
|
check_privsep_dir() {
|
||||||
|
# Create the PrivSep empty dir if necessary
|
||||||
|
if [ ! -d /var/run/sshd-oobm ]; then
|
||||||
|
mkdir /var/run/sshd-oobm
|
||||||
|
chmod 0755 /var/run/sshd-oobm
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
|
||||||
|
check_config() {
|
||||||
|
/usr/sbin/sshd -t $SSHD_OPTS || exit 1
|
||||||
|
}
|
||||||
|
|
||||||
|
check_keys() {
|
||||||
|
# create keys if necessary
|
||||||
|
if [ ! -f $HOST_KEY_RSA ]; then
|
||||||
|
echo " generating ssh RSA key..."
|
||||||
|
ssh-keygen -q -f $HOST_KEY_RSA -N '' -t rsa
|
||||||
|
fi
|
||||||
|
if [ ! -f $HOST_KEY_ECDSA ]; then
|
||||||
|
echo " generating ssh ECDSA key..."
|
||||||
|
ssh-keygen -q -f $HOST_KEY_ECDSA -N '' -t ecdsa
|
||||||
|
fi
|
||||||
|
if [ ! -f $HOST_KEY_DSA ]; then
|
||||||
|
echo " generating ssh DSA key..."
|
||||||
|
ssh-keygen -q -f $HOST_KEY_DSA -N '' -t dsa
|
||||||
|
fi
|
||||||
|
if [ ! -f $HOST_KEY_ED25519 ]; then
|
||||||
|
echo " generating ssh ED25519 key..."
|
||||||
|
ssh-keygen -q -f $HOST_KEY_ED25519 -N '' -t ed25519
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
|
||||||
|
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
|
||||||
|
|
||||||
|
case "$1" in
|
||||||
|
start)
|
||||||
|
check_for_no_start
|
||||||
|
echo "Starting OOBM server"
|
||||||
|
check_keys
|
||||||
|
check_privsep_dir
|
||||||
|
start-stop-daemon -S -p $PIDFILE --make-pidfile --startas /usr/sbin/sshd \
|
||||||
|
-- -f $CONFFILE $SSHD_OPTS
|
||||||
|
echo "done."
|
||||||
|
;;
|
||||||
|
stop)
|
||||||
|
echo -n "Stopping OOBM server"
|
||||||
|
pidno1=$(<$PIDFILE)
|
||||||
|
pidno=$((pidno1 + 1))
|
||||||
|
kill $pidno
|
||||||
|
echo "."
|
||||||
|
;;
|
||||||
|
reload|force-reload|restart)
|
||||||
|
check_for_no_start
|
||||||
|
check_keys
|
||||||
|
check_config
|
||||||
|
echo -n "Reloading OOBM server configuration"
|
||||||
|
/etc/init.d/sshd-oobm stop
|
||||||
|
/etc/init.d/sshd-oobm start
|
||||||
|
echo "."
|
||||||
|
;;
|
||||||
|
status)
|
||||||
|
pidno1=$(<$PIDFILE)
|
||||||
|
pidno=$((pidno1 + 1))
|
||||||
|
if ps -p $pidno > /dev/null
|
||||||
|
then
|
||||||
|
echo "OOBM server ($pidno) is running"
|
||||||
|
else
|
||||||
|
echo "OOBM server is not running"
|
||||||
|
fi
|
||||||
|
exit $?
|
||||||
|
;;
|
||||||
|
*)
|
||||||
|
echo "Usage: /etc/init.d/ssh-oobm {start|stop|status|reload \
|
||||||
|
|force-reload|restart}"
|
||||||
|
exit 1
|
||||||
|
esac
|
||||||
|
exit 0
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
\section{Configuration: /etc/ssh/sshd\_banner}
|
||||||
|
\label{section:appendix-ssh-sshdbanner}
|
||||||
|
\begin{verbatim}
|
||||||
|
#####################
|
||||||
|
# MultiTech Conduit #
|
||||||
|
# LoRaWAN Gateway #
|
||||||
|
#####################
|
||||||
|
|
||||||
|
MODE: Remote Gateway Management
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
\section{Configuration: /etc/ssh/sshd\_oobm\_banner}
|
||||||
|
\label{section:appendix-ssh-sshdoodbmbanner}
|
||||||
|
\begin{verbatim}
|
||||||
|
#####################
|
||||||
|
# MultiTech Conduit #
|
||||||
|
# LoRaWAN Gateway #
|
||||||
|
#####################
|
||||||
|
|
||||||
|
MODE: Out of Band Management service
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
\section{Configuration: /etc/ssh/sshd\_config}
|
||||||
|
\label{section:appendix-ssh-sshdconfig}
|
||||||
|
\begin{verbatim}
|
||||||
|
# $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $
|
||||||
|
|
||||||
|
# This is the sshd server system-wide configuration file. See
|
||||||
|
# sshd_config(5) for more information.
|
||||||
|
|
||||||
|
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
|
||||||
|
|
||||||
|
# The strategy used for options in the default sshd_config shipped with
|
||||||
|
# OpenSSH is to specify options with their default value where
|
||||||
|
# possible, but leave them commented. Uncommented options change a
|
||||||
|
# default value.
|
||||||
|
|
||||||
|
#Port 22
|
||||||
|
#AddressFamily any
|
||||||
|
#ListenAddress 0.0.0.0
|
||||||
|
#ListenAddress ::
|
||||||
|
|
||||||
|
# The default requires explicit activation of protocol 1
|
||||||
|
Protocol 2
|
||||||
|
|
||||||
|
# HostKey for protocol version 1
|
||||||
|
#HostKey /etc/ssh/ssh_host_key
|
||||||
|
# HostKeys for protocol version 2
|
||||||
|
#HostKey /etc/ssh/ssh_host_rsa_key
|
||||||
|
#HostKey /etc/ssh/ssh_host_dsa_key
|
||||||
|
#HostKey /etc/ssh/ssh_host_ecdsa_key
|
||||||
|
#HostKey /etc/ssh/ssh_host_ed25519_key
|
||||||
|
|
||||||
|
# Lifetime and size of ephemeral version 1 server key
|
||||||
|
#KeyRegenerationInterval 1h
|
||||||
|
#ServerKeyBits 1024
|
||||||
|
|
||||||
|
# Ciphers and keying
|
||||||
|
#RekeyLimit default none
|
||||||
|
|
||||||
|
# Logging
|
||||||
|
# obsoletes QuietMode and FascistLogging
|
||||||
|
#SyslogFacility AUTH
|
||||||
|
#LogLevel INFO
|
||||||
|
|
||||||
|
# Authentication:
|
||||||
|
#LoginGraceTime 2m
|
||||||
|
#PermitRootLogin yes
|
||||||
|
#StrictModes yes
|
||||||
|
#MaxAuthTries 6
|
||||||
|
#MaxSessions 10
|
||||||
|
|
||||||
|
#RSAAuthentication yes
|
||||||
|
#PubkeyAuthentication yes
|
||||||
|
|
||||||
|
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
|
||||||
|
# but this is overridden so installations will only check .ssh/authorized_keys
|
||||||
|
AuthorizedKeysFile .ssh/authorized_keys
|
||||||
|
|
||||||
|
#AuthorizedPrincipalsFile none
|
||||||
|
|
||||||
|
#AuthorizedKeysCommand none
|
||||||
|
#AuthorizedKeysCommandUser nobody
|
||||||
|
|
||||||
|
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
|
||||||
|
#RhostsRSAAuthentication no
|
||||||
|
# similar for protocol version 2
|
||||||
|
#HostbasedAuthentication no
|
||||||
|
# Change to yes if you don't trust ~/.ssh/known_hosts for
|
||||||
|
# RhostsRSAAuthentication and HostbasedAuthentication
|
||||||
|
#IgnoreUserKnownHosts no
|
||||||
|
# Don't read the user's ~/.rhosts and ~/.shosts files
|
||||||
|
#IgnoreRhosts yes
|
||||||
|
|
||||||
|
# To disable tunneled clear text passwords, change to no here!
|
||||||
|
#PasswordAuthentication yes
|
||||||
|
#PermitEmptyPasswords no
|
||||||
|
|
||||||
|
# Change to no to disable s/key passwords
|
||||||
|
ChallengeResponseAuthentication no
|
||||||
|
|
||||||
|
# Kerberos options
|
||||||
|
#KerberosAuthentication no
|
||||||
|
#KerberosOrLocalPasswd yes
|
||||||
|
#KerberosTicketCleanup yes
|
||||||
|
#KerberosGetAFSToken no
|
||||||
|
|
||||||
|
# GSSAPI options
|
||||||
|
#GSSAPIAuthentication no
|
||||||
|
#GSSAPICleanupCredentials yes
|
||||||
|
|
||||||
|
# Set this to 'yes' to enable PAM authentication, account processing,
|
||||||
|
# and session processing. If this is enabled, PAM authentication will
|
||||||
|
# be allowed through the ChallengeResponseAuthentication and
|
||||||
|
# PasswordAuthentication. Depending on your PAM configuration,
|
||||||
|
# PAM authentication via ChallengeResponseAuthentication may bypass
|
||||||
|
# the setting of "PermitRootLogin without-password".
|
||||||
|
# If you just want the PAM account and session checks to run without
|
||||||
|
# PAM authentication, then enable this but set PasswordAuthentication
|
||||||
|
# and ChallengeResponseAuthentication to 'no'.
|
||||||
|
UsePAM yes
|
||||||
|
|
||||||
|
#AllowAgentForwarding yes
|
||||||
|
#AllowTcpForwarding yes
|
||||||
|
#GatewayPorts no
|
||||||
|
X11Forwarding yes
|
||||||
|
#X11DisplayOffset 10
|
||||||
|
#X11UseLocalhost yes
|
||||||
|
#PermitTTY yes
|
||||||
|
#PrintMotd yes
|
||||||
|
#PrintLastLog yes
|
||||||
|
#TCPKeepAlive yes
|
||||||
|
#UseLogin no
|
||||||
|
UsePrivilegeSeparation sandbox # Default for new installations.
|
||||||
|
#PermitUserEnvironment no
|
||||||
|
Compression no
|
||||||
|
ClientAliveInterval 15
|
||||||
|
ClientAliveCountMax 4
|
||||||
|
#UseDNS yes
|
||||||
|
#PidFile /var/run/sshd.pid
|
||||||
|
#MaxStartups 10:30:100
|
||||||
|
#PermitTunnel no
|
||||||
|
#ChrootDirectory none
|
||||||
|
#VersionAddendum none
|
||||||
|
|
||||||
|
# no default banner path
|
||||||
|
Banner /etc/ssh/sshd_banner
|
||||||
|
|
||||||
|
# override default of no subsystems
|
||||||
|
Subsystem sftp /usr/libexec/sftp-server
|
||||||
|
|
||||||
|
# Example of overriding settings on a per-user basis
|
||||||
|
#Match User anoncvs
|
||||||
|
# X11Forwarding no
|
||||||
|
# AllowTcpForwarding no
|
||||||
|
# PermitTTY no
|
||||||
|
# ForceCommand cvs server
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
\section{Configuration: /etc/ssh/sshd\_oobm\_config}
|
||||||
|
\label{section:appendix-ssh-sshdoobmconfig}
|
||||||
|
\begin{verbatim}
|
||||||
|
# $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $
|
||||||
|
|
||||||
|
# This is the sshd server OOBM configuration file.
|
||||||
|
|
||||||
|
############################
|
||||||
|
# CONNECTIVITY #
|
||||||
|
############################
|
||||||
|
Port 1024
|
||||||
|
#AddressFamily any
|
||||||
|
#ListenAddress 0.0.0.0
|
||||||
|
#ListenAddress ::
|
||||||
|
|
||||||
|
# The default requires explicit activation of protocol 1
|
||||||
|
Protocol 2
|
||||||
|
|
||||||
|
# HostKey for protocol version 1
|
||||||
|
#HostKey /etc/ssh/ssh_host_key
|
||||||
|
# HostKeys for protocol version 2
|
||||||
|
#HostKey /etc/ssh/ssh_host_rsa_key
|
||||||
|
#HostKey /etc/ssh/ssh_host_dsa_key
|
||||||
|
#HostKey /etc/ssh/ssh_host_ecdsa_key
|
||||||
|
#HostKey /etc/ssh/ssh_host_ed25519_key
|
||||||
|
|
||||||
|
# Lifetime and size of ephemeral version 1 server key
|
||||||
|
#KeyRegenerationInterval 1h
|
||||||
|
#ServerKeyBits 1024
|
||||||
|
|
||||||
|
# Ciphers and keying
|
||||||
|
#RekeyLimit default none
|
||||||
|
|
||||||
|
############################
|
||||||
|
# LOGGING #
|
||||||
|
############################
|
||||||
|
SyslogFacility AUTH
|
||||||
|
LogLevel INFO
|
||||||
|
|
||||||
|
############################
|
||||||
|
# AUTHENTICATION #
|
||||||
|
############################
|
||||||
|
AllowGroups oobm
|
||||||
|
ForceCommand /etc/ssh/sshd_oobm_cmd
|
||||||
|
|
||||||
|
#LoginGraceTime 2m
|
||||||
|
#PermitRootLogin yes
|
||||||
|
#StrictModes yes
|
||||||
|
#MaxAuthTries 6
|
||||||
|
#MaxSessions 10
|
||||||
|
|
||||||
|
#RSAAuthentication yes
|
||||||
|
#PubkeyAuthentication yes
|
||||||
|
|
||||||
|
# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
|
||||||
|
# but this is overridden so installations will only check .ssh/authorized_keys
|
||||||
|
AuthorizedKeysFile .ssh/authorized_keys
|
||||||
|
|
||||||
|
#AuthorizedPrincipalsFile none
|
||||||
|
|
||||||
|
#AuthorizedKeysCommand none
|
||||||
|
#AuthorizedKeysCommandUser nobody
|
||||||
|
|
||||||
|
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
|
||||||
|
#RhostsRSAAuthentication no
|
||||||
|
# similar for protocol version 2
|
||||||
|
#HostbasedAuthentication no
|
||||||
|
# Change to yes if you don't trust ~/.ssh/known_hosts for
|
||||||
|
# RhostsRSAAuthentication and HostbasedAuthentication
|
||||||
|
#IgnoreUserKnownHosts no
|
||||||
|
# Don't read the user's ~/.rhosts and ~/.shosts files
|
||||||
|
#IgnoreRhosts yes
|
||||||
|
|
||||||
|
# To disable tunneled clear text passwords, change to no here!
|
||||||
|
#PasswordAuthentication yes
|
||||||
|
#PermitEmptyPasswords no
|
||||||
|
|
||||||
|
# Change to no to disable s/key passwords
|
||||||
|
ChallengeResponseAuthentication no
|
||||||
|
|
||||||
|
# Kerberos options
|
||||||
|
#KerberosAuthentication no
|
||||||
|
#KerberosOrLocalPasswd yes
|
||||||
|
#KerberosTicketCleanup yes
|
||||||
|
#KerberosGetAFSToken no
|
||||||
|
|
||||||
|
# GSSAPI options
|
||||||
|
#GSSAPIAuthentication no
|
||||||
|
#GSSAPICleanupCredentials yes
|
||||||
|
|
||||||
|
# Set this to 'yes' to enable PAM authentication, account processing,
|
||||||
|
# and session processing. If this is enabled, PAM authentication will
|
||||||
|
# be allowed through the ChallengeResponseAuthentication and
|
||||||
|
# PasswordAuthentication. Depending on your PAM configuration,
|
||||||
|
# PAM authentication via ChallengeResponseAuthentication may bypass
|
||||||
|
# the setting of "PermitRootLogin without-password".
|
||||||
|
# If you just want the PAM account and session checks to run without
|
||||||
|
# PAM authentication, then enable this but set PasswordAuthentication
|
||||||
|
# and ChallengeResponseAuthentication to 'no'.
|
||||||
|
UsePAM yes
|
||||||
|
|
||||||
|
#AllowAgentForwarding yes
|
||||||
|
#AllowTcpForwarding yes
|
||||||
|
#GatewayPorts no
|
||||||
|
X11Forwarding yes
|
||||||
|
#X11DisplayOffset 10
|
||||||
|
#X11UseLocalhost yes
|
||||||
|
#PermitTTY yes
|
||||||
|
#PrintMotd yes
|
||||||
|
#PrintLastLog yes
|
||||||
|
#TCPKeepAlive yes
|
||||||
|
#UseLogin no
|
||||||
|
UsePrivilegeSeparation sandbox # Default for new installations.
|
||||||
|
#PermitUserEnvironment no
|
||||||
|
Compression no
|
||||||
|
ClientAliveInterval 15
|
||||||
|
ClientAliveCountMax 4
|
||||||
|
#UseDNS yes
|
||||||
|
#PidFile /var/run/sshd.pid
|
||||||
|
#MaxStartups 10:30:100
|
||||||
|
#PermitTunnel no
|
||||||
|
#ChrootDirectory none
|
||||||
|
#VersionAddendum none
|
||||||
|
|
||||||
|
# no default banner path
|
||||||
|
Banner /etc/ssh/sshd_oobm_banner
|
||||||
|
|
||||||
|
# override default of no subsystems
|
||||||
|
Subsystem sftp /usr/libexec/sftp-server
|
||||||
|
|
||||||
|
# Example of overriding settings on a per-user basis
|
||||||
|
#Match User anoncvs
|
||||||
|
# X11Forwarding no
|
||||||
|
# AllowTcpForwarding no
|
||||||
|
# PermitTTY no
|
||||||
|
# ForceCommand cvs server
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
\section{Configuration: /etc/ssh/sshd\_oobm\_cmd}
|
||||||
|
\label{section:appendix-ssh-sshdoobmcmd}
|
||||||
|
\begin{verbatim}
|
||||||
|
#!/usr/bin/env bash
|
||||||
|
sudo mts-io-sysfs store ap1/serial-mode rs232
|
||||||
|
/usr/bin/screen /dev/ttyAP1 9600
|
||||||
|
\end{verbatim}
|
||||||
Reference in New Issue
Block a user