Next target is SWITCH, TSHOOT, BGP, MPLS, QoS.....................
বৃহস্পতিবার, ২৯ ডিসেম্বর, ২০১১
ROUTE (642-902) Successfully Passed.
Next target is SWITCH, TSHOOT, BGP, MPLS, QoS.....................
শুক্রবার, ২৫ নভেম্বর, ২০১১
Resetting Password of Cisco Switch:
Use the following terminal settings:
3. Power the switch and bring it to the switch: prompt:
For 2900XL, 3500XL, 2940, 2950, 2960, 2970, 3550, 3560, and 3750 series switches, do this:
Catalyst Switch Series | LED Behavior and Mode Button Release Action |
2900XL, 3500XL, 3550 | Release the Mode button when the LED above Port1x goes out. |
2940, 2950 | Release the Mode button after approximately 5 seconds when the Status (STAT) LED goes out. When you release the Mode button, the SYST LED blinks amber. |
2960, 2970 | Release the Mode button when the SYST LED blinks amber and then turns solid green. When you release the Mode button, the SYST LED blinks green. |
3560, 3750 | Release the Mode button after approximately 15 seconds when the SYST LED turns solid green. When you release the Mode button, the SYST LED blinks green. |
The Catalyst 2955 series switches do not use an external mode button for password recovery. Instead the switch boot loader uses the break-key detection to stop the automatic boot sequence for the password recovery purposes. The break sequence is determined by the terminal application and operating system used. Hyperterm running on Windows 2000 uses Ctrl + Break. On a workstation running UNIX, Ctrl-C is the break key.
Note: Make sure to type a colon ":" after the dir flash.
Note: Overwrite the passwords which are necessary. You need not overwrite all of the mentioned passwords.
শনিবার, ১৯ নভেম্বর, ২০১১
Several type attack and mitigation by ACL
In simple words, VLAN Hopping attack, invloves an attacker using a double-encapsulated 802.1Q frames to manipulate the switch operation. As the double-tagged frame enters the switch, switch performs only one level of decapsulation. For better understanding, we use an example:
The attacker sends a double-tagged 802.1Q frames to switch. The outer header has the VLAN of the attacker, which is the same as the native VLAN of the trunk port.(For the purpose of this example, assume VLAN 5). The inner tag is the victim VLAN, VLAN 10.
The frame arrives on the switch, which looks at the first 4-byte 802.1Q tag. The switch sees that the frame is destined for VLAN 5 and sends it out on all VLAN 5 ports(including the trunk), because there is no CAM table entry. At this point the second tag is still intact and has not been inspected by the first switch.
The frame arrives at the second switch but has no knowledge that is was supposed to be for VLAN 5 (native vlan is not tagged by the sending switch as specified in the 802.1Q specification)
The second switch looks at only the 802.1Q tag(the former inner tag that the attacker sent) and sees that the frame is destined for VLAN 10 (the victim VLAN). The second switch sends the packet on to the victim port or floods it, depending on whether there is an existing CAM table entry for the victim host.
HOW TO MITIGATE :
1) if no trunking is required on an interface, disable trunking :
Switch(config-if)# switchport mode access
2) If trunking is necessary, enable it but prevent DTP frames from being generated:
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport nonegotiate
3) if the trunking is required, set the native VLAN on the trunk to an unused VLAN.
Switch(config-if)#switchport trunk native vlan
NOTE : There is no way to execute these kind of attacks unless the switch is misconfigured.
Smurf Attack :
Smurf attack consists of large numbers of ICMP packets sent to a router subnet broadcast address using a spoofed source IP address from the same subnet. You need to use a ACL which blocks all IP packets originating from any host destined for the subnet broadcast addresses. [The router here has a subnet: 16.2.1.0/24]
============================
Router(config)# access-list 110 deny ip any host 16.2.1.255 log
Router(config)# access-list 110 deny ip any host 16.2.1.0 log
Router(config)# access-list 110 permit ip any any
Router(config)# interface e0/0
Router(config)# ip access-group 110 in
Router(config) end
==============================
NOTE : In Cisco IOS Release 12.0 or later, there is a command “no ip directed-broadcast” which is enabled by default and prevents this type of attack. Then you may not need to learn and apply this ACL!!
Mitigating DoS attack by ACL
Considering you know about DoS attacks and their behavior, we take a look at ACLs that can mitigate this kind of attack. The interesting! point about DoS attacks is they can be prevented but can’t be stopped if they have begun. Here we talk about some known tools and the way we can counteract them. These tools include : Trin00, Stacheldraht, Trinity v3, Subseven. Below you can see the tools and their respective ports:
Trin00: TCP/1524- TCP/27665- UDP/27444- UDP/31335
Stacheldraht : TCP/16660- TCP/65000- ICMP/echo- ICMP/echo-reply
Trinity V3: TCP/33270- TCP/6667
Subseven : TCP/2222- TCP/6669- TCP/range 6711 6712- TCP/6776- TCP/7000
We choose “Trinity V3″. The router here has two interfaces, e0/0, e0/1
=============================
Router(config)# access-list 180 deny tcp any any eq 33270 log
Router(config)# access-list 180 deny tcp any any eq 6667 log
Router(config)# access-list 180 permit ip any any
Router(config)#interface e0/0
Router(config)# ip access-group 180 in
Router(config)# end
Router(config)# interface e0/1
Router(config)# ip access-group 180 in
Router(config)# end
=============================
NOTE : we bound the ACL to “in” direction.
বৃহস্পতিবার, ২০ অক্টোবর, ২০১১
Nagios [Monitoring Tool] Quick Installation and Basic configuration on debian:
Prerequisites:
1. Apache 2
2. PHP
3. GCC Compiler and development libraries
4. GD development libraries.
Install these packages from internet by apt-get command.
#apt-get install apache2
#apt-get install libapache2-mod-php5
#apt-get install build-essential
#apt-get install libgd2-xpm-dev
Or by only one command:
#apt-get install apache2 libapache2-mod-php5 build-essential libgd2-xpm-dev
Create account Information:
You have to create one user (nagios)and two groups (nagios, nagcmd). Nagcmd group will be use for allowing external commands to be submitted through the web interface. And nagios user will be member of nagios and nagcmd group. Apache user(www-data) will also be a member of nagcmd group.
#adduser nagios
Then set password for this user. No need to create nagios group externally. By default it will be created and nagios user will be a member of this group.
#groupadd nagcmd
#usermod -a -G nagcmd nagios
#usermod -a -G nagcmd www-data
Download Nagios and Plugins packages:
Here I have installed nagios core 3.2.3 version and plugins 1.4.11 version.
Download both packages in any directory .
#wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.3.tar.gz
#wget http://prodownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.11.tar.gz
Compile and Install Nagios:
Extract the nagios source code and enter extracted directory.
#tar zxvf nagios-3.2.3.tar.gz
#cd nagios-3.2.3
Run the Nagios configure script and passing the name of the nagcmd group then compile Nagios source code.
#./configure –with-command-group=nagcmd
#make all
Install binaries, init scrip, sample config file and set permissions on the external command directory.
#make install
#make install-init
#make install-config
#make install-commandmode
Nagios will be install in the /usr/local/ directory.
Configure web Interface:
Install the nagios web config file in the Apache conf.d directory.
#make install-webconf
Create nagiosadmin account for logging into the Nagios web interface and assign password.
#htpasswd –c /usr/local/nagios/etc/htpasswd.users nagiosadmin
Customize Contact information:
Edit /usr/local/nagios/etc/objects/contacts.cfg config file and replace your e-mail address by any editor.
Restart Apache to make new settings take effect.
#/etc/init.d/apache2 reload
Compile and Install the Nagios plugins:
Extract the nagios-plugins source code and enter extracted directory
#tar zxvf nagios-plugins-1.4.11.tar.gz
#cd nagios-plugins-1.4.11
Compile and install plugins:
Run the Nagios-plugins configure script and passing the user and group name nagios then compile Nagios-plugins source code.
#./configure --with-nagios-user=nagios --with-nagios-group=nagios
#make
#make install
Start Nagios:
Configure nagios to automatically start when the system boots.
#ln –s /etc/init.d/nagios /etc/rcS.d/S99nagios
Verify the Nagios configuration file:
#/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
If no error found then it will shows :
Total Warnings: 0
Total Errors: 0
If there are no errors, Start Nagios.
#/etc/init.d/nagios start
Login to the web interface:
বৃহস্পতিবার, ২২ সেপ্টেম্বর, ২০১১
VLAN Configuration on Debian/ubuntu
1. apt-get install vlan [VLAN Package installation]
2. vim /etc/network/interfaces [Open interfaces for edit]
auto vlan10 [To auto up vlan10]
auto vlan20 [To auto up vlan20]
iface vlan10 inet static [Static IP address assignment in vlan10]
address xxx.xxx.xxx.xxx
netmask xxx.xxx.xxx.xxx
network xxx.xxx.xxx.xxx
broadcast xxx.xxx.xxx.xxx
mtu 1500 [Declare mtu]
vlan_raw_device ethx [vlan10 attached with physical interface ethx]
iface vlan20 inet static [Static IP address assignment in vlan20]
address xxx.xxx.xxx.xxx
netmask xxx.xxx.xxx.xxx
network xxx.xxx.xxx.xxx
broadcast xxx.xxx.xxx.xxx
mtu 1500 [Declare mtu]
vlan_raw_device ethx [vlan20 attached with physical interface ethx]
3. /etc/init.d/networking restart [Restart network interfaces]
[Vlan ID and config file will create under /proc/net/vlan/]
বুধবার, ১৪ সেপ্টেম্বর, ২০১১
শুক্রবার, ২৬ আগস্ট, ২০১১
BGP Path Selection Process
1. Weight (Bigger is better)
2. Local preference (Bigger is better)
3. Self originated (Locally injected is better than iBGP/eBGP learned)
4. AS-Path (Smaller is better)
5. Origin (Prefer ORIGIN code I over E, and E over ?)
6. MED (Smaller is better)
7. External (Prefer eBGP over iBGP)
8. IGP cost (Smaller is better)
9. EBGP Peering (Older is better)
10. RID (Lower is better)
রবিবার, ১৯ জুন, ২০১১
Difference between IP INSPECT and IP ACCESS-GROUP
Difference between IP INSPECT and IP ACCESS-GROUP
The ip access-group references a stateless ACL. All packets flowing through an interface where this ACL is placed in a particular direction will be permitted or dropped according to the entries in this ACL.
The ip inspect does not by itself filter any packets. However, it inspects them - it looks into them and tries to determine the protocol, port, perhaps even application data that is transported inside the inspected packets. Basing on the information gained by this analysis, the ip inspect then builds a session table. The session table therefore contains information about all sessions (conversations, if you so call them). And now comes the most interesting part: when a reply packet arrives in the opposite direction, the router consults this session table and if the packet indeed belongs to a known session, the router will bypass the ACL placed on interfaces and allow this packet to go through.
The ip inspect mechanism is also called the CBAC - Context-Based Access Control, and it is used to create stateful firewalls, that is, firewalls that are able to identify individual conversations and once a particular connection has been permitted from inside to outside, the reply in the opposite direction will be permitted automatically, without having the permit it in any additional ACL.
The CBAC knows many higher-level protocols and it is also able to cope with protocols that use random ports and where it is almost impossible to effectively control such traffic using static ACLs.
The ip inspect and ip access-group are often combined, for example:
ip inspect name MyFW tcp
ip inspect name MyFW udp
ip inspect name MyFW icmp
access-list 100 deny ip any any
interface Fa0/0
ip inspect MyFW in
ip access-group 100 out
Here, the router allows any traffic to enter the the Fa0/0 (there is no ip access-group for the inbound direction). Furthermore, it makes a note of each TCP, UDP or ICMP conversation that was initiated by a packet entering the Fa0/0 (the ip inspect in the inbound direction). When a reply packet in this conversation arrives, the router will first consult the session table created by the ip inspect, and if there is a corresponding session entry for this packet, it will be allowed to go out the Fa0/0. However, if there is no session information for this packet in the session table, it will be subjected to the ACL 100 which will drop it.
Essentially, I have built here a simple stateful firewall: I allow any connection initiated from an inside network. However, I will permit only responses to be sent back to the inside network. No connections initiated from outside will be permitted to go to the inside network.
So once again: the "ip access-group" filters packets right there, according to a given ACL. The "ip inspect" makes a table of conversations and "temporarily opens holes" in ACLs in the opposite direction to allow a bidirectional communication for each conversation.
N.B: This article is followed from http://www.configrouter.com/topic/difference-between-ip-inspect-and-ip-access-group
Configuration of a drop-in bridged CISCO Router / Firewall
Configuration of a drop-in bridged CISCO Router / Firewall
Overview
Often, you have a given network layout which cannot be changed. For example, you own only a few routable IP-Addresses and therefore must use the same Network-ID for the DMZ (Demilitarized Zone) and your Internet connection. Some modern Firewalls / Routers allows to "drop-in" in such a network configuration. That means, no network changes have to be made and only one IP-Address is used for the router / firewall. If you use a Cisco Router, this can be difficult, because usually each interface on a Cisco Router must have one IP-Address assigned to it. But there is a trick - so called bridging - using this feature you can overcome these difficulties.
Cisco Router / Firewall using only one IP-Address
Features of a bridged Cisco Router / Firewall
The following features can be used with Cisco's IOS and an 2621 Router
Integrated Bridging between Internet and DMZ
The main features of this configuration is, that we can use the same network (194.246.125.192/28) for the Internet and the DMZ. No routing is necessary between the DMZ and Internet, only one IP-Address is used for the Firewall.
The following figure shows the configuration of the Cisco 2621 firewall. The firewall is setup with three interfaces for the External, Optional and Trusted Interface.
-
External Interface: Ethernet1/0 (Internet)
-
Optional Interface: FastEthernet0/0 (DMZ)
-
Trusted Interface: FastEthernet0/1 (HSZ)
The external and optional Interface are bridged. For the trusted interface an access-list for IN (102) and OUT (103) is setup and maintained. For the bridged intrerface only the IN (150) access-list is setup.
Configure Interfaces
To configure a router interface in the Cisco IOS software, use the following commands, starting in global configuration mode.
interface FastEthernet0/0
description DMZ
no ip address
duplex auto
speed auto
bridge-group 32
!
interface Ethernet1/0
description Internet
no ip address
bridge-group 32
!
Enable Integrated Routing and Bridging
After you have set up the interfaces in the router, you can enable integrated routing and bridging. To enable integrated routing and bridging in the Cisco IOS software, use the following command in global configuration mode.
bridge irb
Use the show interfaces irb privileged EXEC command to display the protocols that a given bridged interface can route to the other routed interface when the packet is routable, and to display the protocols that a given bridged interface bridges.
show interfaces irb
FastEthernet0/0 DMZ
Routed protocols on FastEthernet0/0:
ip
Bridged protocols on FastEthernet0/0:
ip
Software MAC address filter on FastEthernet0/0
Hash Len Address Matches Act Type
0x00: 0 ffff.ffff.ffff 43016 RCV Physical broadcast
0x2A: 0 0900.2b01.0001 0 RCV DEC spanning tree
0xB9: 0 0002.b91d.2700 2115670 RCV Interface MAC address
0xB9: 1 0002.b91d.2700 0 RCV Bridge-group Virtual Inter
0xC0: 0 0100.0ccc.cccc 0 RCV CDP
0xC2: 0 0180.c200.0000 0 RCV IEEE spanning tree
0xC2: 1 0180.c200.0000 0 RCV IBM spanning tree
0xC2: 2 0100.0ccd.cdce 0 RCV VLAN Bridge STP
FastEthernet0/1 HSZ
Routed protocols on FastEthernet0/1:
ip
Ethernet1/0 Internet
Routed protocols on Ethernet1/0:
ip
Bridged protocols on Ethernet1/0:
ip
Software MAC address filter on Ethernet1/0
Hash Len Address Matches Act Type
0x00: 0 ffff.ffff.ffff 9669 RCV Physical broadcast
0x2A: 0 0900.2b01.0001 0 RCV DEC spanning tree
0xA9: 0 0002.b91d.2710 0 RCV Interface MAC address
0xB9: 0 0002.b91d.2700 1916977 RCV Bridge-group Virtual Inter
0xC0: 0 0100.0ccc.cccc 0 RCV CDP
0xC2: 0 0180.c200.0000 0 RCV IEEE spanning tree
0xC2: 1 0180.c200.0000 0 RCV IBM spanning tree
0xC2: 2 0100.0ccd.cdce 0 RCV VLAN Bridge STP
BVI32
Routed protocols on BVI32:
ip
Configure the Bridge-Group Virtual Interface
The bridge-group virtual interface resides in the router. It acts like a normal routed interface that does not support bridging, but represents the entire corresponding bridge group to routed interfaces within the router. The bridge-group virtual interface is assigned the number of the bridge group that it represents. The bridge-group virtual interface number is the link between the bridge-group virtual interface and its bridge group. Because the bridge-group virtual interface is a virtual routed interface, it has all the network layer attributes, such as a network address and the ability to perform filtering. Only one bridge-group virtual interface is supported for each bridge group.
When you enable routing for a given protocol on the bridge-group virtual interface, packets coming from a routed interface but destined for a host in a bridged domain are routed to the bridge-group virtual interface, and are forwarded to the corresponding bridged interface. All traffic routed to the bridge-group virtual interface is forwarded to the corresponding bridge group as bridged traffic. All routable traffic received on a bridged interface is routed to other routed interfaces as if it is coming directly from the bridge-group virtual interface.
To create a bridge-group virtual interface, use the following command in interface configuration mode:
interface BVI32
ip address 194.246.125.195 255.255.255.240
ip access-group 150 in
no ip redirects
ip nat outside
ip inspect Ethernet_BVI in
When you intend to bridge and route a given protocol in the same bridge group, you must configure the network-layer attributes of the protocol on the bridge-group virtual interface. Do not configure protocol attributes on the bridged interfaces. No bridging attributes can be configured on the bridge-group virtual interface.
Configure Protocols for Routing or Bridging
When integrated routing and bridging is enabled, the default route/bridge behavior in a bridge group is to bridge all packets.
You could then explicitly configure the bridge group to route a particular protocol, so that routable packets of this protocol are routed, while nonroutable packets of this protocol or packets for protocols for which the bridge group is not explicitly configured to route will be bridged.
You could also explicitly configure the bridge group so that it does not bridge a particular protocol, so that routable packets of this protocol are routed when the bridge is explicitly configured to route this protocol, and nonroutable packets are dropped because bridging is disabled for this protocol.
Specify a protocol to be routed in a bridge group use the following command:
bridge 32 route ip
Context Based Access Control (CBAC) is able to manage multichannel applications such as FTP, CU-SeeMe, H.323, etc. Multichannel applications are those that use one connection for the commands that are sent between the client and server and another, possibly multiple, connections for the data sent between the client and server. Often, the connection for the data channel may be initiated from the server to the client. Without understanding the behaviour of these applications, the router would not know whether these data channels from the server to the client should be permitted or denied access.
Operation
The process CBAC follows to monitor outbound traffic sessions and create appropriate inbound access-list entries as follows:
-
An outgoing packet reaches a router interface. The packet is evaluated against an access list applied to the interface. The access list should allow all traffic to be inspected by CBAC. (Traffic denied by the access list will be dropped.)
-
CBAC will examine the packet and record information about it in the state table (this table is viewable with the command show ip inspect session detail). The information in the state table includes the source and destination IP addresses and TCP or UDP port numbers.
-
CBAC creates a temporary opening in an access list for the return traffic; these openings will vary depending on the application used. The temporary entries will be placed on the interface that will receive the return traffic.
-
A return packet reaches a router interface. The return packet is permitted by the temporary access-list entries and inspected by CBAC. CBAC will update the state table and modify the temporary access-list entries if necessary. All future packets that are part of this network conversation are inspected similarly to update tables and access-list entries as needed.
-
When the connection is completed, the entries in the state table and the inbound access list are removed. For TCP these entries are removed after a normal FIN exchange between the client and server. For UDP there are configurable inactivity timeouts.
Limitation
CBAC inspects only TCP and UDP packets. Other IP traffic (such as Internet Control Message Protocol, or ICMP) must be filtered with traditional IP access lists. Packets with the router as the source or destination address are not inspected by CBAC. If both Cisco encryption technology (CET) and CBAC are configured, CBAC will not be able to accurately inspect the contents of the CET-encrypted packets.
If both IPSec and CBAC are configured, CBAC can inspect the traffic correctly as long as the CBAC router is the end point of the IPSec tunnel. If the router is not the end point of the tunnel, CBAC cannot inspect the packets because the packets will not have a TCP or UDP header.
CBAC uses approximately 600 bytes of memory per connection to maintain each entry in the state table. In addition, a small amount of additional processing occurs during the inspection process.
Network Address Translation NAT
NAT is a feature that dynamically modifies the contents of IP packets flowing through the router so that the source and/or destination IP addresses are altered. Packets leaving the router will have the source or destination address translated to a different IP address so an administrator can hide the IP addresses in use on an internal network behind a router performing NAT. This technique is a requirement for organizations using addresses from the RFC 1918 unregistered address space or using IP addresses that are registered to other organizations.
Characteristics
NAT can be used to alter both the source and destination IP addresses in IP headers and the IP checksum is updated automatically by the NAT process. Some applications imbed the source IP address of hosts in the data portion of the IP packet, so additional modification of the packet is required. For these applications, the NAT process must also modify the data portion of the packet to match the modified source IP address in the IP header. Cisco's version of NAT can handle many applications that place the IP address in the data portion of the packet. Cisco's version also allows load-sharing TCP traffic by permitting TCP requests to a single IP address to be serviced by multiple hosts.
NAT is most often used at administrative domain boundaries such as the Internet or connections between different organizations. NAT is useful not only for organizations that do not have registered IP addresses, but also for organizations that have a registered IP address range but have more hosts than can be accommodated by the number of addresses. Unregistered addresses may be used internally and registered addresses used only when packets communicate with external networks. The NAT process is transparent to both source and destination hosts for most applications.
Caveats
Although NAT is a very useful tool, it does have some drawbacks. The central difficulty with NAT is that, as mentioned earlier, some applications imbed the original source IP address in the data portion of the IP packet. Therefore, after undergoing NAT, the source IP address of the packet does not match the IP address imbedded in the data portion of the packet. Applications which imbed the IP address in the data portion of the packet function improperly if the source IP address in the IP header does not match the source IP address imbedded in the data portion of the packet. The Cisco implementation can handle most popular applications that include the IP address in the data portion of the packet. One notable exception is NetBios session services. NetBios services are used by Windows NT, so it is very prevalent in many data networks.
NAT Terms
Several terms used when discussing Cisco NAT are helpful:
-
Inside local address. IP addresses assigned to hosts on the internal network. These addresses are normally only known by internal hosts.
-
Inside global address. IP addresses assigned to internal hosts by the NAT process; the addresses of internal hosts as seen by external hosts.
-
Outside local address. IP addresses assigned to external hosts by the NAT process; the addresses of external hosts as seen by internal hosts.
-
Outside global address. IP addresses assigned to hosts on the external network. These addresses are known by external hosts but may not be known by internal hosts.
Inside addresses are used by the internal network and may or may not be translated. Outside addresses are used by external networks and also may or may not be translated. The term local refers to addresses as seen by internal hosts.
The term global refers to addresses as seen by external hosts. Note that outside local and outside global addresses may be the same if outside addresses are not being translated by NAT, that is, the addresses of external hosts may be the same on external networks as on the internal network.
The easiest way to remember this terminology is that the first word, inside or outside, reflects the origination of the packet. The terms inside local and inside global address both indicate that the packet originated from the inside network. The second word, local or global, indicates where the addresses are seen. Local addresses are seen locally on the inside network. Global addresses are seen globally on the outside network.
Enabling NAT
Familiarity with several commands is required to enable NAT functionality on the router. First, you need to determine the interfaces on which you will enable NAT and whether they will be an inside or outside interface.
Normally, the interface that connects to your internal network will be the NAT inside and any interfaces that connects to external networks, such as the Internet, will be the NAT outside interface. You can show the translated IP adresses with show ip nat trans
An access list is an ordered set of statements that permits or denies the flow of packets across an interface based on matching criteria of access list parameters and information contained in packets.
Since the flow of data across an interface is bidirectional, an access list can be applied to a specific direction an interface, either inbound or outbound. Here the term inbound refers to the flow of data toward a router, while outbound refers to the flow of data in a direction away from a router.
Standard IP Access List
Two types of access lists are supported by Cisco routers, standard and extended. A standard access list is limited in functionality because it only allows filtering based upon source address. In comparison, an extended access list, as its name implies, extends packet filtering, enabling you to filter packets based upon both source and destination address and upperlayer application data.
The following number ranges are used for standard and extended lists.
-
Standard access lists: 1-99
-
Extended access lists: 100 - 199
The format of a standard access list is shown next:
access-list[list-number][permit|deny][source address][wildcard-mask][log]
Permit / Deny
Use of the keyword permit or deny is what specifies whether or not packets that match an access-list entry are allowed to flow through an interface or are filtered.
Source Address
For a standard IP access list the source address is the IP address of a host or group of hosts specified using dotted decimal notation. In reality, the specification of a group of hosts is based upon the use of the wildcard-mask explained next.
Wildcard-mask
The wildcard-mask supported by Cisco access lists functions in a reverse manner to a subnet mask. That is, the access-list mask uses a binary 0 to represent a match and a binary 1 to represent a ?don't care? condition. To illustrate the operation of a wildcard-mask, let's assume your organization has the class C network address 198.78.46.0. Assuming you did not employ subnets, when you configure each station on that network you would enter a subnet mask of 255.255.255.0. In this situation a 1 bit represents a match, while a 0 bit represents a ?don't care? condition. Since the Cisco wildcard-mask is the opposite of a subnet mask, the following standard IP access-list statement is for all packets with a source network address of 198.78.46.0:
access-list 1 permit 198.78.46.0 0.0.0.255
In the preceding access-list statement note that the wildcard-mask of 0.0.0.255 is the compliment of the subnet mask. Thus, another technique to specify an access-list wildcard-mask is to determine the subnet mask and take its inverse.
Host
Host signifies an exact match and represents the wildcard-mask of 0.0.0.0. For example, assume you want to permit packets from source address 198.78.46.8. You could code the following access-list statement:
access-list 1 permit 198.78.46.8 0.0.0.0
Since the keyword host signifies an exact match, the previous access-list statement can be recorded as follows:
access-list 1 permit host 198.78.46.8
Thus, host is an abbreviation for a wildcard-mask of 0.0.0.0
Any
In a standard access list the keyword any is used as an abbreviation for a source address and wildcard-mask of 0.0.0.0 255.255.255.255. For example, assume you wish to deny packets from source address 198.78.46.8 and permit packets from all other addresses. The standard access-list statements to accomplish this would be as follows:
access-list 1 deny host 198.78.46.8
access-list 1 permit anyNote the order of the two statements!
Access-list statements are processed in a top-down order. If we reversed the order and placed the permit statement before the deny statement, we would not be able to bar or filter packets from host address 198.78.46.8 because the permit statement would allow all packets.
Log
When included log in an access list, this keyword results in the logging of packets that match permit and deny statements in the access list. Logging can be done to the console or to another host using the syslog daemon.
Extended IP Access Lists
An extended IP access list, as its name implies, extends the ability to filter packets. An extended IP access list allows you to filter packets based upon source and destination address, protocol, source and destination port, and a variety of options that permit comparison of specific bits in certain packet fields.
The general format of an extended IP access list is shown below:
access-list[list number][permit|deny][protocol|protocol keyword][source
address source-wildcard][source port][destination address][destination-
wildcard][destination port][log][options]
List Number
Similar to a standard IP access list, the list number identifies an extended IP access list. Numbers 100-199 can be used to define 100 unique extended IP access lists.
Protocol (!)
The protocol entry defines the protocol to be filtered, such as IP, TCP, UDP, ICMP, and so on. The entry of a protocol is important because of the relationship of protocols within the TCP/IP protocol suite that forms datagrams.
That is, an IP header is used to transport ICMP, TCP, UDP, and various routing protocols so that if you specify IP as the protocol to be filtered, all matches against other fields will cause the packet to be permitted or denied regardless of whether the packet represents an application transported by TCP, UDP, or an ICMP message. Thus, if you wish to filter based on a specific protocol, you should specify that protocol. In addition, you should place more specific entries ahead of less specific entries.
For example, if you code a statement permitting IP for a specific address, followed by denying TCP for that address, the second statement would never take effect. However, by reversing the order you could bar TCP to the address, while permitting all other protocols to that address.
Port Number
The source port number can be specified in several ways. It can be
specified explicitly, either as a numeric or as a recognized mnemonic. For example, you could use either 80 or http to specify the Web's hypertext transmission protocol. For TCP and UDP you can use the keyword opertors < (less than), > (greater than), = (equal) and <> (not equal).Options
A wide range of options is supported by an extended IP access list. One commonly used option is Iog, which was described earlier when we discussed standard IP access lists. A second commonly used option is established. This option is only applicable to the TCP protocol and is employed to restrict TCP traffic in one direction as a response to sessions initiated in the opposite direction. To accomplish this, an access list statement with the established option examines each TCP packet to determine if its ACK or RST bit is set. If it is set, the packet is part of a previously established conversation.
Important Rules
The following rules are important for success. These rules are a mixture of fact and suggestion. The factual portion of a rule is based upon the manner in which access-list processing occurs.
-
Top-Down Processing
Access-list entries are evaluated from the top down sequentially, commencing with the first entry in the list. This means you must carefully consider the order in which you place statements in an access list.
-
Adding Entries
New entries are added to the bottom of an access list, which means it may not be possible to change the functionality of an existing access list, requiring you to create a new list, delete the existing list, and apply the new list to an interface.
-
Standard List Filtering
Standard IP access lists are limited to filtering on source address only, so you may need to use an extended IP access list to satisfy specific organizational requirements.
-
Access-List Placement
Consider placing extended access lists as close as possible to the source being filtered so that you can create filters that do not adversely affect the data flow on other interfaces. Also, consider placing standard access lists as close as possible to the destination. Since a standard access list only uses source addresses, placing the list too close to the source can block the flow of packets to other ports.
-
Statement Placement
Since IP includes ICMP, TCP, and UDP, you should place more specific entries in an access list before less specific entries to ensure that one statement ahead of another does not negate the effect of a statement appearing later in the list. access list is applied to an interface, no filtering will occur.
-
Filtering Direction
The filtering direction defines whether inbound or outbound packets are examined. Always double-check the filtering direction because it defines which packets are examined.
Disable ICMP Redirect Messages
All DMZ Hosts have the BVI32 virtual Interface as their Gateway. If one of this DMZ hosts communicate with a client in the Internet, the Router sends an ICMP Redirect with the address of the Internet client. From now on, the DMZ host sends the IP pakets directly to the Internet client, instead of the Gateway and the Access-List 150 is bypasswd. This not desired effect can be disabled on the BVI32 Interface with the command
no ip redirects
Routes sometimes can become less than optimal. For example, it is possible for the router to be forced to resend a packet through the same interface on which it was received. If this happens, the router sends an ICMP Redirect message to the packet's originator telling it that it is on a subnet directly connected to the router, and that it must forward the packet to another system on the same subnet. It does so because the originating host presumably could have sent that packet to the next hop without involving the router at all. The Redirect message instructs the sender to remove the router from the route and substitute a specified device representing a more direct path. This feature is enabled by default.
Complete Configuration File
Here is the complete configuration file:
!
version 12.1
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname c2621
!
logging buffered 4096 debugging
no logging console
enable secret 5 $1$elmZ$4.EfdgcLJz7MNUffP4HHA0
enable password 7 045C05030632
!
ip subnet-zero
no ip finger
no ip domain-lookup
!
ip inspect max-incomplete high 1100
ip inspect max-incomplete low 900
ip inspect one-minute high 1100
ip inspect one-minute low 900
ip inspect name Ethernet_HSZ ftp timeout 3600
ip inspect name Ethernet_HSZ tcp timeout 3600
ip inspect name Ethernet_HSZ http java-list 51 timeout 3600
ip inspect name Ethernet_HSZ smtp timeout 3600
ip inspect name Ethernet_HSZ udp timeout 15
ip inspect name Ethernet_HSZ cuseeme timeout 3600
ip inspect name Ethernet_HSZ h323 timeout 3600
ip inspect name Ethernet_HSZ rcmd timeout 3600
ip inspect name Ethernet_HSZ realaudio timeout 3600
ip inspect name Ethernet_HSZ streamworks timeout 3600
ip inspect name Ethernet_HSZ vdolive timeout 3600
ip inspect name Ethernet_HSZ sqlnet timeout 3600
ip inspect name Ethernet_HSZ tftp timeout 30
ip inspect name Ethernet_BVI smtp timeout 3600
ip inspect name Ethernet_BVI tcp timeout 3600
ip inspect name Ethernet_BVI udp timeout 15
ip audit notify log
ip audit po max-events 100
bridge irb
!
interface FastEthernet0/0
description DMZ
no ip address
duplex auto
speed auto
bridge-group 32
!
interface FastEthernet0/1
description HSZ
ip address 192.168.138.1 255.255.255.0
ip access-group 102 in
ip access-group 103 out
ip nat inside
ip inspect Ethernet_HSZ in
duplex auto
speed auto
!
interface Ethernet1/0
description Internet
no ip address
bridge-group 32
!
interface BVI32
ip address 194.246.125.195 255.255.255.240
ip access-group 150 in
no ip redirects
ip nat outside
ip inspect Ethernet_BVI in
!
ip nat inside source list 101 interface BVI32 overload
ip classless
ip route 0.0.0.0 0.0.0.0 194.246.125.193
no ip http server
!
logging trap debugging
logging facility user
logging 192.168.138.21
!
! Disabling NAT between HSZ and DMZ for some hosts
!
access-list 101 deny tcp host 192.168.138.28 194.246.125.192 0.0.0.15
access-list 101 deny tcp host 192.168.138.21 194.246.125.192 0.0.0.15
access-list 101 deny tcp host 192.168.138.15 194.246.125.192 0.0.0.15
access-list 101 deny udp host 192.168.138.28 194.246.125.192 0.0.0.15
access-list 101 deny udp host 192.168.138.21 194.246.125.192 0.0.0.15
access-list 101 deny udp host 192.168.138.15 194.246.125.192 0.0.0.15
access-list 101 permit ip 192.168.138.0 0.0.0.255 any
!
! Extended Access-Lists
!
access-list 102 permit ip 192.168.138.0 0.0.0.255 any
access-list 102 deny ip any any log
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.28 eq domain
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.15 eq domain
access-list 103 permit udp 194.246.125.192 0.0.0.15 host 192.168.138.28 eq domain
access-list 103 permit udp 194.246.125.192 0.0.0.15 host 192.168.138.15 eq domain
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.28 eq smtp
access-list 103 permit tcp 194.246.125.192 0.0.0.15 host 192.168.138.15 eq smtp
access-list 103 permit tcp host 194.246.125.196 host 192.168.138.21 eq 22
access-list 103 permit tcp host 194.246.125.196 host 192.168.138.28 eq 143
access-list 103 permit tcp host 194.246.125.196 host 192.168.138.15 eq www
access-list 103 deny icmp any any log
access-list 103 deny ip any any log
access-list 150 permit udp any any eq domain
access-list 150 permit udp any eq domain any range 1000 65000
access-list 150 permit tcp any any eq domain
access-list 150 permit tcp any eq domain any range 1000 65000
access-list 150 permit tcp 194.246.125.192 0.0.0.15 eq www any
access-list 150 permit tcp 194.246.125.192 0.0.0.15 eq smtp any
access-list 150 permit tcp 194.246.125.192 0.0.0.15 range 1000 65000 any eq smtp
access-list 150 permit tcp any 194.246.125.192 0.0.0.15 eq smtp
access-list 150 permit udp 194.246.125.192 0.0.0.15 range 1000 65000 any eq ntp
access-list 150 permit udp any 194.246.125.192 0.0.0.15 eq ntp
access-list 150 permit tcp host 194.246.125.196 eq 22 any
access-list 150 permit tcp host 194.246.125.196 host 192.168.138.21 eq 22
access-list 150 permit tcp host 194.246.125.196 host 192.168.138.28 eq 143
access-list 150 permit tcp host 194.246.125.196 host 192.168.138.15 eq www
access-list 150 permit tcp host 194.246.125.196 eq 443 any
access-list 150 permit tcp host 194.246.125.196 eq 3970 any
access-list 150 permit tcp host 194.246.125.196 eq 7777 any
access-list 150 permit tcp host 194.246.125.196 eq 7778 any
access-list 150 deny icmp any any log
access-list 150 deny ip any any log
bridge 32 protocol ieee
bridge 32 route ip
!
line con 0
transport input none
line aux 0
line vty 0 4
password 7 030F5A070D
login
!
end
Configuration
The CISCO Router is configured with TELNET or a serial line connection.
telnet 192.168.138.1
Trying 192.168.138.1...
Connected to 192.168.138.1.
Escape character is '^]'.
User Access Verification
Password: ........
c2621>enable
Password: .........
c2621# show config
Start the TFTP Server on your Windows 2000 Workstation and download the Configurationfile.
c2621# copy running-config tftp
Address or name of remote host []? 192.168.138.23
Destination filename [c2621-confg]? c2621-confg-2001.06.15
Upload the configurationfile
c2621# copy tftp running-config
Address or name of remote host []? 192.168.138.23
Source filename [c2621-confg]? c2621-confg-2001.06.15
Activate the configurationfile
c2621# write mem
You can also edit the configuration directly on the router
c2621# conf t
c2621(config)# .......
c2621(config)#
c2621# write mem
N.B: This article is followed from http://www.akadia.com/services/bridged_cisco_router.html