Alcatel Unleashed

Hey Silvio,

good to see that you are back ...

@Mark:
I agree with Silvios statement but you need to make sure that you don't cut of your management access with the following command.

silvio wrote: -> no ip service all

It would be safer to go through the services to deny them (I already explained that in this thread).

-benny

I looked through both of your posts and as always it was a stupid mistake on my part. I was sure I did not need the Switch group because we only have a single ip address associated to each switch. Yesterday I got a call and one of our obscure networks was having problems. All I had to do was look at the configuration snapshot and I would have seen it but I am so used to limiting the command with qos or ip or something of the sort that I hardly ever look at the whole thing. I changed the ip address to the group switch and it is fine. I turned on all the other ip services just to see what would happen and now we have some trying to access us over ftp. I am tempted to shut down the other ip services through acls so I can see when people are trying to access the switch. Thank you for the help I hate it when I do something silly that causes the problem but it was a great study for me on ACLs and a review of QOS.

Thanks for the help Benny and Silvio.
Sincerely
Mark

Please take a second look at this I am still getting ssh connections for Ip address other than 192.168.254.4 (I changed the ip)
-> show configuration snapshot qos
! QOS :
policy port group Inside 1/15-25
policy port group OutSide 1/1
policy port group PGroup 1/25
policy condition BandWidthRestrict destination port group PGroup
policy condition NoSSHCond destination network group Switch ip protocol 6 destination ip port 22
policy condition NoUDPSSHCond destination network group Switch ip protocol 17 destination ip port 22
policy condition SSHCond source ip 192.168.254.4 ip protocol 6 destination ip port 22
policy action Allow
policy action Deny disposition drop
policy action MaxBandWidth maximum bandwidth 1.40M
policy rule AllowTCPSSH precedence 5 condition SSHCond action Allow
policy rule MaxBandRule condition BandWidthRestrict action MaxBandWidth
policy rule BlockSSH condition NoSSHCond action Deny
policy rule BlockUDPSSH condition NoUDPSSHCond action Deny
qos apply
Internet Gateway-> show active policy rule
Policy From Prec Enab Act Refl Log Save Matches
AllowTCPSSH cli 5 Yes Yes No No Yes 425
( L3): SSHCond -> Allow

MaxBandRule cli 0 Yes Yes No No Yes 63958
(L2/3): BandWidthRestrict -> MaxBandWidth

BlockSSH cli 0 Yes Yes No No Yes 260
( L3): NoSSHCond -> Deny

BlockUDPSSH cli 0 Yes Yes No No Yes 0
( L3): NoUDPSSHCond -> Deny

Thanks
Mark

Hi,
now I see matched traffic for the deny rule BlockSSH. So something is working....

1) is every ssh-traffic to the switch from other than 192.168.254.4 permitted? or is it blocked sometimes?
2) have you checked the matched entries (with show active police rule) before and after the access? Which rule has matched for this traffic?
regards Silvio

First I would recommend to clear the counters, so that we have a fresh overview. It might be that your traffic gets classified by the bandwitdth rule first and therefore is allowed to reach the service.

Just to make sure that this is not the case I recommend to give rule "BlockSSH" a precedence of 4 (so it comes right after the "allow your admin computer" rule).

-benny

Silvio-
1. All ssh to the switch should be blocked except the one specific address.
2. It appears that no rule is effected but I was not looking at the Max bandwidth rule. I will try benny's suggestion.

Benny
What you recomend makes sense. A single IP is using the max bandwidth rule and I noticed a reduction in SSH connections after I setup the SSH rules. If they are trying to access all my ips including the one in the MaxBandRule it would see the rule first. I will make the change. I will not know if it works for a little while. I will check back in.

Thanks both of you
Mark

No change. It looks like the connections are coming through the rule that only allow source address of 192.168.254.4

Below is part of the swlog. Maybe I am reading it wrong.

SUN JAN 17 13:37:38 2010 SSH info Session 15, Session Deleted
SUN JAN 17 13:40:43 2010 SSH info Session 16 New SSH Connection from 200.163.167.170 port 43172
SUN JAN 17 13:41:15 2010 SSH info Session 16, Session Deleted
SUN JAN 17 13:43:27 2010 SSH info Session 17 New SSH Connection from 12.2.202.132 port 47964
SUN JAN 17 13:43:58 2010 SSH info Session 17, Session Deleted
SUN JAN 17 13:50:02 2010 SSH info Session 18 New SSH Connection from 193.147.87.241 port 1036
SUN JAN 17 13:50:34 2010 SSH info Session 18, Session Deleted
SUN JAN 17 13:55:30 2010 SSH info Session 19 New SSH Connection from 192.168.254.4 port 59408
SUN JAN 17 13:57:41 2010 SSH info Session 20 New SSH Connection from 218.83.164.35 port 54840
SUN JAN 17 13:57:55 2010 SSH info Session 21 New SSH Connection from 79.29.84.4 port 4366
SUN JAN 17 13:58:13 2010 SSH info Session 20, Session Deleted
SUN JAN 17 13:58:27 2010 SSH info Session 21, Session Deleted
SUN JAN 17 14:02:26 2010 SSH info Session 19, Session Deleted


You can see where I log in. It looks like through the show active policy rule that the illegal address are coming through the rule that alllows ip 192.168.254.4. The more I think about it the more I get confused.

I am going to disable ssh for today and look at it again tomorrw.

Hi doctora,
my question was not what would you like to block - that is clear. My question was whether you have in your tests in all cases (from all source ip) ssh-connect to the switch. Or is the ssh-access from wrong ip's sometimes blocked? I assume this because I have seen matched traffic for the NoSSH-rule. For info: One year ago I had have trubble with dhcp-acl at a 6624 also. Normaly my rules worked fine - but sometimes they didn't work. ALU support says to me that the acl's will ignore if the switch has stress.
If your rules didn't match, try to use lesser conditions. For troubleshooting I have good experiences with this. You have to find out when the rule did match and when not.
And so you can also see whether the bandwith-rule will match before your wished rule.
Silvio

Mark,

Lets try to simplify the rules as Silvio already suggested.I recommend to remove the lines in orange. The line with green doesn't really make a difference. If this doesn't help I would propose to run a sniffer in the network to identify which kind of traffic creates those log messages. (Don't forget that you need to issue an qos apply to activate the changes.)

-benny

I will even remove the bandwidth rule. I will have to try this later. I have another issue and I shut down everything but console access. I will get down there in a couple hours. I appreciate the help and will update with what I find out. as far as Silvios question I am not sure I understand but in all testing I have done it has blocked all improper access and has always allowed access from where it should. This is why I wondered if there was another SSH port I should block.

On a side note. I added a rule to block the ability to ping the switch over night and it blocked over 22000 matches. I will remove that rule also.

It will not allow me to remove the protocol.

Mark