How Many Types of ACLs are there in Cisco's Big IOS Security World....Continued

I thought to add some more IOS Security features in my previous list...might not be an exact ACL feature but in some way sometimes relies heavily on ACL.

1. ACL using Group-Objects...YES...now can use group objects to minimize number of ACLs like we do in ASA :-) isn't that cool enough...those old days are gone now. Thanks to some great programmers sitting out there in Cisco.

ACL group object feature came I guess in IOS 12.4(20T). It allows you to configure two types of group object.

* Network Objects
* Service Objects

And guess what...one more surprise with this feature is now we can use / notation with our IP addresses in Network Objects Group like 1.1.1.1/1...isn't that cool

Anyways...I'll demonstrate this feature in my next post and till the time I'll try to find out IOS for it.

2.) TCP Intercept - Another Cool IOS security feature

3.) URPF - Sometimes it also has to rely on ACLs...depending upon it's configuration mode

4.) NBAR - Cool QOS based Security Feature

5.) CAR -Of Course it not four wheeler CAR but CAR is acronym for Committed Access Rate and can be used as a security feature.

6.) IOS based IPS

7.) 802.1x

8.) CoPP - Control Plane Policing

9.) Setting up privilege level / Menu based Access For Users

10.) Setting Up Connection Limits - Defining Max number of TCP/UDP/ICMP packets from Single host
under defined time value, Max number of Half TCP sessions from
anyone under defined time value

I am sure there would be some other features as well along with some protocol specific features like RTBHF and Sink hole filtering...Those are more or less CCIE Security Topics anyways :-)

Happy Studying & Stay Tuned....

Best Regards,
Deepak Arora
CCIE#XXXXX...Oops that number is still missing

How Many Types of ACLs are there in Cisco's Big IOS Security World

Few days back I asked a question to a very confident CCNA Security guy...actually he just came to me before taking CCNA Security exam and asked me...hey,why don't you ask me something related to Security as I am feeling pretty confident that I know lots of security stuff now.

Hmmm...I said Okey and just asked him the following question :-)

How many ACLs and Firewall features we have in IOS related to Router Security ?

He said... Standard ACL, Extended ACL, Named ACL, Reflexive ACL, CBAC & Zone Based Firewall.

Hmmm...his list looks interesting but still not complete...maybe it was not a true CCNA Security Question as I never take a look at it's curriculum...Anyways...Following is my list and see if I missed something...Feel free to drop an email to me if you have something to add in this list.

1. Standard ACL
2. Extended ACL
3. Named ACL
4. TCP Established ACL / Reflexive ACL
5. Turbo ACL
6. CBAC
7. Zone Based Firewall
8. Time Based ACL
9. Dynamic ACL / Lock & Key ACL
10. Flexibal Packet Matching ACL
11. ACL to to prevent fragmented IP packets from reaching you application ports

Holy Cow...Did you ever think about that :-(

I must say even I still need to dig myself about which one takes precedence over other when multiple types are configured together

Some more ACL stuff in coming days along with solution of my last ACL Post...

Happy Studying...

Best Regards,
Deepak Arora
CCIE# XXXXX...Oops that number is still missing :-)

Filtering ALL Even Subnets With Single ACL

These days I am quite busy with my job schedule which is keeping me away from studies & blog.

Anyways... today lets play around some ACLs. I know many people who think that they know ACL stuff very well. But actually that's not the case. Specially if they were been given task like I show up in Diagram here. The challenge here is following:

R2 has got plenty of networks to advertise using EIGRP to R1. Administrator f R1 wants that only Odd Network Subnets like 192.168.1.0/24...3.0/24 etc of R2 should be able to reach LAN segment of R1 and all Even subnets should not be able to do that. And for that you are only allowed to use single ACL entry....but also don't use Group Objects ( If you know really what they are :-) )

So good luck to all of you * R1 Admins :-) * I will post the solution and some more ACL details soon.

Happy Studying...

Regards,
Deepak Arora

Fixing ASDM Error - Unconnected Sockets Not Implemented

Yesterday when I tried to access my ASA 5520 box using ASDM, I got an error " Unconnected Sockets Not Implemented". Initially I thought It could be because of some ASDM access permission configured on ASA. But everything was fine with the configuration. I spent quite some time but didn't find any clue about how to fix this issue and what could be the possible cause.

Finally I downgraded my Java version because I knew that ASDM uses JRE and recently I upgraded my JRE. So after making downgrade I was able to access the ASDM. It seems like some JRE versions are not compatible with Latest ASDM version 6.x

Regards,
Deepak Arora

PIX - "sh block" command

I would like to thank Mr. Don Edelmon who shared this helpful information with us. DON is a Network Security Specialist working for xxxxx :-)

Anyways below is the information:

When the PIX boots, it copies the OS from Flash into RAM and runs the OS from RAM (just like routers
do). Next, the PIX copies the its startup configuration from Flash and places it into RAM.

Finally, the PIX carves out RAM to create the block pools. Once this is completed, the PIX is up and
running and need additional RAM only if the configuration increases in size. In addition, the PIX
stores the translation and connection entries in RAM. During normal operation, the free memory on
the PIX should change very little, if at all.

Typically, the only time you should run low on memory is if you are under attack and there are
hundreds of thousands of connections going through the PIX. You can check this by issuing the show
conn count command, which will display the current and
maximum number of connections through the PIX.

The 'show block' command will change during normal operation in the PIX...
For example... When a packet comes into a PIX's interface, it is placed on the input interface
queue, passed up to the OS, and placed in a block. For Ethernet packets, the 1550-byte blocks are
used; if the packet comes in on a 66 MHz Gigabit Ethernet card, the 16384-byte blocks are used. The
PIX determines whether the packet should be permitted or denied based on the Adaptive Security
Algorithm (ASA) and processes the packet through to the output queue on the outbound interface. If
the PIX is having trouble keeping up with the traffic load, the number of available 1550-byte blocks
(or 16384-byte blocks for 66 MHz GE) will hover close to 0 (as shown in the CNT column of the
command output). When the CNT column hits zero, the PIX attempts to allocate more blocks, up to a
maximum of 8192. If no more blocks are available, the PIX drops the packet.

The 256-byte blocks are mainly used for stateful failover messages. The active PIX generates and
sends packets to the standby PIX to update the translation and connection table. During periods of
bursty traffic where high rates of connections are created or torn down, the number of available
256-byte blocks may drop to 0. This indicates that one or more connections were not updated to the
standby PIX. This is generally acceptable, because the stateful failover protocol will catch the
missing xlate or connection the next time around. If the CNT column for 256-byte blocks stays at or
near 0 for extended periods of time, however, then the PIX is having trouble keeping the translation
and connection tables synchronized because of the number of connections per second that the PIX is
processing. If this happens consistently, you should consider upgrading the PIX to a faster model.
Syslog messages sent out from the PIX also use the 256-byte blocks, but they are generally not
released in such quantity to cause a depletion of the 256-byte block pool. If the CNT column shows
that the number of 256-byte blocks is near 0, ensure that you are not logging at Debugging (level 7)
to the syslog server. This is indicated by the logging trap line in the PIX configuration. It is
recommended to set logging at Notification (level 5) or lower, unless you require additional
information for debugging purposes.

Example
pixfirewall# show blocks
SIZE MAX LOW CNT
4 1600 1597 1600
80 400 399 400
256 500 495 499
1550 1444 1170 1188
16384 2048 1532 1538

The following describes the columns in the show blocks output.
Column Description
SIZE = The size, in bytes, of the block pool.
MAX = The maximum number of blocks available for the specified byte block pool. Note that the
maximum number of blocks are carved out of memory at bootup. Typically, the maximum number of blocks
does not change. The exception is for the 256- and 1550-byte blocks, where the PIX can dynamically
create more when needed, up to a maximum of 8192.
LOW = The low water mark. This is the lowest number of this size blocks
available since the PIX was powered up, or since the last clearing of the
blocks (with the clear blocks command).
CNT = The current number of blocks available for that specific size block
pool.
The following describes the rows in the show blocks output.

Here is the documentation on the Interfaces and Memory blocks I mentioned to you.
Memory blocks.

Even though this is a little garbled you just need to know what the block size is used for.
Block Size Used to MAX Created at Startup
4 Duplicating existing blocks in DNS, isakmp, url-filtering, uauth, h323, tftp, and TCP
Modules1600
80 Used in TCP Intercept to generate an ACK packet, fover hello messages. 400400
256 Stateful Failover, Syslog, TCP module
1550 Ethernet Packets, buffering url filtered packets.8192400
1552 QoS Metrics 40960
2560 IKE Messages 81920
4096 QoS Metrics 2000
8192 QoS Metrics 1500
16384 Only used for the Livengood (i82543 ) Gig Ethernet cards 92160
65536 QoS Metrics160