• Tag : security

 
 

VXLAN: security recommendations

Posted on January 16, 2017 by

Abstract This document provides recommendations that are advised to implement in order to increase the security in multitenant network environments built on Arista Networks devices using VXLAN. Introduction One of the crucial qualities of modern cloud network infrastructure is scalability. Scalability can’t be achieved if security of the network operations inside the cloud is compromised. As for example, load scalability is not achievable in environments where the VMs are not able to operate when the network between them is not working properly due to hijacked MAC-addresses. One of the technologies used nowadays to address the challenges with scalability inside the cloud networks...
Continue reading →

How are people generally separating internal and DMZ networks?

Posted on March 30, 2016 by

Hi forum, Considering the design elements of a L3LS, the separation of functions into dedicated leaves (such as Services, Compute, Storage, Border), and given Cisco’s VDC and it’s logical separation (or rather, the broadly accepted/ marketed view that secure and less secure networks can be collapsed onto the same physical device) are people doing the same with L3LS deployments with VLANs and VXLAN?  Or are they interconnecting two L3LS ‘instances’ with border leaves with a secure gateway? Cloud datacentres seem to make no distinction between what a customer defines as secure and not secure and generally they seem to suggest...
Continue reading →

Securing eAPI

Posted on March 30, 2015 by

Introduction In this article we will talk about a few tips to secure our eAPI access, for example, HTTPS, changing port, certificate, ACL, on-box, AAA, vrf etc. Turning on/off eAPI First of all, the most secure way is turning off eAPI, which is by default. myswitch#configure myswitch(config)#management api http-commands myswitch(config-mgmt-api-http-cmds)#shutdown To turn eAPI on by “no shutdown”, by default the HTTPS protocol is running and HTTP is turned off for secure purpose, because HTTP send user and password in clear text. HTTP can be used by “protocol http”, however, we recommend using HTTPS. Both HTTP and HTTPS can be used concurrently. myswitch#configure terminal myswitch(config)#management api http-commands...
Continue reading →

Securing EOS CLI

Posted on March 25, 2014 by

Objective This Tech Tip is intended to provide Arista EOS users with the configuration guidelines and best practices to enable secure management plane protocols according to IT industry security standards. It is not the objective of this document to set the foundations or rules of a company security policy or a password policy. Note: This document is not intended to set company security or password policy. Ultimate responsible to define and apply an end-to-end IT security policy is the responsibility of the end user and must take into account any regulations directly related with company activities. Arista EOS includes a wide...
Continue reading →

Restricting access to the switch

Posted on January 24, 2014 by

In this article we demonstrate how you can enable your Arista switch to restrict access to various network services. By default, Arista EOS implements a control-plane ACL to restrict the packets going to the CPU.  This is done for security purposes, but in its default configuration is very permissive.  As such, it is recommended that the sources which can access the switch be restricted using the methods described below. To view the default ACL issue the following command: Arista#sh ip access-lists default-control-plane-acl IP Access List default-control-plane-acl [readonly] statistics per-entry 10 permit icmp any any [match 4, 11 days, 20:46:23 ago]...
Continue reading →

Automatic MD5 Verification of EOS image

Posted on January 23, 2014 by

Introduction This article describes how EOS can be extended in order to check the integrity of software images. The extension described below adds the ability to automatically download the MD5 sum of an EOS image and check its integrity.  This is done by adding an optional verify parameter to the existing copy command. When verify is specified, the switch will first attempt to copy the requested EOS image (e.g. EOS-4.12.5.swi), and then it will try to retrieve an MD5 sum for the same resource (e.g. EOS-4.12.5.swi.md5sum). Assuming both files are successfully downloaded, the MD5 sum of the software image will be...
Continue reading →