1 Using Access-groups to Block/Allow Traffic in AOS When setting up an AOS unit, it is important to control which traffic is allowed in and out. In many cases, the built-in AOS firewall is the most efficient way to properly block and allow traffic through the AOS unit, especially when NAT functionality is required. The firewall is made to protect a unit with a public Internet connection from the outside world. You can read more about the AOS firewall and how to set it up at https://supportforums.adtran.com/docs/doc Internetworking equipment that resides on private networks is not always safe from security concerns, despite the lack of a public connection. There may be resources that should only be available to certain personnel, or networks that should not be able to communicate with other networks in the infrastructure. The AOS firewall includes many options and utilities that aren t needed in a private network security plan. In this case, access-groups can be the best option to properly control traffic, save resources on the AOS unit, and keep the configuration of the router simplistic. Access-groups offer advantages over the AOS firewall. The most notable advantage is that access-groups process traffic before the packet is sent to be processed by other functions in the AOS unit, like SSH, HTTP, or the route-table. So when trying to simply block or allow certain types of traffic, access-groups can be a more efficient than the firewall because resources aren t allocated for the packet until it is accepted in the access-group. Furthermore, the AOS firewall blocks traffic, by default, that it considers to be a threat like traffic it detects as spoofed (spoofed traffic are packets that comes in an interface from a source that, according to the route table, would not be located out of that interface). On a public network, it is vital to block spoofed traffic, but on a private network there are many situations where traffic the firewall perceives as spoofed would actually be legitimate (like A-symmetrical routing). Accessgroups provide the ability to make small traffic-controlling rules without blocking unwanted traffic. Before creating an access-group, it is important to understand where you want to block/allow traffic in regards to each interface. An access-group can be applied to any interface in either the outbound or inbound direction. It is important to perform this action as close to the source of the traffic as possible, so that the traffic takes up the least amount of processing for the AOS unit. There are several examples below.
2 Example 1: Blocking SSH Traffic Inbound In this example, a network administrator wants to add a rule to block SSH attempts into the AOS device on the Ethernet 0/1 interface. All other traffic is permitted. The Ethernet 0/1 interface configuration is below: ip address First, an access-control list (ACL) needs to be created to take the proper actions on traffic. Since it is known that all SSH traffic to the AOS device needs to be blocked, an ACL rule can be made to deny that traffic: ip access-list extended BLOCK-SSH deny tcp any host eq ssh Access-groups strictly use the ACL s permit and deny functions, where as the AOS firewall uses the ACL s permit and deny as a match and do not match. In this case, if you do not have any permit statements in an ACL referenced as an access-group, no traffic will be permitted. In this case, the network administrator only wants to block SSH into , so a permit ip any any can be added at the bottom, so that all other traffic is allowed (instead of the traffic being denied by default using the implicit deny t the bottom of all ACLs). The final ACL is below: ip access-list extended BLOCK-SSH deny tcp any host eq ssh permit ip any any To make it an access group, it will need to be applied to the interface in the inbound direction, because it is blocking inbound SSH connections: ip access-group BLOCK-SSH in
3 Example 2: Blocking/Allowing Traffic with Multiple Network Subnets A company has the following network: The network administrator is trying to secure the servers and interfaces on the network, but would like to do so without enabling the firewall on the AOS unit. The network requirements are below: Customer/Guest LAN 1. Permit access to the Web server and the DHCP server on the Employee LAN. 2. Deny access to the remaining Employee LAN and the AOS unit. 3. Deny access to the MPLS network. Employee LAN 1. Permit access to the MPLS network. 2. Permit access to the AOS device via SSH. 3. Deny access to the Customer Network unless the source of the traffic is the DHCP server or Web server. MPLS Network 1. Permit access to the Employee LAN. 2. Deny access to the Customer LAN.
4 3. Permit access to the AOS device via SSH only, if the source IP address is Below are the current configurations of the AOS unit s three interfaces: ip address ! interface eth 0/2 ip address ! interface t1 1/1 tdm-group 1 timeslots 1-24 speed 64! interface ppp 1 ip address cross-connect 1 t1 1/1 1 ppp 1 To start, build an ACL for each set of criteria and then apply it to the corresponding interface: Customer/Guest LAN 1. Permit access to the Web server and the DHCP server on the Employee LAN. permit ip any host permit ip any host Deny access to the remaining Employee LAN and the router itself. Implicit deny at the bottom of the ACL 3. Deny access to the MPLS network. Implicit deny at the bottom of the ACL ip access-list extended CUSTOMER-LAN permit ip any host permit ip any host
5 When traffic reaches the ACL, it will only be allowed to pass if it is destined for either the IP address of or If not, it will be matched by the implicit deny at the bottom of the ACL, and the traffic will be blocked. To make this ACL an Access-group, it will be applied to the Ethernet 0/2 interface in the inbound direction, which is closest to the source of the traffic being blocked (the customer traffic): interface eth 0/2 ip access-group CUSTOMER-LAN in Employee LAN 1. Permit access to the MPLS network. permit ip any Permit access to the router via SSH. permit tcp any host eq ssh 3. Deny access to the Customer Network unless the source IP address is the DHCP server or Web server. This rule can be accomplished in several ways. Since there is an implicit deny at the bottom of the ACL, the simplest way is to allow traffic sourced from the two servers, and let the implicit deny block everything else permit ip host permit ip host ip access-list extended EMPLOYEE-LAN permit ip any permit tcp any host eq ssh permit ip host permit ip host Now the ACL will be applied to the Ethernet 0/1 interface, in the inbound direction, since it is closest to the source of the traffic being affected (employee LAN traffic): ip access-group EMPLOYEE-LAN in MPLS Network
6 1. Permit access to the Employee LAN. permit ip any Deny access to the Customer LAN. Implicit deny at the bottom of the ACL 3. Permit access to the AOS device via SSH, only if the source is Here it will again be more efficient to allow through the SSH traffic and let the implicit deny block everything else. permit tcp host any eq ssh This makes the final ACL as shown below: ip access-list extended MPLS-NETWORK permit ip any permit tcp host any eq ssh Now the ACL will be applied to the PPP 1 interface, in the inbound direction, since it is closest to the source of the traffic being affected (MPLS traffic): interface ppp 1 ip access-group MPLS-NETWORK Example 3: Using an Outbound Access-group In this example, a network administrator would like to block SSH access to a server that is connected to the core AOS device s Ethernet 0/1 interface, regardless of the traffic s source IP address. Ethernet 0/1 s configuration is below: ip address The server s IP address is The core AOS device has 25 VLAN interfaces on it, any of which could generate SSH traffic, which would exit the device on the Ethernet 0/1 interface destined to that server. In this case, the configuration will be more efficient for the network administrator to block the traffic outbound on the eth 0/1 interface, instead of blocking it inbound on all of the different interfaces that could try and access the server. If the accessgroup was located on all 25 vlans, it would also require the AOS device to check all traffic that
7 comes in on those interfaces, no matter the destination, to make sure it is not SSH traffic destined for that server. The network administrator should create the following ACL: ip access-list extended BLOCK-SERVER-SSH deny tcp any host eq ssh permit ip any any The permit ip any any at the bottom is so that the implicit deny of the ACL will not catch all other traffic. Now that the ACL has been made, the network administrator should apply the ACL as an Access-group to the Ethernet 0/1 interface in the outbound direction: ip access-group BLOCK-SERVER-SSH out Troubleshooting Access-groups When verifying traffic is being blocked or allowed properly by Access-groups, the easiest way to confirm this is to check to see if there are matches for the ACL that the Access-group references. For example, consider the following configuration: ip address ip access-group BLOCK-PING in! ip access-list extended BLOCK-PING deny icmp any any permit ip any any In this case, running the command show ip access-list will allow the user to see which rules have been matched, and how many times they have been matched, to indicate whether the Access-group is working: Extended IP access list BLOCK-PING deny icmp any any (66 matches) permit ip any any (185 matches)
8 Issuing the command several times in succession will allow the user to check whether the matches are increasing, as the matched traffic is hitting the router. The ACL matches can be cleared by issuing the clear ip access-list command.
CHAPTER 2 Point-to-Point GRE over IPsec Design and Implementation In designing a VPN deployment for a customer, it is essential to integrate broader design considerations such as high availability, resiliency,
Configuration Example Use NAT for Public Access to Servers with Private IP Addresses on the Private Network Example configuration files created with WSM v11.7.2 Revised 5/10/2013 Use Case In this use case,
CHAPTER 15 This chapter describes the security appliance failover feature, which lets you configure two security appliances so that one takes over operation if the other one fails. This chapter includes
C H A P T E R 4 Interconnecting Multiple OSPF Areas This chapter introduces readers to the use, operation, configuration, and verification of Open Shortest Path First (OSPF) in multiple areas. After completing
Special Publication 800-41 Revision 1 Guidelines on Firewalls and Firewall Policy Recommendations of the National Institute of Standards and Technology Karen Scarfone Paul Hoffman NIST Special Publication
Connecting Remote Offices by Setting Up VPN Tunnels Cisco RV0xx Series Routers Overview As your business expands to additional sites, you need to ensure that all employees have access to the network resources
FileMaker Server 13 FileMaker Server Help 2010-2013 FileMaker, Inc. All Rights Reserved. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker and Bento are trademarks of FileMaker,
This design guide provides guidelines and best practices for customer deployments of IP Security (IPsec) direct encapsulation VPNs. It is assumed that the reader has a basic understanding of IPsec. Contents
PREPARING AN IP6 ADDRESS PLAN MANUAL PREPARING AN IP6 ADDRESS PLAN MANUAL ersion 2, 18 September 2013 CONTENTS 1. Introduction... 3 1.1. For Whom is this Document Intended?... 3 2. Structure of IPv6 Addresses...
CHAPTER114 The window in Cisco Unified Communications Manager Administration allows the administrator to add, search, display, and maintain information about Cisco Unified Communications Manager end users.
WHITE PAPER Mobility Services Platform (MSP) Using MSP in Wide Area Networks (Carriers) Table of Contents About This Document... 1 Chapter 1 Wireless Data Technologies... 2 Wireless Data Technology Overview...
white paper Public or Private Cloud: The Choice is Yours Current Cloudy Situation Facing Businesses There is no debate that most businesses are adopting cloud services at a rapid pace. In fact, a recent
TeamViewer 7 Manual Remote Control TeamViewer GmbH Kuhnbergstraße 16 D-73037 Göppingen www.teamviewer.com Table of Contents 1 About TeamViewer... 5 1.1 About the software... 5 1.2 About the manual... 5
CHAPTER 6 Setting up Support for CiscoWorks ANI Server The CiscoWorks Server includes tools required to properly set up the server to support other CiscoWorks applications. These features include: Configuring
10 Things Your Next Firewall Must Do Introduction Without question, your network is more complex than ever before. Your employees are accessing any application they want, using work or personal devices.
ADMINISTRATION GUIDE Cisco Small Business WAP4410N Wireless-N Access Point with Power Over Ethernet Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the
61200796E1-29.1B August 2010 Configuration Guide in AOS This configuration guide describes automatic number identification (ANI) substitution and dialed number identification service (DNIS) substitution
SYMANTEC ADVANCED THREAT RESEARCH The Teredo Protocol: Tunneling Past Network Security and Other Security Implications Dr. James Hoagland Principal Security Researcher Symantec Advanced Threat Research
Data ONTAP 8.1 Network Management Guide For 7-Mode NetApp, Inc. 495 East Java Drive Sunnyvale, CA 94089 U.S. Telephone: +1 (408) 822-6000 Fax: +1 (408) 822-4501 Support telephone: +1 (888) 463-8277 Web:
Data protection Protecting personal data in online services: learning from the mistakes of others May 2014 Contents Introduction... 2 What the DPA says... 4 Software security updates... 5 Software security
The Critical Security Controls for Effective Cyber Defense Version 5.0 1 Introduction... 3 CSC 1: Inventory of Authorized and Unauthorized Devices... 8 CSC 2: Inventory of Authorized and Unauthorized Software...
GE Measurement & Control Remote Comms System Installation and User Reference Guide Contents BENEFITS OF REMOTE COMMS SYSTEM... 1 HOW THE REMOTE COMMS SYSTEM WORKS... 3 COMPONENTS OF REMOTE COMMS SYSTEM...
Record-Level Access: Under the Hood Salesforce, Summer 15 @salesforcedocs Last updated: May 20, 2015 Copyright 2000 2015 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of
TD-W8951NB 150Mbps Wireless N ADSL2+ Modem Router (Annex B) Rev: 3.0.0 1910010747 COPYRIGHT & TRADEMARKS Specifications are subject to change without notice. is a registered trademark of TP-LINK TECHNOLOGIES
Pearson Inform v4.0 Educators Guide Part Number 606 000 508 A Educators Guide v4.0 Pearson Inform First Edition (August 2005) Second Edition (September 2006) This edition applies to Release 4.0 of Inform
Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors Program Guide Version 2.0 May 2013 Document Changes Date Version Description February 11, 2010 1.0 May 2013 2.0 Approved Scanning