Module 11 Notes
- Reduce size of Broadcast Domains
- Restrict unnecessary traffic crossing long distance and/or slow links
- Conserve Public IP addresses with an organized NAT implementation
- Security!
- PoLP -> Network Segmentation limits access to only those who need it
- How is your system connected
- No connection to any network (best defense)
- private network (highly secure environments (military, grid))
- On the internet?
access to a system
- NAT: Using private IP addresses internally and translating to “public” IP’s when communicating on Internet
- Routers “route” traffic between different networks
- Can create routing rule to control which networks can communicate.
- Can create Access Control Lists (ACLs) to drop certain types of traffic
- Spoofed addresses
- Certain protocols
- Technical Solutions
- Network Address Translation (NAT)
- Access Control Lists (ACLs)
- Firewalls
- Planning/Layout Solutions
- Network Zoning
- Device that controls traffic in and out of a network based on ruleset
- Layer 4 Firewalls
- Rules based on Layer 3:
- IP Addresses of both internal and external computers
- e.g. allow all external systems to 170.129 (Public).20.101
- Allow 153.104.15.6 to 170.129 (Public).118.112
- Allow 153.104.15.0/24 to 170.129 (Public).18.0/24
- Deny Any to 170.129 (Public).15.0/24
- IP Addresses of both internal and external computers
- And Layer 4 “Port Numbers”
- Such as Port 80 (HTTP), 443 (HTTPS), 3389 (RDP)
- e.g. allow all external systems to 170.129 (Public).20.101 on port 80
- Allow 153.104.15.6:3389 to 170.129 (Public).118.112:3389
- Allow 153.104.15.0/24 to 170.129 (Public).18.0/24 on port 443
- Deny Any to 170.129 (Public).15.0/24 on port 3389
- Such as Port 80 (HTTP), 443 (HTTPS), 3389 (RDP)
- Rules based on Layer 3:
- Level 7: Application Firewalls
- newer
- Can inspect the entire packet including data
- Can set rules on layer 3/4+
- Info in data such as URLs
- Particular applications, regardless of ports
- Examples:
- Allow port 80 (HTTP) but block Facebook
- Allow port 80 (HTTP) to 170.129 (Public).20.101 but block if URL contains “/admin.php”
- Improving security by Placing systems with similar security requirements in “zones” protected by firewalls
- These requirements can include:
- Services they run
- Who accesses them
- Who manages them
- Operational criticality
- Data they store/process
- Regulatory requirements
- Move all servers into security “zones” behind network
firewalls
- Recognized best-practice (ISO, NIST, SANS CSC)
- Hardware firewalls required by policy and regulations (PCI,FISMA)
- Asset-based as opposed to perimeter approach to network traffic flow policy
- Quicker troubleshooting and incident response
- Improve intrusion prevention and monitoring
- Defense-in-depth
- Context: Firewall contexts can be viewed as “virtual” firewalls on the same hardware.
- Reasons for configuring separate contexts include:
- Simplify rule sets while maintaining security requirements
- Isolate systems according to security requirements
- Comply with policy and regulatory controls for isolation, monitoring, and logging
- Example's Planned Contexts:
- PCI: Systems processing credit cards
- HIPAA: Systems processing/storing Protected Health Info (PHI)
- ITS: Systems administered exclusively by central IT team
- General: Systems administered by central IT, other IT, and/or vendors
- Management: Systems used to manage network devices, building control, or other embedded devices
- Other possible:
- Research projects
- Professional Schools (Tuck Business, Thayer Engineering)
-
VLAN Groups: Grouping of VLANs within a context. These can include:
- DMZ: VLANS with systems directly accessible by Internal and/or External users.
- Production: Production systems only directly accessible by administrators and load balancers.
- Dev/Non-prod: Development and/or non-production systems
- Firewall rule update testing
- Allows different inbound, outbound and back-end rules
- Policy requirement and best practice
- Minimal impact for admins (different IP and checkbox on request)
- Two Types
-
Standard:
- Apply to source IP address or Network Only
- Layer 3
-
Extended:
- Apply to source and destination IP address and/or network
- Can also create rule for TCP Ports
- Layer 3 and 4
-
Standard:
-
Creating Access Lists
- Two Step Process:
- In global config mode – use ip access-list command to create list
- Apply list to interface with ip access-group command
- Interface config mode
- Specify in or out.
- Does list apply to packets entering interface (in) or leaving interface (out)
- Two Step Process:
Standard:
-
ip access-list standard name_of_list- Then rules:
permit/deny ip_address wildcard_mask
- Then rules:
Extended:
-
ip access-list extended name_of_list• Rules:permit/deny protocol source_ip wc_mask dst_ip wc_mask (port)
Standard Example:
- Create ACL:
- device(config)# ip access-list standard Net1
- device(config-std-nacl-Net1)# deny host 10.157.22.26
- device(config-std-nacl-Net1)# deny 10.16.4.0 0.0.0.255
- device(config-std-nacl-Net1)# permit any
- Apply to interface
- device(config)# int eth 1/1
- device(config-if-e10000-1/1)# ip access-group Net1 in
Extended Example:
- Create Access List
- (config)# ip access-list extended MYACL
- (config-nacl-myacl)# deny tcp host 10.0.0.2 host 10.0.1.2 eq 80
- (config-nacl-myacl)# deny tcp 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255 eq 23
- (config-nacl-myacl)# permit ip any any
- Apply to Interface
- (config)# interface fastEthernet 0/0
- (config-if)# ip access-group MYACL in
- Rules applied in order – top to bottom
- Hidden “Deny all” by default:
- When access lists are applied to an interface, a default “deny all all” is applied at the bottom
- So, must apply a “permit any” at the end of your list if appropriate
- Regular ACLs cannot be reordered: Must delete and recreate if order is messed up
- Watch your INs/OUTs: Think of the packet flow. IN is entering the interface, OUT is leaving the interface