IP infected with Conficker A or Conficker B botnet as stated by spamhaus.org

[Dyop_Geop]

We have a fortigate 100D setup. All LAN Traffic are with Antivirus, Webfilter, App Ctrl, IPS, email filter enabled. The public ip address is always being listed in spamhaus.org.

" X.X.X.20 is listed in the XBL, because it appears in: CBL"

" IP Address X.X.X.20 is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet. It was last detected at 2014-06-16 00:00 GMT (+/- 30 minutes), approximately 2 hours ago. It has been relisted following a previous removal at 2014-06-13 14:18 GMT (2 days, 12 hours, 2 minutes ago) This IP is infected (or NATting for a computer that is infected) with the Conficker A or Conficker B botnet."

For some reason the antivirus/IPS are not detecting the conficker virus. What else to do please?

[Dyop_Geop]

So there are 194 botnet listed. I have to block them all? Even though we' re not sure that all these botnets are related to the conficker botnet?

[ede_pfau]

OK, build 4429 actually is 5.0.7 with the heartbleed fix. This is indeed the most recent firmware version for the 100D. And yes, I would block all botnets. No need to spare any one of them! There are by definition no good botnets. The impact on CPU load is negligible.

[Dyop_Geop]

alright. done this. I hope this will work. will continue to monitor their public ip address in spamhaus.org if it will be blocked.

[ede_pfau]

In this case, I am talking about a hotel that I am monitoring. No internal DNS but plenty ISP based DNS from all over the world in use. I have to allow ' all' as DNS but only with an AppControl sensor on it.

[Dipen]

CBL doesn' t do a virus scan so it is not necessary that your Computer is indeed infected with virus. The IP addresses you are referring to is this a Static [1 to 1] IP or your gateway IP? In this case AV UTM or Application UTM shouldn' t be of much help. Please apply an Anti Spam policy as well.

[Nihas]

I will suggest you to have a look in to the internal machines than concentrating more on firewall.! Other option is that you have to restrict the communications for limited services instead of " any" . Through that way yo will get more control over the network. I had the similar issue with Zeus Botnet , and luckly they have given the destination IP' Addresses. But when I check my analyzer all traffic to the particular destination was blocked. But simply I could find the source machines and I have done a deep inspection helped me to fix the issue..! Now my public IP is green every where..

[MVIOX]

I am pretty sure that you have already done so, but sometimes it is the small things that count. Turn on all log reporting for each of your firewall rules. Once this has been done, you can sift through and see if there are some packets that are being forwarded or even blocked. This will give you a better understanding of exactly what your UTM is doing or not. It will also give you ideas on how to implement new rules and create a more efficient FW. I' m glad to see you are green again! Trust me, I understand the headache of managing a hotel environment. Just remember, your network = Your rules.

[FortiAdam]

Don' t forget that when you are using proxy based AV and botnet detection it will only inspect the ports that you tell it to. Check your proxy options to see if you are looking for HTTP on just port 80 or on all ports. If your firewall policy allows traffic to exit with any destination port you should also be using your proxy options to inspect any port for HTTP. If you are making botnet connections via HTTP on port 40923 the AV proxy could care less and wont even look at it unless you configure it to do so.

[Sean_Toomey_FTNT]

These are all good points. You will want to do the following: 1. Under Proxy Options, change the protocol inspection ports to " Any" for each listing 2. Enable block botnet connections in AV 3. Block FortiGuard categories under Security Risk, and also enable " Rate URLs by Domain and IP Address" 4. Block Botnet applications in App Control (OPTIONAL because there are several considerations to doing so - enable deep SSL inspection). The reason behind these recommendations is that it requires a layered approach to solve the problem. 1. You want to inspect the various protocols on any port because it is easy to run HTTP on a different port 2. Blocking Botnet under AV takes care of signature based bots 3. Blocking " Security Risk" means any site marked malicious by FortiGuard is automatically blocked 4. Blocking Botnet under App Control takes care of behavior based bots It is becoming increasingly common for attacks to run over SSL enabled protocols as well, so for absolute best coverage you will want to enable this as well. However this is not something you should do lightly. SSL Decryption takes planning and some trial and error to accomplish - that is not a FortiGate thing but rather the same process is needed for ANY product that does SSL decryption. There is so much to cover on this topic I won' t do so here in this post, only to say please read carefully the documentation on SSL Decryption before you enable it. Don' t just turn it on. Once you go through the process and enable it, however, you will then have a layer of protection that the majority of network security installations are not able to block, and you will make yourself safer against things like zero-day attacks. If you do all these things and you find that Conflicker is getting by the Fortigate, please do a packet capture of the issue in action, and then open a TAC case so we can review this for you and resolve your problem, because it should be able to block it. Make sure you give a backup of the FortiGate config as well as a diag debug report / exe tac report when you do so. Hope this helps. Thanks!