Network Address Translation

Total Page:16

File Type:pdf, Size:1020Kb

Network Address Translation Network address translation “NAT” redirects here. For other uses, see Nat. As network address translation modifies the IP address in- formation in packets, it has serious consequences on the quality of Internet connectivity and requires careful at- In computer networking, network address translation (NAT) provides a method[1] of modifying network ad- tention to the details of its implementation. NAT imple- mentations vary widely in their specific behavior in vari- dress information in Internet Protocol (IP) datagram packet headers while they are in transit across a traf- ous addressing cases and in their effect on network traffic. Vendors of equipment containing implementations do not fic routing device for the purpose of remapping one [2] IP address space into another. The term NAT44 is commonly document the specifics of NAT behavior. sometimes used to more specifically indicate mapping between two IPv4 addresses; this is the typical case while IPv4 carries the majority of traffic on the Inter- 1 Basic NAT net. NAT64 refers to the mapping of an IPv4 address to an IPv6 address, or vice versa. The simplest type of NAT provides a one-to-one transla- Network administrators originally used network address tion of IP addresses. RFC 2663 refers to this type of NAT translation to map every address of one address space to a as basic NAT; it is often also called a one-to-one NAT. corresponding address in another space, such as when an In this type of NAT, only the IP addresses, IP header organization changed Internet service providers without checksum and any higher level checksums that include having a facility to announce a public route to the net- the IP address are changed. Basic NATs can be used to work. As of 2014 NAT operates most commonly in con- interconnect two IP networks that have incompatible ad- junction with IP masquerading, which is a technique dressing. that hides an entire IP address space - usually consisting of private network IP addresses (RFC 1918) - behind a single IP address in another, usually public address space. Vendors implement this mechanism in a routing device 2 One-to-many NAT that uses stateful translation tables to map the “hidden” addresses into a single IP address and that readdresses the The majority of NATs map multiple private hosts to one outgoing Internet Protocol packets on exit so they appear publicly exposed IP address. In a typical configuration, to originate from the routing device. In the reverse com- a local network uses one of the designated “private” IP munications path, the router maps responses back to the address subnets (RFC 1918). A router on that network originating IP addresses using the rules (“state”) stored has a private address in that address space. The router is in the translation tables. The translation table rules es- also connected to the Internet with a “public” address as- tablished in this fashion are flushed after a short period signed by an Internet service provider. As traffic passes unless new traffic refreshes their state. from the local network to the Internet, the source address in each packet is translated on the fly from a private ad- The method enables communication through the router dress to the public address. The router tracks basic data only when the conversation originates in the masqueraded about each active connection (particularly the destination network, since this establishes the translation tables. For address and port). When a reply returns to the router, example, a web browser in the masqueraded network can it uses the connection tracking data it stored during the browse a website outside, but a web browser outside can outbound phase to determine the private address on the not browse a web site hosted within the masqueraded net- internal network to which to forward the reply. work. However, most NAT devices today allow the net- work administrator to configure translation table entries All datagram packets on IP networks have a source IP for permanent use. This feature is often referred to as address and a destination IP address. Typically packets “static NAT” or port forwarding - it allows traffic origi- passing from the private network to the public network nating in the “outside” network to reach designated hosts will have their source address modified while packets in the masqueraded network. passing from the public network back to the private net- work will have their destination address modified. More Because of the popularity of this technique to conserve complex configurations are also possible. IPv4 address space, the term NAT has become virtually synonymous with the method of IP masquerading. To avoid ambiguity in how to translate returned packets, further modifications to the packets are required. The 1 2 3 IMPLEMENTATION vast bulk of Internet traffic is TCP and UDP packets, and ual NAT behaviors instead of using the Cone/Symmetric for these protocols the port numbers are changed so that terminology. Especially, most NAT translators combine the combination of IP address and port information on symmetric NAT for outgoing connections with static port the returned packet can be unambiguously mapped to the mapping, where incoming packets to the external address corresponding private address and port information. RFC and port are redirected to a specific internal address and 2663 uses the term network address and port translation port. Some products can redirect packets to several inter- (NAPT) for this type of NAT. Other names include port nal hosts, e.g. to divide the load between a few servers. address translation (PAT), IP masquerading, NAT over- However, this introduces problems with more sophis- load and many-to-one NAT. This is the most common ticated communications that have many interconnected type of NAT, and has become synonymous with the term packets, and thus is rarely used. NAT in common usage. This method enables communi- cation through the router only when the conversation orig- inates in the masqueraded network, since this establishes 2.2 Type of NAT and NAT traversal, role the translation tables. For example, a web browser in the of port preservation for TCP masqueraded network can browse a website outside, but a web browser outside could not browse a web site hosted The NAT traversal problem arises when two peers be- within the masqueraded network. However, most NAT hind distinct NAT try to communicate. One way to solve devices today allow the network administrator to config- this problem is to use port forwarding, another way is to ure translation table entries for permanent use. This fea- use various NAT traversal techniques. The most popular ture is often referred to as “static NAT” or port forward- technique for TCP NAT traversal is TCP hole punching, ing and allows traffic originating in the “outside” network which requires the NAT to follow the port preservation to reach designated hosts in the masqueraded network. design for TCP, as explained below. Protocols not based on TCP or UDP require other trans- Many NAT implementations follow the port preservation lation techniques. ICMP packets typically relate to an ex- design for TCP: for a given outgoing tcp communica- isting connection and need to be mapped using the same tion, they use the same values as internal and external IP address and port mappings as that connection. port numbers. NAT port preservation for outgoing TCP connections is crucial for TCP NAT traversal, because as TCP requires that one port can only be used for one com- 2.1 Methods of port translation munication at a time, programs bind distinct TCP sockets to ephemeral ports for each TCP communication, render- There are several ways of implementing network address ing NAT port prediction impossible for TCP.[2] and port translation. In some application protocols that use IP address information, the application running on a On the other hand, for UDP, NATs do not need to have node in the masqueraded network needs to determine the port preservation. Indeed multiple UDP communications external address of the NAT, i.e., the address that its com- (each with a distinct endpoint) can occur on the same munication peers detect, and, furthermore, often needs to source port, and applications usually reuse the same UDP examine and categorize the type of mapping in use. Usu- socket to send packets to distinct hosts. This makes port ally this is done because it is desired to set up a direct prediction straightforward, as it is the same source port communications path (either to save the cost of taking for each packet. the data via a server or to improve performance) between Furthermore, port preservation in NAT for TCP allows two clients both of which are behind separate NATs. P2P protocols to offer less complexity and less latency For this purpose, the Simple traversal of UDP over NATs because there is no need to use a third party (like STUN) (STUN) protocol was developed (RFC 3489, March to discover the NAT port since the application itself al- [2][3] 2003). It classified NAT implementation as full-cone ready knows the NAT port. NAT, (address) restricted-cone NAT, port-restricted cone However, if two internal hosts attempt to communicate NAT or symmetric NAT and proposed a methodology with the same external host using the same port number, for testing a device accordingly. However, these pro- the external port number used by the second host is cho- cedures have since been deprecated from standards sta- sen at random. Such NAT is sometimes perceived as (ad- tus, as the methods have proven faulty and inadequate to dress) restricted cone NAT and other times as symmetric correctly assess many devices. New methods have been NAT. standardized in RFC 5389 (October 2008) and the STUN Recent studies have shown that roughly 70% of clients in acronym now represents the new title of the specification: P2P networks employ some form of NAT.[4] Session Traversal Utilities for NAT.
Recommended publications
  • Active-Active Firewall Cluster Support in Openbsd
    Active-Active Firewall Cluster Support in OpenBSD David Gwynne School of Information Technology and Electrical Engineering, University of Queensland Submitted for the degree of Bachelor of Information Technology COMP4000 Special Topics Industry Project February 2009 to leese, who puts up with this stuff ii Acknowledgements I would like to thank Peter Sutton for allowing me the opportunity to do this work as part of my studies at the University of Queensland. A huge thanks must go to Ryan McBride for answering all my questions about pf and pfsync in general, and for the many hours working with me on this problem and helping me test and debug the code. Thanks also go to Theo de Raadt, Claudio Jeker, Henning Brauer, and everyone else at the OpenBSD network hackathons who helped me through this. iii Abstract The OpenBSD UNIX-like operating system has developed several technologies that make it useful in the role of an IP router and packet filtering firewall. These technologies include support for several standard routing protocols such as BGP and OSPF, a high performance stateful IP packet filter called pf, shared IP address and fail-over support with CARP (Common Address Redundancy Protocol), and a protocol called pfsync for synchronisation of the firewalls state with firewalls over a network link. These technologies together allow the deployment of two or more computers to provide redundant and highly available routers on a network. However, when performing stateful filtering of the TCP protocol with pf, the routers must be configured in an active-passive configuration due to the current semantics of pfsync.
    [Show full text]
  • Pf3e Index.Pdf
    INDEX Note: Pages numbers followed by f, n, priority-based queues, 136–145 or t indicate figures, notes, and tables, match rule for queue assignment, respectively. 137–138 overview, 134–135 Symbols performance improvement, 136–137 # (hash mark), 13, 15 queuing for servers in DMZ, ! (logical NOT) operator, 42 142–144 setting up, 135–136 A on FreeBSD, 135–136 on NetBSD, 136 Acar, Can Erkin, 173 on OpenBSD, 135 ACK (acknowledgment) packets transitioning to priority and class-based bandwidth allocation, queuing system, 131–133 139–140 anchors, 35–36 HFSC algorithm, 124, 126, 142 authpf program, 61, 63 priority queues, 132, 137–138 listing current contents of, 92 two-priority configuration, loading rules into, 92 120–121, 120n1 manipulating contents, 92 adaptive.end value, 188 relayd daemon, 74 adaptive firewalls, 97–99 restructuring rule set with, 91–94 adaptive.start value, 188 tagging to help policy routing, 93 advbase parameter, 153–154 ancontrol command, 46n1 advskew parameter, 153–154, 158–159 antispoof tool, 27, 193–195, 194f aggressive value, 192 ARP balancing, 151, 157–158 ALTQ (alternate queuing) framework, atomic rule set load, 21 9, 133–145, 133n2 authpf program, 59–63, 60 basic concepts, 134 basic authenticating gateways, class-based bandwidth allocation, 60–62 139–140 public networks, 62–63 overview, 135 queue definition, 139–140 tying queues into rule set, 140 B handling unwanted traffic, 144–145 bandwidth operating system-based queue actual available, 142–143 assignments, 145 class-based allocation of, 139–140 overloading to
    [Show full text]
  • Freebsd and Netbsd on Small X86 Based Systems
    FreeBSD and NetBSD on Small x86 Based Systems Dr. Adrian Steinmann <[email protected]> Asia BSD Conference in Tokyo, Japan March 17th, 2011 1 Introduction Who am I? • Ph.D. in Mathematical Physics (long time ago) • Webgroup Consulting AG (now) • IT Consulting Open Source, Security, Perl • FreeBSD since version 1.0 (1993) • NetBSD since version 3.0 (2005) • Traveling, Sculpting, Go AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 2 Focus on Installing and Running FreeBSD and NetBSD on Compact Flash Systems (1) Overview of suitable SW for small x86 based systems with compact flash (CF) (2) Live CD / USB dists to try out and bootstrap onto a CF (3) Overview of HW for small x86 systems (4) Installation strategies: what needs special attention when doing installations to CF (5) Building your own custom Install/Maintenance RAMdisk AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 3 FreeBSD for Small HW Many choices! – Too many? • PicoBSD / TinyBSD • miniBSD & m0n0wall • pfSense • FreeBSD livefs, memstick • NanoBSD • STYX. Others: druidbsd, Beastiebox, Cauldron Project, ... AsiaBSDCon Tutorial March 17, 2011 in Tokyo, Japan “Installing and Running FreeBSD and NetBSD on Small x86 Based Systems” Dr. Adrian Steinmann <[email protected]> 4 PicoBSD & miniBSD • PicoBSD (1998): Initial import into src/release/picobsd/ by Andrzej Bialecki <[email protected]
    [Show full text]
  • IP Filter - TCP/IP Firewall/NAT Software
    IP Filter - TCP/IP Firewall/NAT Software IP Filter Current version: 5.1.0 Next release status Patches for last release What's new ? Click here! Mailing list ? Send mail to [email protected] with "subscribe ipfilter" in the body of the mail. What is it ? IPFilter is a software package that can be used to provide network address translation (NAT) or firewall services. To use, it can either be used as a loadable kernel module or incorporated into your UNIX kernel; use as a loadable kernel module where possible is highly recommended. Scripts are provided to install and patch system files, as required. To see an overview of how IP Filter fits into the overall picture of TCP/IP with your kernel and the order in which the various phases of packet processing is done, click here. The IPFilter FAQ by Phil Dibowitz! It comes as a part of the following operating systems: FreeBSD-current (post 2.2) NetBSD-current (post 1.2) xMach Solaris 10 Open Solaris http://coombs.anu.edu.au/~avalon/ip-filter.html (1 of 7)19.2.2011 •. 14:01:49 IP Filter - TCP/IP Firewall/NAT Software It has been tested and run on: Solaris/Solaris-x86 2.3 - 9 SunOS 4.1.4 - 4.1.4 NetBSD 1.0 - 1.4 FreeBSD 2.0.0 - 2.2.8 BSD/OS-1.1 - 4 IRIX 6.2, 6.5 OpenBSD 2.0 - 3.5 Linux(*) 2.4 - 2.6 HP-UX 11.00 Tru64 5.1a AIX 5.3 ML05 QNX 6 Port * - It has been tested and shown to work on RedHat 9.0, SuSE 9.1 and will, in general work with 2.4 and 2.6 kernels.
    [Show full text]
  • Traversing NAT: a Problem
    Dakota State University Beadle Scholar Masters Theses & Doctoral Dissertations Spring 3-2021 Traversing NAT: A Problem Tyler Flaagan Dakota State University Follow this and additional works at: https://scholar.dsu.edu/theses Part of the Information Security Commons, OS and Networks Commons, and the Systems Architecture Commons Recommended Citation Flaagan, Tyler, "Traversing NAT: A Problem" (2021). Masters Theses & Doctoral Dissertations. 365. https://scholar.dsu.edu/theses/365 This Dissertation is brought to you for free and open access by Beadle Scholar. It has been accepted for inclusion in Masters Theses & Doctoral Dissertations by an authorized administrator of Beadle Scholar. For more information, please contact [email protected]. Traversing NAT: A Problem A dissertation submitted to Dakota State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Cyber Operations March 2021 By Tyler Flaagan Dissertation Committee: Dr. Kyle L. Cronin Dr. Michael J. Ham Dr. Mark L. Hawkes DocuSign Envelope ID: 8BDB3DA0-604E-4AB7-9BFE-F25909CF4FC0 DISSERTATION APPROVAL FORM This dissertation is approved as a credible and independent investigation by a candidate for the Doctor of Philosophy degree and is acceptable for meeting the dissertation requirements for this degree. Acceptance of this dissertation does not imply that the conclusions reached by the candidate are necessarily the conclusions of the major department or university. Student Name: Tyler Flaagan Dissertation Title: Traversing NAT: A Problem
    [Show full text]
  • HP-UX Ipfilter Version A.03.05.13 Administrator's Guide
    HP-UX IPFilter Version A.03.05.13 Administrator’s Guide HP-UX 11i v3 January 2007 HP Networking Manufacturing Part Number : 5991-7705 E0107 United States © Copyright 2001-2007 Hewlett-Packard Development Company, L.P. Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental, or consequential damages in connection with the furnishing, performance, or use of this material. Warranty A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your local Sales and Service Office. U.S. Government License Proprietary computer software. Valid license from HP required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Copyright Notice © Copyright 2001–2007 Hewlett-Packard Development Company, L.P. All rights reserved. Reproduction, adaptation, or translation of this document without prior written permission is prohibited, except as allowed under the copyright laws. Trademark Notices UNIX® is a registered trademark of The Open Group. ii Contents Preface: About This Document 1. Installing and Configuring HP-UX IPFilter Overview of HP-UX IPFilter Installation . 3 Installation and Configuration Checklist . 3 Step 1: Checking HP-UX IPFilter Installation Prerequisites .
    [Show full text]
  • Takashi Okumura : Ph.D. Dissertation, 2006 Univ. of Pittsburgh
    VIRTUALIZATION OF NETWORK I/O ON MODERN OPERATING SYSTEMS by Takashi Okumura B.A., Keio University, Japan, 1996 M.A., Keio University, Japan, 1998 M.S., University of Pittsburgh, 2000 M.D., Asahikawa Medical College, 2007 Submitted to the Graduate Faculty of the Arts and Science in partial fulfillment of the requirements for the degree of Doctor of Philosophy University of Pittsburgh 2007 UNIVERSITY OF PITTSBURGH DEPARTMENT OF COMPUETR SCIENCE This dissertation was presented by Takashi Okumura It was defended on August 24th, 2006 and approved by Dr. Daniel Moss´e Dr. Ahmed Amer Dr. Bruce R. Childers Dr. Hideyuki Tokuda, Keio University Dissertation Director: Dr. Daniel Moss´e ii Copyright c by Takashi Okumura 2007 iii VIRTUALIZATION OF NETWORK I/O ON MODERN OPERATING SYSTEMS Takashi Okumura, Ph.D University of Pittsburgh, 2007 Network I/O of modern operating systems is incomplete. In this network age, users and their applications are still unable to control their own traffic, even on their local host. Network I/O is a shared resource of a host machine, and traditionally, to address problems with a shared resource, system research has virtualized the resource. Therefore, it is reasonable to ask if the virtualization can provide solutions to problems in network I/O of modern operating systems, in the same way as the other components of computer systems, such as memory and CPU. With the aim of establishing the virtualization of network I/O as a design principle of operating systems, this dissertation first presents a virtualization model, hierarchical virtual- ization of network interface. Systematic evaluation illustrates that the virtualization model possesses desirable properties for virtualization of network I/O, namely flexible control gran- ularity, resource protection, partitioning of resource consumption, proper access control and generality as a control model.
    [Show full text]
  • Ethical Hacking and Countermeasures Version 6
    Ethical Hacking and Countermeasures Version 6 Modu le LX Firewall Technologies News Source: http://www.internetnews.com/ Copyright © by EC-Council EC-Council All Rights Reserved. Reproduction is Strictly Prohibited Module Objective This modu le will fam iliar ize you wihith: • Firewalls • Hardware Firewalls • Software Firewalls • Mac OS X Firewall • LINUX Firewall • Windows Firewall Copyright © by EC-Council EC-Council All Rights Reserved. Reproduction is Strictly Prohibited Module Flow Firewalls Mac OS X Firewall Hardware Firewalls LINUX Firewall Software Firewalls Windows Firewall Copyright © by EC-Council EC-Council All Rights Reserved. Reproduction is Strictly Prohibited Firewalls: Introduction A firewall is a program or hardware device that protects the resources of a private netw ork from users of other networks It is responsible for the traffic to be allowed to pass, block, or refuse Firewall also works with the proxy server It helps in the protection of the private network from the users of the different network Copyright © by EC-Council EC-Council All Rights Reserved. Reproduction is Strictly Prohibited Hardware Firewalls Copyright © by EC-Council EC-Council All Rights Reserved. Reproduction is Strictly Prohibited Hardware Firewall Har dware Firewa lls are place d in the perime ter of the networ k It employs a technique of packet filtering It reads the header of a packet to find out the source and destination address The information is then compared with the set of predefined and/orand/ or user created rules that determine whether the packet is forwarded or dropped Copyright © by EC-Council EC-Council All Rights Reserved. Reproduction is Strictly Prohibited Netgear Firewall Features: • ItInterne t shar ing broa dbddband router and 4-port switch • 2x the speed and 4x times the coverage of a Wireless-G router • Configurable for private networks and public hotspots • Double Firewall protection from external hackers attacks • Touchless WiFi Security makes it easy to secure your network Copyright © by EC-Council EC-Council All Rights Reserved.
    [Show full text]
  • Cablelabs® Ipv6 Roadmap Requirements Document CM-GL
    CableLabs® IPv6 Roadmap Requirements Document CM-GL-IPv6-REQ-V01-120831 ISSUED Notice This CableLabs Requirements document is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. Neither CableLabs, nor any other entity participating in the creation of this document, is responsible for any liability of any nature whatsoever resulting from or arising out of use or reliance upon this document by any party. This document is furnished on an AS-IS basis and neither CableLabs, nor other participating entity, provides any representation or warranty, express or implied, regarding its accuracy, completeness, or fitness for a particular purpose. Distribution of this document is restricted pursuant to the terms of separate access agreements negotiated with each of the parties to whom this document has been furnished. Cable Television Laboratories, Inc., 2012 Confidential CM-GL-IPv6-REQ-V01-120831 CableLabs® CAUTION This document contains proprietary, confidential information that is the exclusive property of CableLabs®. If you do not have a valid agreement with CableLabs for the use of this document, or have not signed a non-disclosure agreement with CableLabs, then you received this document in an unauthorized manner and are not legally entitled to possess or read it.
    [Show full text]
  • Architecture for Programmable Network Infrastructure
    Architecture for programmable network infrastructure Tom Barbette Université de Liège Faculté des Sciences Appliquées Département d’Electricité, Electronique et Informatique Doctoral Dissertation presented in fulfilment of the requirements for the degree of Docteur en Sciences (Informatiques) May 2018 ii Summary Software networking promises a more flexible network infrastructure, poised to leverage the computational power available in datacenters. Virtual Net- work Functions (VNF) can now run on commodity hardware in datacenters instead of using specialized equipment disposed along the network path. VNFs applications like stateful firewalls, carrier-grade NAT or deep packet inspection that are found “in-the-middle”, and therefore often categorized as middleboxes, are now software functions that can be migrated to reduce costs, consolidate the processing or scale easily. But if not carefully implemented, VNFs won’t achieve high-speed and will barely sustain rates of even small networks and therefore fail to fulfil their promise. As of today, out-of-the-box solutions are far from efficient and cannot handle high rates, especially when combined in a single host, as multiple case studies will show in this thesis. We start by reviewing the current obstacles to high-speed software net- working. We leverage current commodity hardware to achieve what seemed impossible to do in software not long ago and made software solutions be- lieved unworthy and untrusted by network operators. Our work paves the way for building a proper software framework for a programmable network infrastructure that can be used to quickly implement network functions. We built FastClick, a faster version of the Click Modular Router, that allows fast packet processing thanks to a careful integration of fast I/O frame- works and a deep study of interactions of their features.
    [Show full text]
  • Olivier Cochard-Labbé [email protected] Agenda
    BSD Router Project Olivier Cochard-Labbé [email protected] Agenda 1. Why BSD Router Project ? 2. Targets & Philosophy 3. Features 4. Build framework 5. Lab scripts 6. Missing features 7. Problems 8. Internal usage @Orange Business Services 9. Questions ? Why BSD Router Project ? ● Network appliances are expensive and "only" 100% software solution ● Huge changes is coming with the Software Defined Networking concept (Openflow, ForCES) ● Ethernet interfaces are becoming the de-facto standard ● Current servers have lot's of power: They should have lot's more better performance in forwarding speed… and netmap is proving it! ● After FreeNAS, I would to return back to my youthful romance: Networking devices for hairy peoples (without WebGUI) Targets & Philosophy ● Medium sized Ethernet router ○ datacenter, ISP ● Not for home: Use m0n0wall or pfSense ● Only an Ethernet router ● No WebGUI ○ It's a FreeBSD ○ Massive deployment: pre-provisioning, configuration management Features ● Pre-packaged NanoBSD images ○ Quagga, Bird, mpd5, pimdd, mrouted, fprobe, etc… ● Multi-archictecture ○ amd64,i386,i386_xenpv, sparc64 (limited) ● Helper scripts: ○ cat BSDRP-1.2-upgrade.img.xz | ssh root@router "xzcat | upgrade" ○ show ifstat|mbuf|mroute|route|proc|tech-support|… ○ config diff|save|put|get|factory|… ● Small sized: 256Mb flash device ○ But removing man pages is a good idea ? Build framework Lab scripts ● Multi-OS scripts available for qemu/Virtualbox ./BSDRP-lab-vbox.sh -n 4 -l 2 -i BSDRP_1.2_full_amd64_serial.img Features testing labs Missing features
    [Show full text]
  • Sality: Story of a Peer- To-Peer Viral Network Nicolas Falliere Principal Software Engineer
    Security Response Sality: Story of a Peer- to-Peer Viral Network Nicolas Falliere Principal Software Engineer Version 1.0 (July 2011) Executive Summary W32.Sality is a file infector that spreads by infecting executable files and Contents by replicating itself across network shares. Infected hosts join a peer- Executive Summary ........................................... 1 to-peer network used to propagate malware on the compromised com- Timeline .............................................................. 1 puter. Typically, those additional programs will be used to relay spam, Architecture ....................................................... 3 proxy communications, steal private information, infect Web servers Going peer-to-peer ............................................. 7 or achieve distributed computing tasks, such as password cracking. Review of the V3 network ................................ 11 Review of the V4 network ................................ 14 The combination of file infection mechanism and the fully de- Metrics and Estimations .................................. 15 centralized peer-to-peer network, along with other anti-secu- Conclusion........................................................ 18 rity measures, make Sality one of the most effective and re- Annex A ........................................................... 19 silient malware in today’s threat landscape. Estimations show Annex B ........................................................... 20 that hundreds of thousands of machines are infected by Sality.
    [Show full text]