Skip to main content
Ian_W
Ian_W
New Member
November 11, 2024
Question

Reconnaissance block - why?

  • November 11, 2024
  • 3 replies
  • 2190 views

Hi,

We have a really simple rule e.g.

Source: private IPs

Destination: Some AWS URL objects which resolve the correct IP addresses (confirmed using dns dump from the FW)

Service: TCP/443

No SSL. No URL filtering.

 

We see the traffic in the logs on the firewall and by all accounts they should be permitted but we see they are being blocked:

 

Threat Action: Block

Threat name: Policy violation

Threat severity: Medium

Threat type: Reconnaissance

 

When I check the individual threat logs -> Antivirus, Intrusion prevention, Application control, web filter, filer filter, there is nothing in the logs. In addition we removed all UTM profiles to test and still had the same issue with the same threat block.

 

Fortigate 3301E running 7.0.15. 

Example trace (which doesn't show any block):

 

id=20085 trace_id=594 func=print_pkt_detail line=5867 msg="vd-XXX-PROD:0 received a packet(proto=6, 10.X.X.X.136:53314->3.5.245.179:443) tun_id=0.0.0.0 from portC1.999. flag [S], seq 2081025662, ack 0, win 64240"
id=20085 trace_id=594 func=init_ip_session_common line=6046 msg="allocate a new session-a254561b, tun_id=0.0.0.0"
id=20085 trace_id=594 func=vf_ip_route_input_common line=2611 msg="find a route: flag=00000000 gw-62.X.X.X via portC1.702"
id=20085 trace_id=594 func=get_new_addr line=1221 msg="find DNAT: IP-62.X.X.X, port-53314"
id=20085 trace_id=594 func=fw_forward_handler line=881 msg="Allowed by Policy-4: SNAT"
id=20085 trace_id=594 func=__ip_session_run_tuple line=3487 msg="SNAT 10.X.X.X->62.X.X.X:53314"
id=20085 trace_id=594 func=np6_hif_nturbo_build_vtag line=1090 msg="vtag->magic d153beef, vtag->coretag 314, vtag->vid 702
                vtag->sip[0] 3832be3e, vtag->sip[1] 0, vtag->sip[2] 0, vtag->sip[3] 0
                vtag->sport 17104, vtag->mtu 1500, vtag->flags 12, vtag->np6_flag 0xc2, skb->npu_flag=0xc0880"
id=20085 trace_id=599 func=print_pkt_detail line=5867 msg="vd-XXX-PROD:0 received a packet(proto=6, 10.X.X.X:53312->3.5.245.179:443) tun_id=0.0.0.0 from portC1.999. flag [S], seq 4214925707, ack 0, win 64240"
id=20085 trace_id=599 func=resolve_ip_tuple_fast line=5953 msg="Find an existing session, id-a25452a1, original direction"
id=20085 trace_id=599 func=npu_handle_session44 line=1183 msg="Trying to offloading session from portC1.999 to portC1.702, skb.npu_flag=00000000 ses.state=04013204 ses.npu_state=0x04003008"
id=20085 trace_id=599 func=fw_forward_dirty_handler line=410 msg="state=04013204, state2=00000000, npu_state=04003008"

 

-Source interface is correct

-Destination interface is correct

-Source NAT is correct

-Routing is correct

-Destination port is correct

 

Any ideas why we would be getting this block? Where it could possibly be configured?

3 replies

dingjerry_FTNT
Staff
dingjerry_FTNT
Staff
November 12, 2024

Hi Ian_W,

 

It seems that you are using a custom service called "TCP/443"?  If yes, I hope you defined the TCP port range correctly with 443.

 

Please show us the configuration of the custom service if you have it.

    dingjerry_FTNT
    Staff
    dingjerry_FTNT
    Staff
    November 12, 2024

    Hi @Ian_W ,

     

    You may apply the default service object "HTTPS" for a try.

      Ian_W
      Ian_WAuthor
      New Member
      November 12, 2024

      We are actually using the default service object "HTTPS" as you rightly suggested and it has been working fine for 18 months+ and we only (noticed) started having this issue about 10 days ago. No other changes were made to the firewall. Could it be something to do with any signature files that could have been downloaded and changed some default options do you think?

       

       

      Ian_W
      Ian_WAuthor
      New Member
      December 5, 2024

      No. After a few days the traffic was allowed so I think it was just a mismatch in DNS resolution between the client and the firewall. I'm going to update the DNS used by the firewall to match the DNS used by the client DNS resolvers. However we were unable to replicate the issue in this particular instance by the time we got a case open with Fortinet support (long story about inefficiency here in our company).

       

      The "reconnaissance" block I think is just a red herring. It's like the FortiAnalyzer trying to give a reason for the block using its built in SIEM intelligence. In version 7.2+ you can actually disable this in the FortiSOC, but in version 7.0 (which we are currently running) this is not visible.

      sjoshi
      Staff
      sjoshi
      Staff
      December 5, 2024

      Hi,

      From the debug flow I can see msg="Allowed by Policy-4: SNAT" so is the policy ID 4 the correct one?
      Also where do you see the below logs
      Threat Action: Block
      Threat name: Policy violation
      Threat severity: Medium
      Threat type: Reconnaissance

      Can you check forward traffic logs what it shows there.

      Also try doing a policy lookup
      https://community.fortinet.com/t5/FortiGate/Technical-Tip-Firewall-policy-lookups/ta-p/192912

      Thanks, Salon
      Terms & ConditionsAccessibility statement