Changed IP address, and now no SSH!

[iterrell]

Having a strange problem with a version 4.1 sensor... It was functioning normally. Then I changed its IP address. This also included changing netmask, gateway, access list, etc, as well as regenerating TLS and SSH keys.

Now the sensor can ping out to its CiscoWorks server (on a different subnet), and the CW server can ping back. But it doesn't report events and I can't use SSH to get into it. Telnet to port 22 connects, waits a few seconds, and then disconnects silently. I don't have the regular unencrypted telnet service enabled. Console access works, though, and the network settings look okay.

Could someone please tell me what I might be missing, or point me to the right documentation?

Thanks!

[brhamon · Accepted solution]

There appears to be an access list problem. One way to verify this with the service account would be to rename /etc/hosts.deny (to something else) and then try to connect. (Do not run the sensor in production without /etc/hosts.deny! This is just a quick way to disable the enforcement of the access lists to determine if this is the source of the problem.)

The IDS 4.x sensors use TCP wrappers to enforce the access lists, which means that you will always be able to ping to/from a non-allowed address. The TCP three-way handshake is likewise always allowed. Only after the TCP socket connects will it check the remote address against your access list entries. If the address is not allowed, the TCP socket is silently closed.

Another data point here would be to check if you have access to the web server. From an allowed host, run a web browser and go to the following URL:

https://10.1.2.3

where, "10.1.2.3" is the IP address of the sensor.

If we can access the web server but not the SSH server, that would indicate a different problem than access lists.

[iterrell]

You're right.

When I ran ipconfig on the ciscoworks server to verify its settings, I discovered that it had two active network interfaces. Adding an access rule for the "wrong" address caused SSH to start working.

I removed the new rule from the sensor's access list and checked the CW server's routing table. There was no explicit route for the sensor's new subnet. Thus it was trying to route network traffic there through the wrong interface. Next it went through a firewall, which intelligently routed back to the right place. But with an unexpected source address.

So on the CW server I added a persistent route for the new subnet... Now SSH works again, with no net change to the sensor config.

Thanks, that helped a lot!