DOCSLIB.ORG

Linux Networking

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Linux Networking Linux Networking This tutorial covers TCP/IP networking and system configuration basics. Linux can support multiple network devices. The device names are numbered and begin at zero and count upwards. For example, a computer running two ethernet cards will have two devices labeled /dev/eth0 and /dev/eth1. Linux network configuration, management, monitoring and system tools are covered in this tutorial. Tutorial Contents: Other YoLinux Networking Tutorials: l # Configuration files l Setting up an internet gateway for home or office l # Red Hat Linux network GUI using iptables configuration tools. l Load balancing servers using LVS (Linux Virtual l # Assigning an IP address Server) l # Activating and De­Activating your NIC l Modem dial­up: l # Subnets ¡ Configuring PPP dial up connections to an l # Enable Forwarding ISP l # Adding a network interface card (NIC) ¡ Dialing Compuserve l # Route ¡ Dialing AOL l # VPN, Tunneling ¡ Configuring PPP dial­in connections l # Usefull Linux networking commands l DNS Name server configuration l # inetd/xinetd: Network Socket l DHCP server configuration: Dynamic Host Listener Daemons Configuration Protocol # rwhod: Remote Who Daemon l l NIS authentication configuration: Server and Client # RPC: Remote Procedure Call. l l Internet/Network Security (portmapper) l Security Tools and Hacker Tools l # PAM: Network Wrappers. l YoLinux Tutorials Index l # ICMP protocol. l # Network Monitoring Tools l # IDS: Intruder Detection System ­ SNORT l # ARP: Address Resolution Protocol l # Configuring Linux For Network Multicast l # Living in a MS/Windows world l # Network Definitions l # Related Links TCP/IP Network Configuration Files: l File: /etc/resolv.conf ­ host name resolver configuration file search name­of­domain.com ­ Name of your domain or ISP's domain if using their name server nameserver XXX.XXX.XXX.XXX ­ IP address of primary name server nameserver XXX.XXX.XXX.XXX ­ IP address of secondary name server This configures Linux so that it knows which DNS server will be resolving domain names into IP addresses. If using DHCP client, this will automatically be sent to you by the ISP and loaded into this file as part of the DHCP protocol. If using a static IP address, ask the ISP or check another machine on your network. Red Hat/Fedora GUI: /usr/sbin/system­config­network (select tab "DNS". l File: /etc/hosts ­ locally resolve node names to IP addresses 127.0.0.1 your­node­name.your­domain.com localhost.localdomain localhost XXX.XXX.XXX.XXX node­name Note when adding hosts to this file, place the fully qualified name first. (It helps sendmail identify your server correctly) i.e.: XXX.XXX.XXX.XXX superserver.yolinux.com superserver This informs Linux of local systems on the network which are not handled by the DNS server. (or for all systems in your LAN if you are not using DNS or NIS) Red Hat/Fedora GUI: /usr/sbin/system­config­network (select tab "Hosts". l File: /etc/nsswitch.conf ­ System Databases and Name Service Switch configuration file hosts: files dns nisplus nis This example tells Linux to first resolve a host name by looking at the local hosts file(/etc/hosts), then if the name is not found look to your DNS server as defined by /etc/resolv.conf and if not found there look to your NIS server. In the past this file has had the following names: /etc/nsswitch.conf, /etc/svc.conf, /etc/netsvc.conf, ... depending on the distribution. Free Information Technology Magazine Fedora / Red Hat Network Configuration Files: Subscriptions and Document l /etc/sysconfig/network Downloads Red Hat network configuration file used by the system during the boot process. l File: /etc/sysconfig/network­scripts/ifcfg­eth0 Configuration settings for your first ethernet port (0). Your second port is eth1. l File: ¡ /etc/modprobe.conf (kernel 2.6) ¡ /etc/modules.conf (kernel 2.4) ¡ (or for older systems: /etc/conf.modules) Example statement for Intel ethernet card: alias eth0 eepro100 Modules for other devices on the system will also be listed. This tells the kernel which device driver to use if configured as a loadable module. (default for Red Hat) Fedora / Red Hat Network GUI Configuration Tools: The following GUI tools edit the system configuration files. There is no difference in the configuration developed with the GUI tools and that developed by editing system configuration files directly. TCP/IP ethernet configuration: l Network configuration: /usr/sbin/system­config­network (FC­2/3) GUI shown here ­­­> /usr/bin/redhat­config­network (/usr/bin/neat) (RH 7.2+ FC­1) l Text console configuration tool: /usr/sbin/system­config­network­tui (Text User Interface (TUI) for Fedora Core 2/3) /usr/bin/redhat­config­network­tui (RH 9.0 ­ FC­1) l Text console network configuration tool. First interface only ­ eth0: /usr/sbin/netconfig l /usr/bin/netcfg (GUI) (last available with RH 7.1) Gnome Desktop: l Gnome Desktop Network Configuration /usr/bin/gnome­network­preferences (RH 9.0 ­ FC­3) Proxy configuration. Choose one of three options: 1. Direct internet connection 2. Manual proxy configuration (specify proxy and port) 3. Automatic proxy configuration (give URL) Assigning an IP address: Computers may be assiged a static IP address or assigned one dynamically. Static IP address assignment: Choose one of the following methods: l Command Line: /sbin/ifconfig eth0 192.168.10.12 netmask 255.255.255.0 broadcast 192.168.10.255 Network address by convention would be the lowest: 192.168.10.0 Broadcast address by convention would be the highest: 192.168.10.255 The gateway can be anything, but following convention: 192.168.10.1 Note: the highest and lowest addresses are based on the netmask. The previous example is based on a netmask of 255.255.255.0 l Red Hat / Fedora GUI tools: ¡ /usr/bin/neat Gnome GUI network administration tool. Handles all interfaces. Configure for Static IP or DHCP client. (First available with Red Hat 7.2.) ¡ /usr/bin/netcfg (Handles all interfaces) (last available in Red Hat 7.1) l Red Hat / Fedora Console tools: ¡ /usr/sbin/system­config­network­tui (Text User Interface) ¡ /usr/sbin/netconfig (Only seems to work for the first network interface eth0 but not eth1,...) l Directly edit configuration files/scripts. See format below. The ifconfig command does NOT store this information permanently. Upon reboot this information is lost. (Manually add the commands to the end of the file /etc/rc.d/rc.local to execute them upon boot.) The commands netcfg and netconfig make permanent changes to system network configuration files located in /etc/sysconfig/network­scripts/, so that this information is retained. The IANA has allocated IP addresses in the range of 192.168.0.0 to 192.168.255.255 for private networks. Helpful tools: l Network Calculators: Subnet mask calculator, node calculator, mask inverter, ... l IP subnet calculator Ubuntu / Debian IP Configuration Files: File: /etc/network/interfaces Static IP example: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 208.88.34.106 netmask 255.255.255.248 broadcast 208.88.34.111 network 208.88.34.104 gateway 208.88.34.110 Dynamic IP (DHCP) example: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet dhcp auto eth2 iface eth2 inet dhcp auto ath0 iface ath0 inet dhcp auto wlan0 iface wlan0 inet dhcp Interfaces: l lo: Loopback interface (network within your system without slowing down for the real ethernet based network) l eth0: First ethernet interface card l wlan0: First wireless network interface Also see "man interfaces" Red Hat / Fedora Core IP Configuration Files: The Red Hat configuration tools store the configuration information in the file /etc/sysconfig/network. They will also allow one to configure routing information. l File: /etc/sysconfig/network Static IP address Configuration: (Configure gateway address) NETWORKING=yes HOSTNAME=my­hostname ­ Hostname is defined here and by command hostname FORWARD_IPV4=true ­ True for NAT firewall gateways and linux routers. False for everyone else ­ desktops and servers. GATEWAY="XXX.XXX.XXX.YYY" ­ Used if your network is connected to another network or the internet. Static IP configuration. Gateway not defined here for DHCP client. OR for DHCP client configuration: NETWORKING=yes HOSTNAME=my­hostname ­ Hostname is defined here and by command hostname (Gateway is assigned by DHCP server.) OR for NIS client configuration: NETWORKING=yes HOSTNAME=my­hostname ­ Hostname is defined here and by command hostname NISDOMAIN=NISProject1 ­ NIS domain to attach l File (Red Hat/Fedora): /etc/sysconfig/network­scripts/ifcfg­eth0 (S.u.s.e.: /etc/sysconfig/network/ifcfg­eth­id­XX:XX:XX:XX:XX) This file used by the command scripts ifup and ifdown Static IP address configuration: DEVICE=eth0 BOOTPROTO=static BROADCAST=XXX.XXX.XXX.255 IPADDR=XXX.XXX.XXX.XXX NETMASK=255.255.255.0 NETWORK=XXX.XXX.XXX.0 ONBOOT=yes ­ Will activate upon system boot RHEL4/FC3 additions: l TYPE=Ethernet l HWADDR=XX:XX:XX:XX:XX:XX l GATEWAY=XXX.XXX.XXX.XXX OR for DHCP client configuration: DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp RHEL4/FC3 additions: l IPV6INIT=no l USERCTL=no l PEERDNS=yes l TYPE=Ethernet l HWADDR=XX:XX:XX:XX:XX:XX (Used by script /etc/sysconfig/network­scripts/ifup to bring the various network interfaces on­line) To disable DHCP change BOOTPROTO=dhcp to BOOTPROTO=none In order for updated information in any of these files to take effect, one must issue the command: service network restart (or: /etc/init.d/network restart) Changing the host name: This is a three step process: 1. Issue the command: hostname new­host­name 2. Change network configuration file: /etc/sysconfig/network Edit entry: HOSTNAME=new­host­name 3.
Load more

Recommended publications
  • Master Thesis
    Master's Programme in Computer Network Engineering, 60 credits MASTER Connect street light control devices in a secure network THESIS Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Network security, 15 credits Halmstad 2015-02-16 “Connect street light control devices in a secure network” Master’s Thesis in Computer Network engineering 2014 Authors: Andreas Kostoulas, Efstathios Lykouropoulos, Zainab Jumaa Supervisor: Alexey Vinel Examiner: Tony Larsson Preface This thesis is submitted in partial fulfilment of the requirements for a Master’s Degree in Computer Network Engineering at the Department of Information Science - Computer and Electrical Engineering, at University of Halmstad, Sweden. The research - implementation described herein was conducted under the supervision of Professor Alexey Vinel and in cooperation with Greinon engineering. This was a challenging trip with both ups and downs but accompanied by an extend team of experts, always willing to coach, sponsor, help and motivate us. For this we would like to thank them. We would like to thank our parents and family for their financial and motivational support, although distance between us was more than 1500 kilometres. Last but not least we would like to thank our fellow researchers and friends on our department for useful discussions, comments, suggestions, thoughts and also creative and fun moments we spend together. i Abstract Wireless communications is a constantly progressing technology in network engineering society, creating an environment full of opportunities that are targeting in financial growth, quality of life and humans prosperity. Wireless security is the science that has as a goal to provide safe data communication between authorized users and prevent unauthorized users from gaining access, deny access, damage or counterfeit data in a wireless environment.
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1, Richard Andrews2 ntop.org, Pisa, Italy1 Symstream Technologies, Melbourne, Australia2 {deri, andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer-to- peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1. Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • AWS Site-To-Site VPN User Guide AWS Site-To-Site VPN User Guide
    AWS Site-to-Site VPN User Guide AWS Site-to-Site VPN User Guide AWS Site-to-Site VPN: User Guide Copyright © Amazon Web Services, Inc. and/or its affiliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon. AWS Site-to-Site VPN User Guide Table of Contents What is Site-to-Site VPN ..................................................................................................................... 1 Concepts ................................................................................................................................... 1 Working with Site-to-Site VPN ..................................................................................................... 1 Site-to-Site VPN limitations ......................................................................................................... 2 Pricing ...................................................................................................................................... 2 How AWS Site-to-Site VPN works ........................................................................................................ 3 Site-to-Site VPN Components .....................................................................................................
    [Show full text]
  • Building Ipv6 Based Tunneling Mechanisms for Voip Security
    WK,QWHUQDWLRQDO0XOWL&RQIHUHQFHRQ6\VWHPV6LJQDOV 'HYLFHV Building IPv6 Based Tunneling Mechanisms for VoIP Security Amzari J. Ghazali, Waleed Al-Nuaimy, Ali Al-Ataby, Majid A. Al-Taee Department of Electrical Engineering and Electronics University of Liverpool, UK e-mail: {amzari.ghazali, wax, ali.ataby, altaeem}@liv.ac.uk Abstract—Internet protocol version 6 (IPv6) was such as Toredo, 6to4 and manual configuration [4]. developed to resolve the IPv4 address exhaustion Despite the benefits of using IPv6, there are still problem and support new features. However, IPv6 still challenges and obstacles in implementing and comprises some defectiveness of IPv4 protocol such as practically using IPv6 VoIP [5]. The issues of the multimedia security. This paper presents IPv6-based transition from the current IPv4 network to IPv6 as tunneling mechanisms for securing Voice over Internet Protocol (VoIP) network traffic using OpenSwan IPSec well as VoIP performance for both IP versions need (site-to-site). IPSec with Triple Data Encryption to be assessed and compared. Algorithm (3DES) is used to create a Virtual Private Evaluation of VoIP performance with IPSec in Network (VPN) on top of existing physical networks. IPv4, IPv6 and 6to4 networks using Teredo for NAT Secure communication mechanisms can therefore be provided for data and control information transmitted traversal in a test LAN was previously reported in between networks. Secure VoIP-oriented mechanisms [6]. The testbed used softphones to setup calls, and on VPN IPv6 have been designed, implemented and background traffic was generated to create congestion tested successfully using open source approaches. The on the links and routers. The results demonstrated the performance of the IPv6 VoIP network is assessed feasibility of using a single Linux box to handle experimentally in terms of several performance metrics IPSec, 6to4 and NAT processing, and it was found including jitter, throughput and packet loss rate.
    [Show full text]
  • CIS Ubuntu Linux 18.04 LTS Benchmark
    CIS Ubuntu Linux 18.04 LTS Benchmark v1.0.0 - 08-13-2018 Terms of Use Please see the below link for our current terms of use: https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/ 1 | P a g e Table of Contents Terms of Use ........................................................................................................................................................... 1 Overview ............................................................................................................................................................... 12 Intended Audience ........................................................................................................................................ 12 Consensus Guidance ..................................................................................................................................... 13 Typographical Conventions ...................................................................................................................... 14 Scoring Information ..................................................................................................................................... 14 Profile Definitions ......................................................................................................................................... 15 Acknowledgements ...................................................................................................................................... 17 Recommendations ............................................................................................................................................
    [Show full text]
  • CS670: Network Security
    Cristina Nita-Rotaru CS670: Network security IPsec. TLS. Sources 1. Many slides courtesy of Christo Wilson and Wil Robertson 2. IPSec Key management based on slides from B. LaMacchia 3. Analysis of the HTTPS Certificate Ecosystem, IMC 2013: https://jhalderm.com/pub/papers/https-imc13.pdf 4. Analysis of SSL certificate reissues and revocations in the wake of Heartbleed, IMC 2014: http://www.ccs.neu.edu/home/cbw/pdf/imc254-zhang.pdf 2 IPSec; TLS 1: Protecting IP: IPsec OSI/ISO Model Application Application Presentation Presentation Session Session Transport Transport Network Network Data Link Data Link Physical Layer Physical Layer 4 IPSec; TLS IPsec design goals } Design philosophy: applications cannot be trusted to implement end-to-end security properly and security should be built into the network itself } Transparent to applications (below transport layer ) } Goal: Facilitate direct IP connectivity between sensitive hosts through untrusted networks } It is designed to be extremely flexible } Different crypto algorithms and key exchange supported } Different security services compositions } Different granularities of protection 5 IPSec; TLS Security goals } IPsec provides: } access control } integrity } data origin authentication } rejection of replayed packets } confidentiality } IETF IPSEC Working Group } Documented in RFCs and Internet drafts 6 IPSec; TLS Security and deployment mechanisms } Operates based on security associations } Deployment: } Transport-mode: encapsulates an upper-layer protocol (e.g. TCP or UDP) and preapends an
    [Show full text]
  • Internet Telephony PBX System IPX-2200/IPX-2500
    Internet Telephony PBX System IPX-2200/IPX-2500 Internet Telephony PBX System IPX-2200 IPX-2500 1 Internet Telephony PBX System IPX-2200/IPX-2500 Copyright Copyright (C) 2016 PLANET Technology Corp. All rights reserved. The products and programs described in this User’s Manual are licensed products of PLANET Technology. This User’s Manual contains proprietary information protected by copyright, and this User’s Manual and all accompanying hardware, software, and documentation are copyrighted. No part of this User’s Manual may be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form by any means by electronic or mechanical including photocopying, recording, or information storage and retrieval systems, for any purpose other than the purchaser's personal use, and without the prior written permission of PLANET Technology. Disclaimer PLANET Technology does not warrant that the hardware will work properly in all environments and applications, and makes no warranty and representation, either implied or expressed, with respect to the quality, performance, merchantability, or fitness for a particular purpose. PLANET has made every effort to ensure that this User’s Manual is accurate; PLANET disclaims liability for any inaccuracies or omissions that may have occurred. Information in this User’s Manual is subject to change without notice and does not represent a commitment on the part of PLANET. PLANET assumes no responsibility for any inaccuracies that may be contained in this User’s Manual. PLANET makes no commitment to update or keep current the information in this User’s Manual, and reserves the right to make improvements to this User’s Manual and/or to the products described in this User’s Manual, at any time without notice.
    [Show full text]
  • FIPS 140-2 Security Policy
    Red Hat Enterprise Linux 6.2 Openswan Cryptographic Module v2.0 FIPS 140-2 Security Policy version 1.1 Last Update: 2012-11-13 Red Hat Enterprise Linux 6.2 Openswan Cryptographic Module version 2.0 FIPS 140-2 Security Policy Contents 1 Cryptographic Module Specification .................................................................................................... .................. 3 1.1 Description of Module ............................................................................................................. .................. ... 3 1.2 Description of Approved Mode .......................................................................................................... ............ 4 1.3 Cryptographic Module Boundary ......................................................................................... ......................... 5 1.3.1 Hardware Block Diagram ................................................................................................................. .......... 6 1.3.2 Software Block Diagram .......................................................................................................... ................... 7 1.4 Red Hat Enterprise Linux 6.2 Cryptographic Modules and FIPS 140-2 Certification ......................... .......... 7 1.4.1 Platforms ............................................................................................................................... ............. ........ 8 1.4.2 FIPS Approved Mode .......................................................................................................................
    [Show full text]
  • Virtual Private Networks for Peer-To-Peer Infrastructures
    Technische Universit¨atDarmstadt Department of Computer Science Prof. Dr. Michael Waidner Virtual Private Networks for Peer-to-Peer Infrastructures Diploma Thesis Submitted by Hiro Dudani <[email protected]> on 2012-11-30 Supervisor: Dipl.-Inform. Nicolai Kuntze In cooperation with: Fraunhofer SIT f¨urPapa ii Ehrenw¨ortlicheErkl¨arung(Affidavit) Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ¨ahnlicher Form noch keiner Pr¨ufungsbeh¨ordevorgelegen. Hiro Dudani Neu-Isenburg, am 29.11.2012 iii Abstract The Nanodatacenters project aims to complement the paradigm of existing centralized server farms with a high number of small storage and communication devices located at the edges of the network. Utilizing previously unused resources like broadband internet access bandwith and idling set-top boxes, these nodes are able to host applications from different content providers offering various kinds of services, such as Video on Demand or online gaming, to end users. This setting does pose particular security challenges. As the devices operate under physical control of the end users, their integrity has be ensured and must be able to be verified by the network. This is achieved through the functionality of Trusted Com- puting. Additionally, the domains of the different content providers have to be isolated in such a way that an attacker cannot use one of them as a foothold to compromise or snoop on the operation of the network or another isolated domain.
    [Show full text]
  • Bohrende Fragen Wireguard
    01/2018 VPN mit Wireguard aufsetzen Titelthema Bohrende Fragen Wireguard 38 Wer ein Virtual Private Network einrichten möchte, kämpft oftmals mit einer nicht ganz simplen Konfiguration. Wireguard verspricht, dass der Tunnelbau auch einfacher und flinker gelingen kann. Falko Benthin www.linux-magazin.de Quelltext und setzt auf starke Verschlüs- selungsalgorithmen, wofür Donenfeld Trevor Perrins Noise Protocol Framework [9] ins Boot nimmt. Für Zertifikate setzt das Wireguard-Protokoll auf Ed25519, für den Schlüsselaustausch auf Curve25519 (ECDHE) und für den Datentransport auf Chacha20-poly1305. Wireguard unterstützt allerdings nur eine kryptografische Suite, die sich je- doch bei Problemen ohne Weiteres aus- tauschen lässt. Anwender müssen ihre Verschlüsselungs-Suite also nicht mehr aus verschiedenen Chiffren selbst zusam- menbasteln. Das reduziert die Komple- xität und vermindert das Risiko von Si- cherheitslücken. Wireguard arbeitet aus © Péter Gudella, 123RF © Péter Sicht des Administrators zustandslos und bringt einen integrierten Schutz gegen VPNs (Virtual Private Networks) gelten In freien Wildbahn treffen Admins Wire- Denial-of-Service-Attacken mit. als sichere Nummer, wenn es darum guard bislang noch eher selten an. Das geht, das Home Office mit dem Firmen- dürfte vor allem daran liegen, dass das Installation und netz, Firmensitze mit der Zentrale oder Projekt noch nicht im offiziellen Linux- Inbetriebnahme Geschäftsreisende mit ihrer Kundenda- Kernel steckt und aktuell nur für Linux tenbank zu verbinden. Privatnutzer ver- und OS X verfügbar ist. Daneben feh- Die Repositories zahlreicher Distributio- wenden VPNs, um beispielsweise sicher len Sicherheits-Audits und das Protokoll nen bieten Wireguard bereits an, sodass über das Internet auf die heimische Wet- kann sich noch ändern. Experimentierfreudige es leicht mit Hilfe terstation mit angeschlossenem Daten- Trotzdem haben es manche VPN-Provi- der entsprechenden Paketverwaltung in- bankserver zuzugreifen.
    [Show full text]
  • Evolution of the Transport Layer Security As Internet Security Protocol: Impact, Improvements and Extent
    Norberto Novoa Torres, et. al. International Journal of Engineering Research and Applications www.ijera.com ISSN: 2248-9622, Vol. 10, Issue 11, (Series-II) November 2020, pp. 27-34 RESEARCH ARTICLE OPEN ACCESS Evolution Of The Transport Layer Security As Internet Security Protocol: Impact, Improvements And Extent. Johana Alejandra Mendoza Aguilera*, Norberto Novoa Torres** *(Engineering Department, Universidad Distrital Francisco José de Caldas, Facultad Tecnologica, Bogotá D.C. – Colombia. ** (Engineering Department, Universidad Distrital Francisco José de Caldas, Facultad Tecnologica, Bogotá D.C. – Colombia. ABSTRACT Although, it presents the use of SSL and TLS as protection mechanisms of communication trough encryption in data transportation making it been the most used crucial service, like messaging, financial transactions, etc., At the same time, it becomes in an attack target through its different versions which they have managed to be successful because of different methods. Making the protocol to evolve rapidly in its implementation modes and present improvements by means of hybrid solutions with the aim to solve those found security breaches or to give power to other services. In this document it is presented an analysis of these affirmations, managing to determine how safe the protocol is at the moment and how it prepares to the future. Keywords – Comunication, Safe protocols, Security, SSL, TLS. --------------------------------------------------------------------------------------------------------------------------------------- Date of Submission: 06-11-2020 Date of Acceptance: 19-11-2020 --------------------------------------------------------------------------------------------------------------------------------------- has been done until now. Or, if it is planned to I. INTRODUCTION include improvements that keep it situating as one of Nowadays, technology presents high the best solutions talking about information and safe advantages ahead of the challenges of security communications it refers.
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1 and Richard Andrews2 1 ntop.org, Pisa, Italy 2 Symstream Technologies, Melbourne, Australia {deri,andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer- to-peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1 Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]