The following post will explain one of the recommended method of filtering unwanted traffic from the internet to the internal network.
Most administrators filter RFC-1918 traversing from the internet to internal networks, while they are allowing a list of bogons prefixes which is defined in RFC-3330. These addresses are _not_ publically assigned, therefore should not see them as source IP destined to your internal network. Furthermore, it is a best practice from a security prospective to filter these ranges in case you are targeted with a spoofing attack.
As a reference to this post, please check RFC-3330 which contains all the prefixes in question.
The following configuration example shows RFC-3330 filtering on a Cisco ASA Firewall.
object-group network RFC-3330
network-object 0.0.0.0 255.0.0.0
network-object 10.0.0.0 255.0.0.0
network-object 126.96.36.199 255.0.0.0
network-object 188.8.131.52 255.0.0.0
network-object 184.108.40.206 255.0.0.0
network-object 127.0.0.0 255.0.0.0
network-object 220.127.116.11 255.255.0.0
network-object 169.254.0.0 255.255.0.0
network-object 172.16.0.0 255.240.0.0
network-object 18.104.22.168 255.255.0.0
network-object 192.0.0.0 255.255.255.0
network-object 192.0.2.0 255.255.255.0
network-object 22.214.171.124 255.255.255.0
network-object 192.168.0.0 255.255.0.0
network-object 198.18.0.0 255.254.0.0
network-object 126.96.36.199 255.255.255.0
network-object 188.8.131.52 240.0.0.0
network-object 240.0.0.0 240.0.0.0
CREATE ACCESSLIST, where the ACL name INTERNET define OUTSIDE interface.
access-list INTERNET deny ip object-group RFC-3330 any
When it comes to Cisco ASA, both Port-Object and Service-Object achieve the same result. However, application of extended Access Control List (ACL) and calling the Port-Object or Service-Object would differ in the ACL statement.
Below, we look at two tcp protocols, namely www and https defined using Port-Object and Service-Object as follows…
object-group service WEB-PORTS tcp
port-object eq www
port-object eq https
object-group service WEB-PORTS
service-object tcp eq 80
service-object tcp eq 443
The port-object defines the object name and the protocol in the object statement, while the service-object defines the protocol and the port together. The following ACL explains that…
Port-Object within an extended ACL
The port-object is defined at the end of the ACL.
access-list ACL_in extended permit tcp NETWORK SUBNET any object-group WEB-PORTS
Service-Object within an extended ACL
While the service-object statement is replaced as a substitute for the protocol with the ACL.
access-list ACL_in extended permit object-group WEB-PORTS NETWORK SUBNET any
The following method will enable a Cisco Aironet Autonomous Access Points to be converted into Lightwright mode by flashing the code. I have tested this on c1252 model but the same method should work as long as the models are supported by Cisco.
Download the recovery image and place it in the TFTP Server.
Remove the trailing
.tar from the image filename, it should look something like the following.
Set the Laptop IP Address as follows…
IP Address: 10.0.0.5
Subnet Mask: 255.255.248.0
Default Gateway: 10.0.0.10
Once you are in RAMON format flash: and set the IP Address on the AP as the following.
ap: format flash:
ap: set IP_ADDR 10.0.0.5
ap: set NETMASK 255.255.248.0
ap: set DEFAULT_ROUTER 10.0.0.10
Issue the following command on the AP to transfer the file from the TFTP Server to Flash
ap: tar -xtract tftp://10.0.0.5/c1250-rcvk9w8-tar.152-4.JB6 flash:
Use the following command to find the exact location of the image.
[click to continue…]
The following JunOS configuration has been tested on PlusNet Fibre broadband running with external BT Openreach Modem. This setup should work with other VDSL/FTTC providers since they use the same underlaying BT infrastructure.
- The configuration has been tested on SRX210H running JunOS
- BT Openreach modem connect to interfaces
fe-0/0/7 on the SRX
Set the underlaying interface encapsulation to be PPP-Over-Ethernet.
set interfaces fe-0/0/7 unit 0 encapsulation ppp-over-ether
Set PPP Options with Authentication method CHAP.
If your ISP happen to use PAP Authentication method, then you need to reflect that.
set interfaces pp0 unit 0 ppp-options chap default-chap-secret YOUR-PASSWORD
set interfaces pp0 unit 0 ppp-options chap local-name YOUR-USERNAME
set interfaces pp0 unit 0 ppp-options chap no-rfc2486
set interfaces pp0 unit 0 ppp-options chap passive
[click to continue…]
Configuring a Cisco ASA firewall to achieve resiliency is straightforward. Implementing the failover feature in the firewall to be on Active Standby mode can achieved by the following commands.
Please note that it is not recommended to use the Management interface for failover purposes, especially for stateful failover in which the security appliance constantly sends the connection information from one security appliance to the other.
Furthermore, we have to consider the future implication of using such Management Interface, as you may be want to create a completely new network for the Out Of Bound (OOB) access where the Management Interface on each device will participate. Therefore, using a Management Interface might cause design issues in the future.
On this example below, I will be using
GigabitEthernet0/5 on both devices as the Failover interface.
[click to continue…]
Border Gateway Protocol (BGP) is the core of Internet and yet its versatility is hardly utilised by majority of the networking community within a data centre environment. BGP is widely used by the service provides and also in conjunction with MPLS. In the introduction of Software-Defined Networking (SDN), the whole concept of network will change dramatically in the coming years; some could say it has already changed, and I agree. We will hardly be managing devices individually and it will become impractical to manage 100s or even 1000s of devices in a data centre architecture.
Why Border Gateway Protocol?
I will try and justify my views as how BGP would be the perfect candidate as a SDN backbone. However, other protocols will still tick some of the boxes but those won’t be able to tick every boxes as BGP does.
I can’t think of a protocol which is versatile enough to handle control plane and data plane separate, yet when it comes to talking between control and data plane, it does it efficiently. After all, SDN is all about separating Control Plane from Data Plane.
[click to continue…]