Helpful ReplyHot!Rule blocking communication with specific netblock seems to not be working.

Author
gt
New Member
  • Total Posts : 3
  • Scores: 0
  • Reward points: 0
  • Joined: 2017/08/08 14:31:32
  • Status: offline
2017/08/09 14:36:05 (permalink) 5.4
0

Rule blocking communication with specific netblock seems to not be working.

The brief overview is we have someone attempting to, I assume compromise, phones in our VOIP system from an IP originating in the Russian Federation. I have attempted to block their IP, the /24 range of IPs, ports used and i'm still seeing packets on the internal interface from their IP. I cannot for the life of me figure out why this is happening and isn't being blocked, it's even using a rule configured for outbound communication to get in, according to FortiView.
 
So I suppose the first question is, will the packet capturer, "diag sniffer packet internal 'net 185.22.155.0/24' 6" show packets that are dropped? I typically set it up so I have one set on wan1 and a separate one set on internal to see if the packet is actually getting to internal from wan1. So if I'm seeing a packet from wan 1 with src=185.22.155.18 and dst =8.27.x.x. then at the same time one on the internal showing src=8.27.x.x and dst=192.168.x.x that, to me, means the packet is getting through. As a note I also use the gui packet capturer to do the same so I can view the .pcap since I haven't gotten the script that converts ssh output to work yet.
 
If there's some information I can get from the CLI that will best help diagnose this please let me know, I'm still learning all the commands. For now though, here are some images from the gui showing what I'm talking about. 

This image shows in FortiView that these connections are being accepted using a rule designed for outbound communications (Source interface: Internal. Destination interface: Wan1 & 2) 

 
This image shows two rules, the first is set to block this ip range on outbound communications and then the other for inbound. I initially didn't specify the interfaces, but that wasn't working so I tried specifying them and it's the same situation, both rules showing 0 bytes. I also initially had the service as ALL but thought maybe it needed to specify protocols, so I did that on the inbound. If I ping the offending IP the first rule shows its blocking data, but if an internal phone tries to communicate with the offending IP, like to respond "405 Registration Method Not Allowed" since they're attempting to register with our VOIP phones using SIP, it doesn't block the communication and no bytes appear on the rule.

 
For a more detailed look at the rule FortiView is saying the connections are using. I have checked to ensure the offending ip is not within the desination address netblock, as that one is in the 184.x.x.x range with a /24 CIDR.

 
Another portion that is confusing about this, I cannot for the life of me find the offending ip on any logs within the 90E's gui or within FortiCloud's interfaces. I have ensured its set to log all, so I would think it would be showing. The catchall syslog we save locally, however, does show the hits. Every line that has their IP is showing what I've quoted below. The part that confuses me is that it's only showing the dstip as being the internal IP its communicating with rather than any lines showing the initial connection with our public ip(wan1: 8.27.x.x). I don't know if that's indicative of anything or if that's just standard.
srcip=185.22.155.18 src_port=59944 dstip=192.168.X.X dst_port=5060 proto=17 src_int="wan1" dst_int="internal" policy_id=23 profile="default" voip_proto=sip kind=register action=permit status=failed
So at this point I'm not sure what is going on and why I'm unable to block communication to/from this IP. Any assistance would be greatly appreciated. Also apologies if I blocked out too much information, I'm really not sure what should/should not be shared publicly and just decided to err on the side of caution.
#1
emnoc
Expert Member
  • Total Posts : 4137
  • Scores: 231
  • Reward points: 0
  • Joined: 2008/03/20 13:30:33
  • Status: offline
Re: Rule blocking communication with specific netblock seems to not be working. 2017/08/09 19:24:39 (permalink) ☄ Helpfulby gt 2017/08/11 13:46:17
5 (1)

If there's some information I can get from the CLI that will best help diagnose this please let me know,

 
Yes the cli cmd diag debug flow and a correct filter is what you should be looking at. This will ensure your hitting the policy in question.
 
Qs you need to ask
 
 
Q1?  What is  fwpolicy-id configuration
 
Q2?  Where is it in the sequence of "other" policies
 
 
 

PCNSE6,PCNSE7, ACE, CCNP,FCNSP,FCESP,Linux+,CEH,ECSA,SCSA,SCNA,CISCA email/web
#2
gt
New Member
  • Total Posts : 3
  • Scores: 0
  • Reward points: 0
  • Joined: 2017/08/08 14:31:32
  • Status: offline
Re: Rule blocking communication with specific netblock seems to not be working. 2017/08/11 13:48:46 (permalink)
0
Thank you for the response, I started using diag debug flow but the traffic has mysteriously ceased. At least for now, I will continue to keep an eye on it and hopefully get more detailed information if they decide to resume.
#3
MikePruett
Platinum Member
  • Total Posts : 617
  • Scores: 10
  • Reward points: 0
  • Joined: 2014/01/08 19:39:40
  • Location: Montgomery, Al
  • Status: offline
Re: Rule blocking communication with specific netblock seems to not be working. 2017/08/12 19:13:57 (permalink)
0
Let us know if it pops back up and we will help you get to the bottom of it

Mike Pruett
Fortinet GURU
#4
Jump to:
© 2017 APG vNext Commercial Version 5.5