Need Help with an Cisco Access List..

[Santa]

ip access-list extended block113
deny tcp any eq ident any eq ident
permit tcp 10.0.0.0 0.0.0.255 eq telnet any
<explicit deny>

what does this tell you?

doesn't this mean anything with a source address of 10.0.0.0/24 going to port 23 going to anywhere on any port is permitted?

Keep knocking my telnet session out trying to see how the packets discarded for incoming port 113 requests.

When doing..

ip access-list extended block113
deny tcp any eq ident any eq ident
permit tcp any any
<explicit deny>

it doesn't seem to work right in blocking the port request for 113.

I was under the impression that Access lists are checked top to bottom. Or is this only on "access-list" not "ip access-lists"?

 

[spidey07]

ip access-list extended block113-----------------you are creating an extended named list called "block113"
deny tcp any eq ident any eq ident--------------deny all packets whose source AND destination port is ident, that is kind of funny, generally the source port of the requesting station is chosen semi-randomly. The destination port is the service being called on the receipient.
permit tcp 10.0.0.0 0.0.0.255 eq telnet any----allow 10.0.0.x whose source port is telnet. kind of funny looking

ACLs are treated from top down with the implicit deny all at the end. It also matters which direction, is this applied inbound or outbound and on which interface?

 

[Santa]

So I should be editing it to read

ip access-list extended block113
deny tcp any any eq ident
permit tcp 10.0.0.0 0.0.0.255 any eq 23
<implicit deny>

This is applied on a FastEthernet0/0 on incoming or "in" which is on 10.0.0.253

So basically the randomly selected nature of the telnet is probably what is missing and why it causes a lockout from the server.

I will give that a shot to see if I don't lose connectivity.

 

[spidey07]

All TCP communications start with a semi-random source port to a service destination port (80 for web, 25 for smtp etc). Here's a little diagram:

compA-----F0/0-ROUTER-S0/1-----compB

compA wants to talk to a service on compB (web). Packets from A to B will have a pseudo random source port and destination port 80. The return packets from B to A will have a source port of 80 and a destination port equal to the source port above. If you wanted to block web traffic from A to B your ACL would resemble

access-list 101 deny tcp any any eq web

That says block any packet from any IP to any IP whose destination port is www (80). You could apply this inbound on F0/0 or outbound on S0/1. I believe the rule of thumb is apply Standard ACLs closest to the destination and extended ones closest to the source.

hope that makes sense

 

[Santa]

It does make sense.. I forgot about the randomization on the host end.

I didn't hear about the Standard ACL being placed closer to the destination but I did hear about ACLs in general being closest or filter as close to the source as possible.

Is applying the ACL on the outbound on the Serial0/0 just backup in case they somehow slip through the fastethernet0/0 so they won't go further into the WAN?

 

[spidey07]

It really depends on what you're trying to do. Once a packet hits a deny it is dropped.

 

[Santa]

Well isn't that spiffy.. I just configured it right so that a port can be open but only those in the Access List can get to it.

Now the question is.. do you handle authentication at Layer 3 (router with Access List) or do you allow it to pass all the way into Layer 7 and have it handled by the application.

In other words if you ran an FTP server would it be best to just let the FTP server handle user name and password (and perhaps IP masking) or would adding an ACL in front of the router be better way to weed out traffic so you don't have someone hacking at the ftp server.

Obviously this has nothing to do with public FTP server that should be accessed in anonymous mode but those who have anonymous turned off.

Is the overhead on the router with the additional packet checks too much for it to handle?

Is this even a standard practice for anyone?

 

[dbx]

youd want to put the acl on the out of s0 if there were other routes connected to the router, and you wanted to allow that traffic to pass to them, and only be denied to that specific subnet, connected to the interface you applied the acl to. applying it to the in of the interface of the subnet you are creating the deny statement for would block the traffic from entering the router and doing so would prevent it from going anywhere, from any of that routers interfaces.

 

[dbx]

santa: it all depends on how much security you want. if you are fine with anyone being able to try and login then no need to do anything further. if youre not then you can tighten the noose with your acl's.

 

[spidey07]

<< Is the overhead on the router with the additional packet checks too much for it to handle?

Is this even a standard practice for anyone? >>



Overhead on the router?....it depends on the router and traffic loads.

Standard practice?...it depends on security policy and the precise goals of the system.

sorry, this doesn't help much but like so many decisions in networking....it depends. I've spent countless design sessions (dozens of hours on these two topics alone) on your first point alone that there is no definate answer. Same with the second.

With a diagram of your network and what your goals/requirements are relating to security/performance/usability I can offer some input.

jeez...was I worthless in this post or what.

 

[Garion]

I actually despise access lists, but I do seem to recall that you might want to have an ESTABLISHED on the end of your Telnet ACL. Sound right?

- G

 

[Santa]

I looked into the established but I think established is more for when you are trying to access outbound (the router allowing certain port destination out) but you have no idea what the port or source will be replying so established will allow the "established" connection initiated from inside to come back from the outside.

Since I am connecting TO the router instead of through it I won't need the established.

If I am wrong in this let me know.. when reading up on established connections it seemed pretty insecure way of doing an access list though since you really don't control how the traffic comes back or whether the traffic is clean and doesn't have any piggy back data on it.

Oh and Spidey.. your rambling is definatly not worthless I think you just reconfirmed my thoughts on it and it is as I thought to be a case by case situation. Guess I was hoping for a magic answer

The example of an FTP is not quite the application I had in mind, perhaps an access list to restrict telnet to my edge routers such as the internet router. This way I could lock down who has access to even see that it is a router sitting outside the firewall by port scanning a block of IP ranges.

This little excersise helped me understand how the Access Lists drop the packets.. it treats it as if the device never recieved it at all thus the client has no knowledge that their packets were checked and dropped.

I need to find out if this works on SYN and FIN type scans also though but if not I think there are flags to indicate these type of packets too.

 

[FFC]

Garion - Why do you despise them? Apart from arcane sytax (which I hate as well) I've found them to be one of the things that cisco got very right in IOS, they're useful for everything, so much so that other router vendors haven't bettered it.