If you take a look in your SourceFire dashboard, and there is no data shown on the malware threat section like so;
Solution
The message is pretty descriptive, and it’s telling you exactly what you need to do. Now I’m making the assumption that you have added a valid AMP / Malware licence like so;
Policies > Access Control > Edit your access control policy > Then Edit the file policy.
Add in “Block Malware with Reset”.
You can test the rule is applying correctly by trying to download the eicar test infected files;
Then after a short time, you should start to see the malware threats window start to show some data.
Related Articles, References, Credits, or External Links
Usually when you Telnet to an Exchange server it gives you a 220 message followed by the “Banner” of the Exchange server, a little like:
220 Servername.domainname.com Microsoft ESMTP Mail service ready at (Date/Time)
The reason why you see this happening is, there is something in between you and the Exchange server that’s stopping/filtering ESMTP traffic.
In this clients case I knew straight away what that was, (because I’d seen it before,) Cisco firewalls (PIX and ASA) that have SMTP/ESMTP inspection enabled cause this to happen.
Disable ESMTP Inspection on Cisco ASA Via command line
Note: If you send mail via TLSDO NOT do this. (see here).
2. Usually you will find ESMTP inspection enabled on the “global_policy” in the class called “inspection_default”, below are the commands to disable this feature.
While putting in a New Exchange 2010 server today, I test moved a mailbox to this new site, and could not get mail to flow to the Exchange 2010 server at the clients main site.
451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host , but that did not succeed. Either there are no alternative hosts, or delivery failed to all alternative hosts.
Mail flowed from the main site to this new site, and internal mail at the new site was fine, but any mail destined for the main site, or going external (because the main site has the only server that can use the Exchange organization send connector) would fail with this error.
Solution
I did a lot of trawling to try and find the answer to this, and discovered lots of reasons for this to happen, so rather than just posting what fixed mine, from the most popular to the most obscure try these in order, and attempt to send mail after each step.
Note: Any change on an Exchange Server’s Receive Connectors should be followed by you restarting the Microsoft Exchange Transport Service (on the server you made the change on) before you try again.
1. On the server you are trying to send TO, check the properties of the Default receive connector and ensure ‘Exchange Server authentication’ is selected.
2. On the server you are trying to send TO, If you have a connector configured to ‘relay’ mail, make sure that the server(s) or network specified DOES NOT include the IP address of the server you cannot send FROM. Also Make sure on the authentication tab ‘Exchange Server authentication’ is NOT selected.
3. If you have Cisco PIX Firewalls between these two mail servers (running version 6 or earlier) make sure smtp fixup is disabled.
[box]
Petes-PIX>
Petes-PIX> enable
Password: *******
Petes-PIX# configure terminal
Petes-PIX(config)# no fixup protocol smtp 25
Petes-PIX(config)# write mem
Building configuration...
Cryptochecksum: f59a9bd3 3129b8bc 474b2415 52f2db0f
1049 bytes copied in 0.430 secs
[OK]
[/box]
4. If you have Cisco ASA Firewalls between these two mail servers, then remove esmtp from the default inspection map.
At this point I admitted defeat and picked up the phone and called Microsoft. One of their support engineers looked at the connectors and settings, and tested the DNS, had me create a new connector, still mail refused to flow. He did however get me pointed in the right direction. When attempting to Telnet to the Exchange server on the main site this is what we saw;
This is what we should be seeing;
Eureka!
I put all the firewalls in, so I know how they are configured, and I know this client has a CSC module in the ASA 5510 at the mail site, I managed to get the output above by rebooting that module, as soon as it was back online we reverted to the short list again. Also while the CSC was rebooting all the mails stuck on the outbound queue cleared.
Enabling CSC Bypass for a Remote Mail Server
Note: Your class-maps, and access-lists may have different names but this should point you in the right direction.
1. Connect to the ASA, view the policy-maps in use.
[box]
Petes-ASA# show run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
inspect pptp
inspect ip-options
class global-class <<<<< Here we go
csc fail-open <<<< This is the one we are looking for
!
Petes-ASA#
[/box]
2. We can see the class-map the CSC is using is called ‘global-class’, let’s take look at that.
[box]
Petes-ASA# show run class-map global-class
!
class-map global-class
match access-list global_mpc <<<<Here's how its being applied
!
[/box]
3. Now we know that’s being applied with an access-list called global_mpc, let’s see what that’s doing.
[box]
Petes-ASA# show run access-list global_mpc
access-list global_mpc extended deny ip host 10.1.0.253 any
access-list global_mpc extended permit tcp any any object-group DM_INLINE_TCP_1
Petes-ASA#
[/box]
Note: Remember permit means inspect and deny means don’t inspect, you can see mine’s set not to scan the CSC update traffic because that’s good practice;
4. So I just need to add in the IP of the Exchange server I cannot send from to make its traffic bypass the CSC Module. Remember to put it at the top so it gets processed before the permit or it will get ignored.
[box]
Petes-ASA# configure terminal
Petes-ASA(config)# access-list global_mpc line 1 extended deny ip host 10.3.0.2 any
The CSC module when it’s installed in your firewall and running, by default scans all traffic in and out including all its own updates and web traffic, this can cause quite a performance hit, to stop this happening exempt the CSC modules traffic from being scanned.
NOTE: your access-lists and port groups may well have different names, so I’ll list all the commands to chase them though the firewall’s running config.
Before you start you will need to know the IP address of your CSC module, in the following example it is 10.1.0.253
2. Show the firewall’s policy map “show run policy-map”.
[box]
Petes-ASA1# show run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
class global-class <<< This is what we are looking for!!
csc fail-open
!
Petes-ASA#
[/box]
3. Show the firewall’s class maps with “show run class-map”, to see what “global-class” is doing.
[box]
Petes-ASA# show run class-map
!
class-map global-class
match access-list global_mpc
class-map inspection_default
match default-inspection-traffic
!
Petes-ASA#
[/box]
4. Now we know “global-class” is matching all traffic in a access-list called “global_mpc” to see what that’s doing issue a “show run access-list global_mpc” command.
[box]
Petes-ASA#
Petes-ASA# show run access-list global_mpc
access-list global_mpc extended permit tcp any any object-group DM_INLINE_TCP_1
Petes-ASA#
[/box]
5. To see what protocols the CSC is scanning issue a “show run object-group id DM_INLINE_TCP_1” command.
[box]
Petes-ASA# show run object-group id DM_INLINE_TCP_1
object-group service DM_INLINE_TCP_1 tcp
port-object eq ftp
port-object eq www
port-object eq pop3
port-object eq smtp
Petes-ASA#
[/box]
6. Now we are sure that’s our CSC scanning 🙂 we need to exclude the CSC from the access list.
[box]
Petes-ASA# configure terminal
Petes-ASA(config)# access-list global_mpc line 1 deny ip host 10.1.0.253 any
Petes-ASA(config)#
[/box]
7. To make sure look at the access-list again.
[box]
Petes-ASA(config)# show run access-list global_mpc
access-list global_mpc extended deny ip host 10.1.0.253 any
access-list global_mpc extended permit tcp any any object-group DM_INLINE_TCP_1
Petes-ASA(config)#
[/box]
At this point you can check web traffic is flowing with a “sh conn | i x” command (Note that’s a pipe symbol).
Check Traffic is Bypassing the Cisco CSC Module
You can do this with a simple packet-tracer command, in the SSM-DIVERT section look for deny=true.
[box]
Petes-ASA(config)#packet-tracer input inside tcp 10.1.0.253 www 123.123.123.123 www-----------Output Removed to Save Space-----------
Phase: 7
Type: SSM-DIVERT
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xadccb148, priority=51, domain=ssm-isvw, deny=true
hits=1, user_data=0xae658708, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, tag=0 dscp=0x0
input_ifc=inside, output_ifc=any
-----------Output Removed to Save Space-----------
[/box]
Related Articles, References, Credits, or External Links
Yeah, it’s funny because it’s true! The article title might not sound like the most professional approach, but when the ‘Well it’s not working now’ finger gets pointed at the ‘firewall guy/girl’, they need to ascertain two things;
1. Is the problem actually the firewall, if not then help the frustrated party track down the actual problem.
2. If your problem IS the firewall, fix it!
I’m just coming out of a major network greenfield site build, all the individual technologies that have been getting planned and designed are now starting to come online and require comms though the firewall solution that I’ve been working on. So my days are pretty much filled with conversations like this;
Consultant/Engineer: Pete I need some ports opening on the firewall.
Me: OK let me know the IP addresses, host-names, ports, protocols etc, and I’ll open them for you. I then open the requested ports/protocols. Consultant/Engineer: You know those ports you opened? They don’t work.
At this point one of the following has occurred;
1. I’ve made an error, (it happens I’m human), I might have entered the wrong information, or not applied an ACL, or put the rule on the wrong firewall. Always assume you have done something wrong, until you are 100% sure that’s not the case.
2. The person who asked for traffic to be allowed, asked for the wrong thing, either they didn’t RTFM, or someone has given them the wrong IP addresses, or because they are human too, they’ve made a mistake.
3. The traffics not even getting to the firewall, because either it’s getting blocked before it gets to you, or there is a routing problem stopping the traffic hitting the firewall. (Remember routing works by Unicorns and Magic, so routing people are not to be trusted!)
4. The traffic needs some kind of special inspection to work through the firewall i.e. ICMP, FTP, or PPTP etc.
5. Some annoying bug in the ASA code is stopping you, which either requires a lot of Internet and forum searching or a call to TAC to confirm.
If I’ve forgotten another reason – feel free to contact me. (Link at the bottom of the page).
Solution
Step 1: Make sure you are not blocking the Traffic
Packet tracer is your friend! Use it to simulate traffic going though the firewall, and the firewall will tell you what it will do with that traffic. I prefer to use command line, but you can also run packet tracer graphically in the ASDM.
Xml: (Optional) Displays the trace capture in XML format.
Example
Below I’m checking that an internal host (10.254.254.5) can get access to a public web server (123.123.123.123) via http (TCP port 80). Note: As mentioned above I just picked a random source port (1024).
OK, so if packet-tracer shows the firewall is not blocking the traffic. Then either there’s other ports we don’t know about that may need opening, or the traffic is not getting to the firewall. Normally at this point I’d test to see if the traffic is getting to the firewall. To do that I would do a packet capture.
To demonstrate, below someone has requested that we open https from Server A on our LAN, to an Internet server Server B.
Above the traffic is not getting to the firewall as there’s a problem between Server A and the Firewall, either something is blocking the traffic downstream, or Server A cannot route traffic to the firewall.
Below we can see traffic hitting the firewall, in fact 10.0.0.1 sends out three packets on TCP port 443 (https). What we CANNOT SEE is any traffic coming back, in this case Server B is not replying to us, either its down or it cannot route traffic back to us.
Now the port(s) we want to allow, we can see are actually working, so if theres still a problem, theres probably another port / protocol that’s being blocked. To find out we need to enable logging and see if any packets are being denied.
Try the connection again, then view the log, (here I’m filtering it on 10.0.0.1, as the log can be quite sizable);
[box]Petes-ASA(config)# show logg | incl 10.0.0.1
%ASA-7-609001: Built local-host inside:10.0.0.1
%ASA-6-302013: Built outbound TCP connection 15 for outside:123.123.123.123/443 (123.123.123.123/443) to inside:10.0.0.1/1070 (10.0.0.1/1070) %ASA-4-106023: Deny tcp src inside:10.0.0.1/1073 dst outside:123.123.123.123/21 by access-group “outbound” [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.0.0.1/1073 dst outside:123.123.123.123/21 by access-group “outbound” [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.0.0.1/1073 dst outside:123.123.123.123/21 by access-group “outbound” [0x0, 0x0]
%ASA-6-302014: Teardown TCP connection 15 for outside:123.123.123.123/443 to inside:10.0.0.1/1070 duration 0:00:30 bytes 1420 TCP FINs
%ASA-7-609002: Teardown local-host inside:10.0.0.1 duration 0:00:30
Petes-ASA(config)# [/box]
As we can see traffic is being denied and it’s on TCP port 21 (That’s FTP if your interested). So let’s open that port, and try again;
[box]Petes-ASA(config)# show logg | incl 10.0.0.1
%ASA-5-111008: User ‘enable_15’ executed the ‘access-list outbound extended permit tcp host 10.0.0.1 host 123.123.123.123 eq 21’ command.
%ASA-5-111010: User ‘enable_15’, running ‘CLI’ from IP 0.0.0.0, executed ‘access-list outbound extended permit tcp host 10.0.0.1 host 123.123.123.123 eq 21’
%ASA-7-609001: Built local-host inside:10.0.0.1
%ASA-6-302013: Built outbound TCP connection 16 for outside:123.123.123.123/443 (123.123.123.123/443) to inside:10.0.0.1/1077 (10.0.0.1/1077)
%ASA-6-302013: Built outbound TCP connection 17 for outside:123.123.123.123/21 (123.123.123.123/21) to inside:10.0.0.1/1080 (10.0.0.1/1080)
%ASA-6-302014: Teardown TCP connection 16 for outside:123.123.123.123/443 to inside:10.0.0.1/1077 duration 0:00:30 bytes 1420 TCP FINs
Petes-ASA(config)# [/box]
And we are working!
If we have got this far and you are still not working, then check the traffic you are trying to send does not need any special inspection enabling. Or the port number you are using may have been reserved for a particular type of traffic (like this).
Failing that, upgrade the ASA, then open a TAC call.
Related Articles, References, Credits, or External Links
