protect management interface of css

[hvd]

Hello,

We've about 9 css of diferent types: 11050, 11501 & 11503. They're all connected with the management interface to a so called management vlan with our hp openview in it 10.0.0.x.

Some of our css are connected to our DMZ (hosting a website), and the default route on them for everything points the DMZ direction, more specific towards our pix firewall.

Everything is working fine, but we're facing a security issue here. Our pix logs show some spoofing errors coming from our css's. Looks like the css are sending packets with source 10.0.0.<their management ip> towards our pix.

It looks like (I've simulated this) when I send any kind of packet from our intranet (not on the management network) to the management interface of one of the css's they tend to respond to it by sending a return packet via the default configured way to our pix (since the originator is not on the management lan). This happens for icmp, telnet, rcp, ... I thought the management interface was completly independant of the css' operation but now it looks it isn't.

Did I forget to configure something, or is this normal behaviour. According to manuals there's no way to put an acl on the management interface. And trying to prevent this kind of behaviour via acl on our ouside (DMZ) interface doesn't seem to work. Suggestion is to isolate a port and use that one for management - I'm not keen on such an idea.

btw. version we're running 7.20.05. Please don't tell me to upgrade or change because there are a lot of buggy versions out (http-keepalive with asp pages.) and I don't have the courage to try them all out.

Looking forward to your replies.

Regards

Hans

[jfoerster]

Hi Hans

if you send anything from outside 10.0.0.x/24 (I assume 10.0.0.x/24 is you management VLAN) than the normal routing table is used except you have a configured (compare to http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_administration_guide_chapter09186a0080176be6.html#wp1141873 Step 7). If the routing of the CSS does not know where to direct your "management" traffic to it uses the default route.

i heard some rumors that this is not working well but this is only rumor and nothing approved. Looking at the documentation this should work.

Regards,

Joerg

[hvd]

Thanks Joerg,

I think this might do, but my css doesn't seem to accept this command. Probably I have to upgrad web-ns to a more recent version. Any idea from which version on this will work keeping in mind the http-keepalive with asp pages still has to work.

The problem is not that I want remotly manage the devic but that when someone accidently hits the management ip address of the css, the answer is send back via the public interface bouncing to the pix's anti-spoofing mechanism. I would like to prevent this accidental hit on the ccs by anyone, and certainly prevent having a return packet. The only solution for the moment I see is to block all trafic to the management interface of the css on our intranet backbone router since we mamange the css from a machine in that management segment.

Hans

[jfoerster]

hi Hans,

sorry for the bad news.

The CSS 1150x supports this command with 7.30 (see http://www.cisco.com/application/pdf/en/us/guest/products/ps792/c1051/ccmigration_09186a00801ee911.pdf.

The CSS11000 with 6.1 (see my first link) there I found the command in the command reference files.

regards,

Joerg