We had a problem where a device on the internal network was infected with sqlnet virus. It was constantly creating connections to external hosts and has caused the number of connections and CPU on the FWSM to increased to almost 100%... almost halting the FWSM process. The infected host 10.120.119.10 is on the inside (high security) of the FWSM and the hosts it was trying to establish connections to were on the outside (low security) of the FWSM. See sh conn below.
How do we prevent this happening on the FWSM if a similar incident happens again? Can setting max connection and/or the embryonic limit help?
Any help is much appreciated.
999849 in use, 999902 most used
Network Processor 1 connections
UDP out 22.214.171.124:1434 in 10.120.119.10:1244 idle 0:01:59 Bytes 36
UDP out 126.96.36.199:1434 in 10.120.119.10:1244 idle 0:01:31 Bytes 36
UDP out 188.8.131.52:1434 in 10.120.119.10:1244 idle 0:00:03 Bytes 36
UDP out 184.108.40.206:1434 in 10.120.119.10:1244 idle 0:01:59 Bytes 36
CPU utilization for 5 seconds = 96%; 1 minute: 55%; 5 minutes: 64%
In FWSM, the default fixup protocol sqlnet is 1521 (UDP). Oracle registered TCP and UDP port 66 with IANA (Internet Assigned Numbers Authority). I am not sure whether you can change it to fixup protocol 66 (depends..).
However, you connection status shows that the virus is targetting UDP 1434 to open/establish multiple connections to external network. So, you might need to block this port using ACL and drop the UDP 1434. Bind the ACL to the FWSM interface where the device is located. But this might not be an ideal solution if the virus uses multiple or random ports.
And if the source port is fixed on 1244, block this port as well.
access-list inside deny udp host any eq 1434
Correct me is I am wrong, I think the embryonic level is only applicable for TCP.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...