DOCSLIB.ORG

Apache 2 with SSL/TLS: Step-By-Step, Part 1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Apache 2 with SSL/TLS: Step-By-Step, Part 1 Apache 2 with SSL/TLS: Step-by-Step, Part 1 Artur Maj 2005-01-18 For more than 10 years the SSL protocol has been widely used for the purpose of securing web transactions over the Internet. One can only guess how many millions or billions of dollars in transactions are processed per a day using SSL. Unfortunately, the simple fact we use SSL does not necessarily mean that the information sent over this protocol is secure. The use of weak encryption, the impossibility of verifying web servers' certificates, security vulnerabilities in web servers or the SSL libraries, as well as other attacks, may each let intruders access sensitive information -- regardless of the fact that it is being sent through the SSL. This article begins a series of three articles dedicated to configuring Apache 2.0 with SSL/TLS support in order to ensure maximum security and optimal performance of the SSL communication. This article, part one, introduces key aspects of SSL/TLS and then shows how to install and configure Apache 2.0 with support for these protocols. The second part discusses the configuration of mod_ssl, and then addresses issues with web server authentication. The second article also shows how to create web server's SSL certificate. The third and final article in this series discusses client authentication and some typical configuration mistakes made by administrators that may decrease the security level of any SSL communication. Introduction to SSL Secure Sockets Layer (SSL) is the most widely known protocol that offers privacy and good reliability for client-server communication over the Internet. SSL itself is conceptually quite simple: it negotiates the cryptography algorithms and keys between two sides of a communication, and establishes an encrypted tunnel through which other protocols (like HTTP) can be transported. Optionally, SSL can also authenticate both sides of communication through the use of certificates. SSL is a layered protocol and consists of four sub-protocols: • SSL Handshake Protocol • SSL Change Cipher Spec Protocol • SSL Alert Protocol • SSL Record Layer The position of the above protocols according to the TCP/IP model has been illustrated on the following diagram in Figure 1. Figure 1. SSL sub-protocols in the TCP/IP model As the above diagrams shows, SSL is found in the application layer of the TCP/IP model. By dint of this feature, SSL can be implemented on almost every operating system that supports TCP/IP, without the need to modify the system kernel or the TCP/IP stack. This gives SSL a very strong advantage over other protocols like IPSec (IP Security Protocol), which requires kernel support and a modified TCP/IP stack. SSL can also be easily passed through firewalls and proxies, as well as through NAT (Network Address Translation) without issues. How does SSL work? The diagram below, Figure 2, shows the simplified, step-by-step process of establishing each new SSL connection between the client (usually a web browser) and the server (usually an SSL web server). Figure 2. How SSL established connections, step-by-step. As you can see from Figure 2, the process of establishing each new SSL connection starts with exchanging encryption parameters and then optionally authenticating the servers (using the SSL Handshake Protocol). If the handshake is successful and both sides agree on a common cipher suite and encryption keys, the application data (usually HTTP, but it can be another protocol) can be sent through encrypted tunnel (using the SSL Record Layer). In reality, the above process is in fact a little bit more complicated. To avoid unnecessary handshakes, some of the encryption parameters are being cached. Alert messages may be sent. Ciphers suites can be changed as well. However, regardless of the SSL specification details, the most common way this process actually works is very similar to the above. SSL, PCT, TLS and WTLS (but not SSH) Although SSL is the most known and the most popular, it is not the only protocol that has been used for the purpose of securing web transactions. It is important to know that since invention of SSL v1.0 (which has never been released, by the way) there have been at least five protocols that have played a more-or-less important role in securing access to World Wide Web, as we see below: • SSL v2.0 Released by Netscape Communications in 1994. The main goal of this protocol was to provide security for transactions over the World Wide Web. Unfortunately, very quickly a number of security weaknesses were found in this initial version of the SSL protocol, thus making it less reliable for commercial use: o weak MAC construction o possibility of forcing parties to use weaker encryption o no protection for handshakes o possibility of an attacker performing truncation attacks • PCT v1.0 Developed in 1995 by Microsoft. Privacy Communication Technology (PCT) v1.0 addressed some weaknesses of SSL v2.0, and was aimed to replace SSL. However, this protocol has never gained as much popularity as SSL v3.0. • SSL v3.0 Released in 1996 by Netscape Communications. SSL v3.0 solved most of the SSL v2.0 problems, and incorporated many of the features of PCT. Pretty quickly become the most popular protocol for securing communication over WWW. • TLS v1.0 (also known as SSL v3.1) Published by IETF in 1999 (RFC 2246). This protocol is based on SSL v3.0 and PCT and harmonizes both Netscape's and Microsoft's approaches. It is important to note that although TLS is based on SSL, it is not a 100% backward compatible with its predecessor. IETF did some security improvements, such as using HMAC instead of MAC, using a different calculation of the master secret and key material, adding additional alert codes, no support for Fortezza cipher suites, and so on. The end result of these improvements is that these protocols don't fully interoperate. Fortunately enough, TLS has also got a mode to fall back to SSL v3.0. • WTLS "Mobile and wireless" version of the TLS protocol that uses the UDP protocol as a carrier. It is designed and optimized for the lower bandwidth and smaller processing capabilities of WAP-enabled mobile devices. WTLS was introduced with the WAP 1.1 protocol, and was released by the WAP Forum. However, after the introduction of the WAP 2.0 protocol, WTLS has been replaced by a profiled version of the TLS protocol, which is much more secure -- mainly because there is no need for decryption and re- encryption of the traffic at the WAP gateway. Why has the SSH (Secure Shell) protocol not been used for the purpose of providing secure access to World Wide Web? There are few reasons why not. First of all, from the very beginning TLS and SSL were designed for securing web (HTTP) sessions, whereas SSH was indented to replace Telnet and FTP. SSL does nothing more than handshake and establishing encryption tunnel, and at the same time SSH offers console login, secure file transfer, and support for multiple authentication schemes (including passwords, public keys, Kerberos, and more). On the other hand, SSL/TLS is based on X.509v3 certificates and PKI, which makes the distribution and management of authentication credentials much easier to perform. Hence, these and other reasons make SSL/TLS more suitable for securing WWW access and similar forms of communication, including SMTP, LDAP and others -- whereas SSH is more convenient for remote system management. To summarize, although several "secure" protocols do indeed exist, only two of them should be used for the purpose of securing web transactions (at least at the moment): TLS v1.0 and SSL v3.0. Both of them are further referred in this article series as simply SSL/TLS. Because of known weaknesses of SSL v2.0, and the famous "WAP gap" in case of WTLS, the use of these other protocols should be avoided or at least minimized. Software requirements This next part of the article shows how to configure Apache 2.0 with SSL/TLS support, using the mod_ssl module. Therefore, before going further, readers are encouraged to download the latest version of Apache's 2.0 source code from Apache's web site. Most of the examples should also work for Apache 1.3.x - in that case, however, mod_ssl need to be downloaded separately from Apache's source code, from the mod_ssl website. The practical examples presented in the article should work on most Linux, Linux-like and BSD-based operating systems. The only requirement for the operating system is to have both GCC and the OpenSSL library installed. As a default web browser, MS Internet Explorer has been chosen for our testing, mainly because of ubiquitous popularity of that browser. However, any modern web browser can be used, including FireFox, Mozilla, Netscape, Safari, Opera and others). Installing Apache with SSL/TLS support The first step in order to install Apache with SSL/TLS support is to configure and install the Apache 2 web server, and create a user and group named "apache". A secure way of installing Apache's 2.0 has already been published on SecurityFocus in the article Securing Apache 2.0: Step-by-Step. The only difference to that process is to enable mod_ssl and mod_setenvif, which is required to provide compatibility with some versions of MS Internet Explorer, as follows (changes shown in bold): ./configure \ --prefix=/usr/local/apache2 \ --with-mpm=prefork \ --enable-ssl \ --disable-charset-lite \ --disable-include \ --disable-env \ --enable-setenvif \ --disable-status \ --disable-autoindex \ --disable-asis \ --disable-cgi \ --disable-negotiation \ --disable-imap \ --disable-actions \ --disable-userdir \ --disable-alias \ --disable-so After configuring, we can install Apache into the destination directory: make su umask 022 make install chown -R root:sys /usr/local/apache2 Configuring SSL/TLS Before running Apache for a first time, we need also to provide an initial configuration and prepare some sample web content.
Load more

Recommended publications
  • BALG: Bypassing Application Layer Gateways Using Multi-Staged Encrypted Shellcodes
    Sebastian Roschke, Feng Cheng, Christoph Meinel: "BALG: Bypassing Application Layer Gateways Using Multi-Staged Encrypted Shellcodes" in Proceedings of the 12th IFIP/IEEE International Symposium on Integrated Network Management (IM 2011), IEEE Press, Dublin, Ireland, pp. 399-406, 5, 2011. ISBN: 978-1-4244-9219-0. BALG: Bypassing Application Layer Gateways Using Multi-Staged Encrypted Shellcodes Sebastian Roschke Feng Cheng Christoph Meinel Hasso Plattner Institute (HPI) Hasso Plattner Institute (HPI) Hasso Plattner Institute (HPI) University of Potsdam University of Potsdam University of Potsdam 14482, Potsdam, Germany 14482, Potsdam, Germany 14482, Potsdam, Germany Email: [email protected] Email: [email protected] Email: [email protected] Abstract—Modern attacks are using sophisticated and inno- easily penetrated by simple tunneling. IDS needs to handle vative techniques. The utilization of cryptography, self-modified efficient evasion techniques. ALGs provide more restrictions code, and integrated attack frameworks provide more possibili- for network access by combining filtering on the application ties to circumvent most existing perimeter security approaches, such as firewalls and IDS. Even Application Layer Gateways layer and IDS techniques, such as deep packet inspection. (ALG) which enforce the most restrictive network access can be Most of ALG implementations provide filtering due to ap- exploited by using advanced attack techniques. In this paper, plication layer protocol compliance and even allow to block we propose a new attack for circumventing ALGs. By using certain commands within a specific protocol. Although ALGs polymorphic and encrypted shellcode, multiple shellcode stages, enforce a very restrictive access policy, it is still possible to protocol compliant and encrypted shell tunneling, and reverse channel discovery techniques, we are able to effectively bypass circumvent such devices by using modern attack techniques.
    [Show full text]
  • VPN 3000 Series Concentrator Reference Volume II: Administration and Monitoring Release 3.6 August 2002
    VPN 3000 Series Concentrator Reference Volume II: Administration and Monitoring Release 3.6 August 2002 Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100 Customer Order Number: DOC-7814742= Text Part Number: 78-14742-01 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • Case Study: Internet Explorer 1994..1997
    Case Study: Internet Explorer 1994..1997 Ben Slivka General Manager Windows UI [email protected] Internet Explorer Chronology 8/94 IE effort begins 12/94 License Spyglass Mosaic source code 7/95 IE 1.0 ships as Windows 95 feature 11/95 IE 2.0 ships 3/96 MS Professional Developer’s Conference AOL deal, Java license announced 8/96 IE 3.0 ships, wins all but PC Mag review 9/97 IE 4.0 ships, wins all the reviews IE Feature Chronology IE 1.0 (7/14/95) IE 2.0 (11/17/95) HTML 2.0 HTML Tables, other NS enhancements HTML <font face=> Cell background colors & images Progressive Rendering HTTP cookies (arthurbi) Windows Integration SSL Start.Run HTML (MS enhancements) Internet Shortcuts <marquee> Password Caching background sounds Auto Connect, in-line AVIs Disconnect Active VRML 1.0 Navigator parity MS innovation Feature Chronology - continued IE 3.0 (8/12/96) IE 3.0 - continued... IE 4.0 (9/12/97) Java Accessibility Dynamic HTML (W3C) HTML Frames PICS (W3C) Data Binding Floating frames HTML CSS (W3C) 2D positioning Componentized HTML <object> (W3C) Java JDK 1.1 ActiveX Scripting ActiveX Controls Explorer Bars JavaScript Code Download Active Setup VBScript Code Signing Active Channels MSHTML, SHDOCVW IEAK (corporations) CDF (XML) WININET, URLMON Internet Setup Wizard Security Zones DocObj hosting Referral Server Windows Integration Single Explorer ActiveDesktop™ Navigator parity MS innovation Quick Launch, … Wins for IE • Quality • CoolBar, Explorer Bars • Componetization • Great Mail/News Client • ActiveX Controls – Outlook Express – vs. Nav plug-ins
    [Show full text]
  • Configuring SSH and Telnet
    Configuring SSH and Telnet This chapter describes how to configure Secure Shell Protocol (SSH) and Telnet on Cisco NX-OS devices. This chapter includes the following sections: • About SSH and Telnet, on page 1 • Licensing Requirements for SSH and Telnet, on page 3 • Prerequisites for SSH and Telnet, on page 3 • Guidelines and Limitations for SSH and Telnet, on page 3 • Default Settings for SSH and Telnet, on page 4 • Configuring SSH , on page 4 • Configuring Telnet, on page 15 • Verifying the SSH and Telnet Configuration, on page 17 • Configuration Example for SSH, on page 18 • Configuration Example for SSH Passwordless File Copy, on page 19 • Additional References for SSH and Telnet, on page 21 About SSH and Telnet This section includes information about SSH and Telnet. SSH Server You can use the SSH server to enable an SSH client to make a secure, encrypted connection to a Cisco NX-OS device. SSH uses strong encryption for authentication. The SSH server in the Cisco NX-OS software can interoperate with publicly and commercially available SSH clients. The user authentication mechanisms supported for SSH are RADIUS, TACACS+, LDAP, and the use of locally stored usernames and passwords. SSH Client The SSH client feature is an application that runs over the SSH protocol to provide device authentication and encryption. The SSH client enables a Cisco NX-OS device to make a secure, encrypted connection to another Cisco NX-OS device or to any other device that runs the SSH server. This connection provides an outbound Configuring SSH and Telnet 1 Configuring SSH and Telnet SSH Server Keys connection that is encrypted.
    [Show full text]
  • Planning for Internet Explorer and the IEAK
    02_Inst.fm Page 15 Monday, October 16, 2000 9:40 AM TWO 2Chapter 2 Planning for Internet Explorer and the IEAK LChapter Syllabus In this chapter, we will look at material covered in the Planning section of Microsoft’s Implementing MCSE 2.1 Addressing Technical Needs, Rules, and Policies and Supporting Microsoft Internet Explorer 5 by using the Internet Explorer Administration Kit exam MCSE 2.2 Planning for Custom (70-080). After reading this chapter, you should be Installations and Settings able to: MCSE 2.3 Providing Multiple • Identify and evaluate the technical needs of business Language Support units, such as Internet Service Providers (ISPs), con- tent providers, and corporate administrators. MCSE 2.4 Providing Multiple Platform Support • Design solutions based on organizational rules and policies for ISPs, content providers, and corporate MCSE 2.5 Developing Security Strategies administrators. • Evaluate which components to include in a custom- MCSE 2.6 Configuring for Offline ized Internet Explorer installation package for a given Viewing deployment scenario. MCSE 2.7 Replacing Other Browsers • Develop appropriate security strategies for using Internet Explorer at various sites, including public MCSE 2.8 Developing CMAK kiosks, general business sites, single-task-based sites, Strategies and intranet-only sites. 15 02_Inst.fm Page 16 Monday, October 16, 2000 9:40 AM 16 Chapter 2 • Planning for Internet Explorer and the IEAK • Configure offline viewing for various types of users, including gen- eral business users, single-task users, and mobile users. • Develop strategies for replacing other Internet browsers, such as Netscape Navigator and previous versions of Internet Explorer. • Decide which custom settings to configure for Microsoft Outlook Express for a given scenario.
    [Show full text]
  • Secured Connectivity Why It Matters and How to Protect Your Organization
    Secured Connectivity Why it Matters and How to Protect Your Organization While every attempt has been made to ensure the accuracy and completeness of the information in this document, some typographical or technical errors may exist. Hummingbird Connectivity – a division of Open Text cannot accept responsibility for customers’ losses resulting from the use of this document. The information contained in this document is subject to change without notice. This document contains proprietary information that is protected by copyright. This document, in whole or in part, may not be photocopied, reproduced, or translated into another language without prior written consent from Hummingbird Connectivity. This edition published September 2008 www.hummingbird.com 2 Contents The Security Challenge 4 Security in Organizations 5 Driving Security 6 Structural Factors 6 External Factors 6 Connectivity — A Definition 7 Security Risks in a Connectivity World 8 Weak Authentication 8 Easy Protocol Decoding 8 Data Authenticity and Integrity Tampering 8 Solutions for Secured Connectivity 9 SSL 9 Kerberos 10 Secure Shell 11 ® Connectivity SecureTerm 12 ™ Connectivity Secure Shell 14 Connectivity Secure Server 16 Secure Replacement for Telnet and FTP 16 High Performance and Scalability 16 Glossary of Terms 18 www.hummingbird.com 3 The Security Challenge Security is the hot topic today. Although, companies have been slow to recognize the importance of security things have changed during the last decade. Security is a top priority and there are no indications that this will end any time soon. The costs of security (or lack thereof) have now been clearly identified, and the picture does not look very good.
    [Show full text]
  • NBAR2 Standard Protocol Pack 1.0
    NBAR2 Standard Protocol Pack 1.0 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883 © 2013 Cisco Systems, Inc. All rights reserved. CONTENTS CHAPTER 1 Release Notes for NBAR2 Standard Protocol Pack 1.0 1 CHAPTER 2 BGP 3 BITTORRENT 6 CITRIX 7 DHCP 8 DIRECTCONNECT 9 DNS 10 EDONKEY 11 EGP 12 EIGRP 13 EXCHANGE 14 FASTTRACK 15 FINGER 16 FTP 17 GNUTELLA 18 GOPHER 19 GRE 20 H323 21 HTTP 22 ICMP 23 IMAP 24 IPINIP 25 IPV6-ICMP 26 IRC 27 KAZAA2 28 KERBEROS 29 L2TP 30 NBAR2 Standard Protocol Pack 1.0 iii Contents LDAP 31 MGCP 32 NETBIOS 33 NETSHOW 34 NFS 35 NNTP 36 NOTES 37 NTP 38 OSPF 39 POP3 40 PPTP 41 PRINTER 42 RIP 43 RTCP 44 RTP 45 RTSP 46 SAP 47 SECURE-FTP 48 SECURE-HTTP 49 SECURE-IMAP 50 SECURE-IRC 51 SECURE-LDAP 52 SECURE-NNTP 53 SECURE-POP3 54 SECURE-TELNET 55 SIP 56 SKINNY 57 SKYPE 58 SMTP 59 SNMP 60 SOCKS 61 SQLNET 62 SQLSERVER 63 SSH 64 STREAMWORK 65 NBAR2 Standard Protocol Pack 1.0 iv Contents SUNRPC 66 SYSLOG 67 TELNET 68 TFTP 69 VDOLIVE 70 WINMX 71 NBAR2 Standard Protocol Pack 1.0 v Contents NBAR2 Standard Protocol Pack 1.0 vi CHAPTER 1 Release Notes for NBAR2 Standard Protocol Pack 1.0 NBAR2 Standard Protocol Pack Overview The Network Based Application Recognition (NBAR2) Standard Protocol Pack 1.0 is provided as the base protocol pack with an unlicensed Cisco image on a device.
    [Show full text]
  • Fdc3302e Frequency Distribution Chassis
    "Smarter Timing Solutions" FDC3302e Frequency Distribution Chassis User Manual USM3302-0800-000 Revision 2 March 2019 FDC3302e Frequency Distribution Chassis User Manual Preface Thank you for purchasing the Frequency Distribution Chassis. Our goal in developing this product is to bring you a distribution chassis that will quickly, easily and reliably meet or exceed your system requirements. Your new FDC3302e is fabricated using the highest quality materials and manufactur- ing processes available today, and will give you years of trouble-free service. About EndRun Technologies EndRun Technologies is dedicated to the development and refinement of the technologies required to fulfill the demanding needs of the time and frequency community. The instruments produced by EndRun Technologies have been selected as the timing reference for a variety of industries and applications - computer networks, satellite earth stations, power utilities, test ranges, broadcast and telecommunications systems and more. EndRun Technologies is committed to fulfilling your precision timing needs by providing the most advanced, reliable and cost-effective time and frequency equipment available in the market today. Trademark Acknowledgements IBM-PC, UNIX, Windows NT are registered trademarks of the respective holders. Part No. USM3302-0800-000 Revision 2 March 2019 Copyright © EndRun Technologies 2007-2019 FDC3302e User Manual About This Manual This manual will guide you through simple installation and set up procedures. Introduction – The Frequency Distribution Chassis, how it works, where to use it, its main features. Basic Installation – How to connect, configure and test your distribution chassis. Console Port – Description of the console commands for use over the serial port or optional network port.
    [Show full text]
  • An Adaptive Multi-Layer Botnet Detection Technique Using Machine Learning Classifiers
    applied sciences Article An Adaptive Multi-Layer Botnet Detection Technique Using Machine Learning Classifiers Riaz Ullah Khan 1,* , Xiaosong Zhang 1, Rajesh Kumar 1 , Abubakar Sharif 1, Noorbakhsh Amiri Golilarz 1 and Mamoun Alazab 2 1 Center of Cyber Security, School of Computer Science & Engineering, University of Electronic Science and Technology of China, Chengdu 611731, China; [email protected] (X.Z.); [email protected] (R.K.); [email protected] (A.S.); [email protected] (N.A.G.) 2 College of Engineering, IT and Environment, Charles Darwin University, Casuarina 0810, Australia; [email protected] * Correspondence: [email protected]; Tel.: +86-155-2076-3595 Received: 19 March 2019; Accepted: 24 April 2019; Published: 11 June 2019 Abstract: In recent years, the botnets have been the most common threats to network security since it exploits multiple malicious codes like a worm, Trojans, Rootkit, etc. The botnets have been used to carry phishing links, to perform attacks and provide malicious services on the internet. It is challenging to identify Peer-to-peer (P2P) botnets as compared to Internet Relay Chat (IRC), Hypertext Transfer Protocol (HTTP) and other types of botnets because P2P traffic has typical features of the centralization and distribution. To resolve the issues of P2P botnet identification, we propose an effective multi-layer traffic classification method by applying machine learning classifiers on features of network traffic. Our work presents a framework based on decision trees which effectively detects P2P botnets. A decision tree algorithm is applied for feature selection to extract the most relevant features and ignore the irrelevant features.
    [Show full text]
  • Getting Started with Your Dedicated Server
    Getting Started Guide Getting Started With Your Dedicated Server Setting up and hosting a domain on your Linux® Dedicated Server using Plesk 8.0®. Getting Started with Your Dedicated Server ‐ Plesk 8.0 Version 1.1 (06.23.08) © Copyright 2008. All rights reserved. Distribution of this work or derivative of this work is prohibited unless prior written permission is obtained from the copyright holder. Trademarks Used in This Book Linux® is a registered trademark of Linus Torvalds. Plesk® is a registered trademark of SW­soft Holdings, LTD. SSH® and Secure Shell® are trademarks of SSH Communications Security, Inc. RedHat® and Fedora® are registered trademarks of Red Hat Software, Inc. Mac® is a registered trademark of Apple Computer, Inc. UNIX® is a registered trademark of The Open Group. Windows XP®, Entourage®, and Outlook® are registered trademarks of Microsoft Corporation in the United States and/or other countries. Thunderbird™ is an unregistered trademark of the Mozilla Foundation. All other trademarks and copyrights are the property of their respective owners. Table of Contents Introduction iv Security Information iv Reprovisioning Your Server vi Getting Help vi Other Resources vii 1 Setting Up Your Dedicated Server 1 Choosing a Host Name, User ID, and Password 1 Choosing a Host Name 1 Choosing a User ID 2 Choosing a Password for Your Server 2 Logging in to Your Manager for the First Time 3 2 Connecting to Your Dedicated Server 5 Connecting to Your Server Using Plesk 5 Connecting to Your Server Using SSH 10 Gaining Root Access on Your
    [Show full text]
  • Microsoft Palladium
    Microsoft Palladium: A Business Overview Combining Microsoft Windows Features, Personal Computing Hardware, and Software Applications for Greater Security, Personal Privacy, and System Integrity by Amy Carroll, Mario Juarez, Julia Polk, Tony Leininger Microsoft Content Security Business Unit June 2002 Legal Notice This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.
    [Show full text]
  • Remote File Access System for Generic Ericsson Processor Boards
    Remote File Access System for Generic Ericsson Processor Boards DANIEL JESÚS GARCÍA MORAL KTH Information and Communication Technology Degree project in Communication Systems Second level, 30.0 HEC Stockholm, Sweden Remote File Access System for Generic Ericsson Processor Boards File transfer service, Random Access Memory-based file system and secure file transfer solution research DANIEL JESÚS GARCÍA MORAL Master’s Degree Project Supervisor: Lukas Karlsson Examiner: Mark Smith Stockholm, Sweden October 2011 iii Abstract Generic Ericsson Processor boards are general purpose hardware platforms which provide generic processing services. They support the Unified Exten- sible Firmware Interface Specification. They have several network interfaces available and they are connected to Ericsson’s laboratory network. Several servers are also connected to this network. These boards require periodic firmware upgrades. They also require acquiring new firmware components and data files. Currently, an application to download or upload files from and to Ericsson’s laboratory servers when an Operating System has not already been booted does not exist. Therefore, the files have to be transferred to USB drives which are connected later to the boards in order to transfer the files. This is a time consuming operation which decreases Er- icsson’s productivity. In addition, although Generic Ericsson Processor boards have an optional solid-state drive as secondary storage, Ericsson wants to be able to operate without it. This is because this secondary storage is not al- ways available and Ericsson does not want to use it when the Generic Ericsson Processor boards are operating before an Operating System has been loaded. They prefer to use Random Access Memory storage.
    [Show full text]