DOCSLIB.ORG

Secure Logging

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Secure Logging SYSADMIN Security Lessons: Rsyslog Making sure your logs work Secure Logging Might as well do it properly – rsyslog. BY KURT SEIFRIED drop-in replacement for sysklogd, and if you’re running a recent Debian, Ubuntu, or Fedora, it’s the default logging pack- was looking at my server backups syslog listen to the network and accept age. The bad news is that you will most the other day and suddenly realized syslog messages from remote hosts. likely need to upgrade it if you want the II had no backups of the logfiles – Problem solved, right? more advanced features. (Fedora ships you know, all the stuff in /var/log/ that Not really. The main problem is that version 2.0.6; the latest stable release is you ignore until something breaks. Also, syslog uses UDP for message transport, 5.2.0.) I realized I had no idea whether logging and UDP doesn’t guarantee delivery. So, For those of you on a different flavor was actually working, so maybe I should for example, if you accidentally firewall of Linux, chances are your vendor ships go about fixing this. syslog, the messages could simply be rsyslog, and you can simply install it dropped without any warning. If you with yum or whatever package manager Why Logging Locally Isn’t want to send logs across networks you you use (e.g., emerge -va rsyslog on Gen- Secure or Reliable don’t trust (e.g., the Internet), you can’t too Linux). Downloading the source and By definition, attackers who gain access be sure that an attacker hasn’t injected compiling it is not hard; however, you to your system can monkey around with log messages, because spoofing UDP is should make sure that you add support the logfiles, modifying them or simply much easier than TCP in that no three- for: deleting them altogether if they’re not way handshake or sequence ID is worried about being quiet. This can leave needed. Also, if an attacker is really on ./configure --enable-gnutls ^^ you with no log of how they broke in or the ball, he or she can alter messages in --enable-mysql what they did, or even that you have suf- transit, without being detected (the mes- make fered a break in. Also, your logging can sages are not protected in any way). make install simply break and stop writing logs, and, unless you’re checking those logs, you’ll Why Not SSL Wrap It? Of course, you will need the gnutls-devel never notice. Trick question. Applications like Stunnel and mysql-devel packages installed on This old problem has a simple solu- only play nicely with TCP-based ser- your system for this to work. Once com- tion: You just log to a remote host that is vices. If you’re utterly determined not to piled, you need to install rsyslog. This designed to hold the logfiles securely. run rsyslog for some reason, I suppose can be tricky because you will need to The syslog -r option will specifically let you could set up a VPN (e.g., remove the existing rsyslog or sysklogd OpenVPN), but that still won’t guaran- package forcibly and ignore the resulting tee message delivery because dependency complaints (initscripts, syslog will still be using vixie-cron, cronie, etc.) that you will re- UDP. ceive. Future updates of these packages could also be an issue because a depen- Rsyslog to the dency is missing. Unfortunately, most Rescue vendors are shipping very old versions The good news of rsyslog. Once you have rsyslog com- is that rsys- piled and installed, you will need to con- log [1] is a figure it securely. Guaranteed Delivery The first thing rsyslog does right is use TCP, which is a much more reli- able transport than UDP. The second thing rsyslog does is pro- vide application-level acknowl- edgment of messages. Thus, it pro- vides a guarantee of message deliv- ery, so even strange TCP errors won’t cause messages to disappear silently. To do this, it supports RELP (Reliable Event 54 ISSUE 115 JUNE 2010 Security Lessons: Rsyslog SYSADMIN Logging Protocol); configuration is triv- communications. If you look in the gtls Because rsyslog is a module and sup- ial on a client: Network Stream Driver documentation ports multiple inputs (and outputs), you file, you will see that the mode you want can easily run it with support for multi- *.* :omrelp:10.1.2.3:2514 to use is x509/name. This setting will ple client types (UDP, TCP, RELP, etc.). cause rsyslog to validate the certificate So, the first goal of ensuring that remote and the name before allowing the client I’m Stuck with an Older logging actually results in remote logging to communicate. Also, you should con- Rsyslog taking place is accomplished. Another figure this on the clients to ensure that If you are truly stuck with an older rsys- advantage is that a central rsyslog server an attacker can’t execute a man-in-the- log, the good news is that you can at will correctly report the origin of a mes- middle attack and impersonate a server least use Stunnel to SSL wrap it. Red Hat sage even if the sender is behind a NAT (and thus harvest potentially sensitive has a knowledge base article with de- machine with other rsyslog clients (in log messages). tailed instructions [4]. The process is other words, you will be able to tell Note that support for the x509/name pretty much like wrapping any other ser- them apart, which doesn’t work so well configuration directive only appeared in vice: You set up Stunnel on the server to with other logging packages). version 3.19.4 and later, so you’ll need accept connections, and on the client, to update Fedora (rsyslog 2.0.6), Debian you connect to the server and configure Secure Delivery (rsyslog 3.18.6), and Ubuntu 9.0.4 (rsys- a local port that is forwarded to the Secure delivery is essential; otherwise, log 3.18.6), but not Ubuntu 9.10 (rsyslog server. Rsyslog on the client machine an attacker can modify messages in tran- 4.2.0), to name a few versions of Linux. connects to the local port that sends the sit or inject fake messages and cause all data off to the server. sorts of problems (like hard disk write Off-Peak Message Delivery error warnings every day at 3am that Real-time remote logging has one prob- In Conclusion cause your pager to go off). Also, you lem, which is that network traffic will be The rsyslog package is a lot more reliable don’t want an attacker eavesdropping on steady and in some cases quite heavy and secure than syslog or sysklogd. Ad- messages. For example, if a user acciden- (someone scans servers for weak ac- ditionally, you can log to a database, tally enters her password instead of her counts, a sudden slew of errors, etc.). If send SNMP alerts, and browse events username, that password will be logged you have branch offices or remote loca- with a nice web interface [5] [6]. n (and sent to whatever remote systems tions that you want to tie into a central your logs go to), potentially exposing the logging system, you could find yourself INFO password to an attacker with access to taking up a significant portion of upload [1] Rsyslog: http://​­www.​­rsyslog.​­com/ your network traffic. To address this, bandwidth during business hours (not [2] Encrypting Syslog Traffic with TLS rsyslog supports TLS (Transport Layer all the world has high-speed Internet like (SSL): http://​­www.​­rsyslog.​­com/ Security) natively; all you need to do is Japan and Norway yet). Fortunately, doc-rsyslog_tls.​­html edit rsyslog.conf [2]. rsyslog addresses this with off-peak mes- [3] Delivery during off-peak hours: This brings up about the only flaw I sage delivery (Listing 1). http://​­wiki.​­rsyslog.​­com/​­index.​­php/ can find with rsyslog: the documenta- This will send log data to 10.1.2.3 be- OffPeakHours tion. Generally speaking, the documen- tween 10pm and 4am; otherwise, it will [4] Wrapping rsyslog with Stunnel: tation is good, but the examples are not spool the logfile locally for later trans- http://​­kbase.​­redhat.​­com/​­faq/​­docs/ always the best. In this case, the primary missions. The ActionQueueSaveOnShut- DOC-18564 example shows the $InputTCPServer- down is important; without it, you will [5] “The sys admin’s daily grind: RSys- StreamDriverAuthMode variable set to lose data if you shut down rsyslog, be- log” by Charly Kühnast, "anon", meaning no client authentica- cause it will not write data in memory to Linux Magazine June 2008, pg. 63, tion is taking place, which sort of defeats the spool. The other benefit of off-peak http://​­www.​­linux-magazine.​­com/ the whole point of using TLS to secure message delivery is that you can stagger Issues/​­2008/​­91/​­WHERE-TO-NEXT delivery times for servers so your central [6] “The sys admin’s daily grind: ph- Listing 1: Off-Peak logging server doesn’t get flooded by cli- pLogCon” by Charly Kühnast, Linux Message Delivery ents [3]. Magazine, July 2008, pg. 69, http:// www.​­linux-magazine.​­com/​­Issues/ 01 # reliably transmit messages Transitioning to Rsyslog 2008/​­92/​­MILKING-MACHINE-2.​­0 02 # during off-peak hours (10p to 4a) What if you want to start using rsyslog, 03 $ModLoad omrelp but you have older syslog clients that Kurt Seifried is an 04 $WorkDirectory /rsyslog/work # Information Secu- where to place the spool files? you can’t yet upgrade? That’s easy; run a rity Consultant spe- 05 $ActionQueueType LinkedList central rsyslog server with support for UDP messages and upgrade the clients cializing in Linux 06 $ActionQueueDequeueTimeBegin 22 when you can.
Load more

Recommended publications
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
    [Show full text]
  • Log-Management-Tenshi.Pdf
    Network Monitoring and Management Log Management Network Startup Resource Center www.ws.nsrc.org These materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International license (http://creativecommons.org/licenses/by-nc/4.0/) Log Management & Monitoring • Keep your logs in a secure place • Where they can be easily inspected • Watch your log file • They contain important information – Many things happen – Someone needs to review them – It’s not practical to do this manually Log Management & Monitoring On your routers and switches And, on your servers Log Management • Centralize and consolidate log files • Send all log messages from your routers, switches and servers to a single node – a log server. • All network hardware and UNIX/Linux servers can be monitored using some version of syslog (we use either syslog-ng or rsyslog for this workshop). • Windows can, also, use syslog with extra tools. • Save a copy of the logs locally, but, also, save them to a central log server. Syslog Basics Uses UDP protocol, port 514 Syslog messages have two attributes (in addition to the message itself): Facility Level Auth Security | Emergency (0) Authpriv User | Alert (1) Console Syslog | Critical (2) Cron UUCP | Error (3) Daemon Mail | Warning (4) Ftp Ntp | Notice (5) Kern News | Info (6) Lpr | Debug (7) Local0 ...Local7 | Centralized Logging Configuring Centralized Logging Cisco hardware – At a minimum: logging ip.of.logging.host Unix and Linux nodes – In syslogd.conf, or in rsyslog.conf, add: *.* @ip.of.log.host – Restart syslogd, rsyslog or syslog-ng Other equipment have similar options – Options to control facility and level Receiving Messages – syslog-ng • Identify the facility that the equipment is going to use to send its messages.
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • NXLOG Community Edition Reference Manual for V2.9.1716 I
    Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 i NXLOG Community Edition Reference Manual for v2.9.1716 Ed. v2.9.1716 Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 ii Copyright © 2009-2014 NXLog Ltd. Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 iii Contents 1 Introduction 1 1.1 Overview . .1 1.2 Features . .1 1.2.1 Multiplatform . .1 1.2.2 Modular architecture . .1 1.2.3 Client-server mode . .2 1.2.4 Log message sources and destinations . .2 1.2.5 Importance of security . .2 1.2.6 Scalable multi-threaded architecture . .2 1.2.7 High performance I/O . .2 1.2.8 Message buffering . .2 1.2.9 Prioritized processing . .3 1.2.10 Avoiding lost messages . .3 1.2.11 Apache-style configuration syntax . .3 1.2.12 Built-in config language . .3 1.2.13 Scheduled tasks . .3 1.2.14 Log rotation . .3 1.2.15 Different log message formats . .4 1.2.16 Advanced message processing capabilites . .4 1.2.17 Offline processing mode . .4 1.2.18 Character set and i18n support . .4 2 Installation and quickstart 5 2.1 Microsoft Windows . .5 2.2 GNU/Linux . .6 2.2.1 Installing from DEB packages (Debian, Ubuntu) . .6 2.2.2 Installing from RPM packages (CentOS, RedHat) . .6 2.2.3 Configuring nxlog on GNU/Linux . .6 Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 iv 3 Architecture and concepts 7 3.1 History .
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • Fedora 16 System Administrator's Guide
    Fedora 16 System Administrator's Guide Deployment, Configuration, and Administration of Fedora 16 Jaromír Hradílek Douglas Silas Martin Prpič Eva Kopalová Eliška Slobodová Tomáš Čapek Petr Kovář Miroslav Svoboda System Administrator's Guide John Ha David O'Brien Michael Hideo Don Domingo Fedora 16 System Administrator's Guide Deployment, Configuration, and Administration of Fedora 16 Edition 1 Author Jaromír Hradílek [email protected] Author Douglas Silas [email protected] Author Martin Prpič [email protected] Author Eva Kopalová [email protected] Author Eliška Slobodová [email protected] Author Tomáš Čapek [email protected] Author Petr Kovář [email protected] Author Miroslav Svoboda [email protected] Author John Ha Author David O'Brien Author Michael Hideo Author Don Domingo Copyright © 2011 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
    [Show full text]
  • Vetting SSL Usage in Applications with SSLINT
    2015 IEEE Symposium on Security and Privacy Vetting SSL Usage in Applications with SSLINT Boyuan He1, Vaibhav Rastogi2, Yinzhi Cao3, Yan Chen2, V.N. Venkatakrishnan4, Runqing Yang1, and Zhenrui Zhang1 1Zhejiang University 2Northwestern University 3Columbia University 4University of Illinois, Chicago [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Abstract—Secure Sockets Layer (SSL) and Transport Layer In particular, we ask the following research question: Is it Security (TLS) protocols have become the security backbone of possible to design scalable techniques that detect incorrect use the Web and Internet today. Many systems including mobile of APIs in applications using SSL/TLS libraries? This question and desktop applications are protected by SSL/TLS protocols against network attacks. However, many vulnerabilities caused poses the following challenges: by incorrect use of SSL/TLS APIs have been uncovered in recent • Defining and representing correct use. Given an SSL years. Such vulnerabilities, many of which are caused due to poor library, how do we model correct use of the API to API design and inexperience of application developers, often lead to confidential data leakage or man-in-the-middle attacks. In this facilitate detection? paper, to guarantee code quality and logic correctness of SSL/TLS • Analysis techniques for incorrect usage in software. applications, we design and implement SSLINT, a scalable, Given a representation of correct usage, how do we de- automated, static analysis system for detecting incorrect use sign techniques for analyzing programs to detect incorrect of SSL/TLS APIs.
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • Xerox® Igen™ 150 Press 3 Party Software License Disclosure
    Xerox® iGen™ 150 Press 3rd Party Software License Disclosure October 2013 The following software packages are copyrighted for use in this product according to the license stated. Full terms and conditions of all 3rd party software licenses are available from the About screen under the Help menu on the Press Interface or by accessing the Support & Drivers page located on the http://www.xerox.com website. Adobe Icons and Web Logos, license: Adobe Icons and Web Logos License Apache log4j 1.2.8, Apache log4j 1.2.9, Apache Web Services XML-RPC 1.2.b1, Apache Lucene Java 1.3, Apache Tomcat 4.1.27, license: Apache License 1.1 Apache Axis 1.x 1.4, Apache Jakarta Commons HttpClient 3.0.alpha1, Apache Jakarta Commons Logging 1.0.4, Apache Jakarta Lucene 1.9.1, Apache XML Security Java 1.3.0, saxpath 1.0 FCS, Skin Look And Feel (skinlf) 1.2.8, Spring Framework Utilities 0.7, Apache Web Services Axis 1.2rc3, Apache Xerces Java XML Parser 2.7.1, Apache XML Xalan-Java 2.7.0, Jetty - Java HTTP Servlet Server 4.0.D0, Lucene Snowball, Streaming API for XML (StAX) - JSR-173 20040819, license: Apache License 2.0 Perl 5.8.5, Perl 5.10.0, AppConfig-1.66, Archive-Tar-1.58, Compress::Zlib-2.020, Expect.pm- 1.21, File-NCopy-0.36, File-NFSLock-1.20, Filesys-Df-0.92, Filesys-DiskFree-0.06, HTML- Parser-3.69, HTML-Tagset-3.20, HTML-Template-2.9, IO-Stty-0.02, IO-Tty-1.08, IO-Zlib- 1.09, libxml-perl-0.08, Net-Netmask-1.9015, Net-Telnet-3.03, perl-5.8.3, perlindex-1.605, Pod- Escapes-1.04, Pod-POM-0.25, Pod-Simple-3.13, Proc-ProcessTable-0.45, Socket6-0.23, Stat-
    [Show full text]
  • Ubuntu Server Guide Basic Installation Preparing to Install
    Ubuntu Server Guide Welcome to the Ubuntu Server Guide! This site includes information on using Ubuntu Server for the latest LTS release, Ubuntu 20.04 LTS (Focal Fossa). For an offline version as well as versions for previous releases see below. Improving the Documentation If you find any errors or have suggestions for improvements to pages, please use the link at thebottomof each topic titled: “Help improve this document in the forum.” This link will take you to the Server Discourse forum for the specific page you are viewing. There you can share your comments or let us know aboutbugs with any page. PDFs and Previous Releases Below are links to the previous Ubuntu Server release server guides as well as an offline copy of the current version of this site: Ubuntu 20.04 LTS (Focal Fossa): PDF Ubuntu 18.04 LTS (Bionic Beaver): Web and PDF Ubuntu 16.04 LTS (Xenial Xerus): Web and PDF Support There are a couple of different ways that the Ubuntu Server edition is supported: commercial support and community support. The main commercial support (and development funding) is available from Canonical, Ltd. They supply reasonably- priced support contracts on a per desktop or per-server basis. For more information see the Ubuntu Advantage page. Community support is also provided by dedicated individuals and companies that wish to make Ubuntu the best distribution possible. Support is provided through multiple mailing lists, IRC channels, forums, blogs, wikis, etc. The large amount of information available can be overwhelming, but a good search engine query can usually provide an answer to your questions.
    [Show full text]
  • Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation David Kaloper-Meršinjak, Hannes Mehnert, Anil Madhavapeddy, and Peter Sewell, University of Cambridge https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Not-quite-so-broken TLS: lessons in re-engineering a security protocol specification and implementation David Kaloper-Mersinjakˇ †, Hannes Mehnert†, Anil Madhavapeddy and Peter Sewell University of Cambridge Computer Laboratory [email protected] † These authors contributed equally to this work Abstract sensitive services, they are not providing the security we need. Transport Layer Security (TLS) is the most widely Transport Layer Security (TLS) implementations have a deployed security protocol on the Internet, used for au- history of security flaws. The immediate causes of these thentication and confidentiality, but a long history of ex- are often programming errors, e.g. in memory manage- ploits shows that its implementations have failed to guar- ment, but the root causes are more fundamental: the chal- antee either property. Analysis of these exploits typically lenges of interpreting the ambiguous prose specification, focusses on their immediate causes, e.g. errors in mem- the complexities inherent in large APIs and code bases, ory management or control flow, but we believe their root inherently unsafe programming choices, and the impos- causes are more fundamental: sibility of directly testing conformance between imple- mentations and the specification.
    [Show full text]