Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 7 subscribers
  • Views 2766 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I read the Rulz, I've created a DNAT blackhole rule, and I'm still getting the same IP hitting the voip server on my LAN.

Kevin Kretz

I saw a few people have had similar issues so I read their threads over a few times and made some changes on my UTM before posting this.

 

I've been watching as a particular IP tries to brute-force its way into my Asterisk sever despite firewall rules blocking it.  After seeing the other posts, I created a static blackhole route to 224.0.0.5, then created a DNAT for traffic to my WAN port from the offending IP to go to 224.0.0.5, and waited.   Just saw another one at the Asterisk server.

 

Any suggestions? My software is at 9.701-6.

 

thanks

 

Kevin



This thread was automatically locked due to age.
Parents
  • 0

    Is the blackhole DNAT before your regular rule?
    Maybe show us an edit of your rule.

    Best regards 
    Alex

    -

  • 0 in reply to Alexander Busch

    Hi,

     

    Thank you for the reply.   The Blackhole DNAT is at the top of my NAT rules, and the blackhole route to the nonexistent IP (blackhole2 in the rule) is my only static route.

     

  • 0 in reply to Kevin Kretz

    Your protected host is published via DNAT too, correct?
    Is that address in Going to your external WAN IP? And maybe it’s better to use an IP of a not existing host instead of a multicast IP.
    But nevertheless the DNAT should work with that IP too. Sorry other things I don’t see at the moment.

    Best regards 

    Alex 

    -

  • 0 in reply to Alexander Busch

    Alex,

     

    My protected host (PBX9) is not published via DNAT.  It's defined under VOIP settings , and I have a firewall rule allowing SIP protocol out from PBX9.

    The 224 address was suggested in another post, maybe I misunderstood.  I changed it to another unused IP and will see if anything changes.

     

    Thank you again

     

    Kevin

  • 0 in reply to Kevin Kretz

    Hi Kevin,

    thanks for clarification. Probably that’s why the blackhole DNAT rule is not working.
    https://community.sophos.com/cfs-file/__key/communityserver-discussions-components-files/51/iptables-sequence.JPG

    S    orry no better idea for that.

    Best regards 

    Alex 

    -

  • 0 in reply to Alexander Busch

    I'm sorry Alex - do you mean it's probably not working because of the VOIP configuration, or because of the (now changed) multicast blackhole IP?

  • 0 in reply to Kevin Kretz

    No, maybe that DNAT blackhole is processed after the connection is handled by the voip (helper / proxy). That’s be caused by the structure of the UTM.
    Sorry my knowledge of the VoIP helper is bad. So I am not sure, but that’s my best guess.

    BR

    -

  • 0 in reply to Kevin Kretz

    Interesting problem, Kevin.  I'm getting the feeling that it's the connection tracker that's allowing return traffic from the SIP Jerk after your VoIP server sent him a packet...

    Please show us the source and destination IPs and ports from one of the packets that gets through.  If you prefer, obfuscate IPs like 84.XX.YY.121, 10.X.Y.100, 192.168.X.200 and 172.2X.Y.51.  That lets us see immediately which IPs are local and which are identical or just in the same subnet.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob,

     

    From packet timing/order and dest port, it doesn't look like the problem traffic is return traffic in response to my VoIP server.

    Captured at outside interface:

    05:40:31.150779 IP 14-197-245-216.static.reverse.lstn.net.39596 > outside.interface.hostname.sip: SIP: REGISTER sip:7777@outside.ip.add.dress SIP/2.0
    05:40:31.152752 IP outside.interface.hostname.sip > 14-197-245-216.static.reverse.lstn.net.39596: SIP: SIP/2.0 401 Unauthorized
    05:40:34.879210 IP 14-197-245-216.static.reverse.lstn.net.5110 > outside.interface.hostname.sip: SIP: REGISTER sip:outside.ip.add.dress SIP/2.0
    05:40:34.881434 IP outside.interface.hostname.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.103041 IP 14-197-245-216.static.reverse.lstn.net.5110 > outside.interface.hostname.sip: SIP: REGISTER sip:outside.ip.add.dress SIP/2.0
    05:40:35.104565 IP outside.interface.hostname.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 403 Forbidden
    05:40:35.118663 IP 14-197-245-216.static.reverse.lstn.net.5110 > outside.interface.hostname.sip: SIP: REGISTER sip:outside.ip.add.dress SIP/2.0
    05:40:35.120221 IP outside.interface.hostname.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.124563 IP 14-197-245-216.static.reverse.lstn.net.5110 > outside.interface.hostname.sip: SIP: REGISTER sip:outside.ip.add.dress SIP/2.0
    05:40:35.125996 IP outside.interface.hostname.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.131833 IP 14-197-245-216.static.reverse.lstn.net.5110 > outside.interface.hostname.sip: SIP: REGISTER sip:outside.ip.add.dress SIP/2.0
    05:40:35.133424 IP outside.interface.hostname.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.138553 IP 14-197-245-216.static.reverse.lstn.net.5110 > outside.interface.hostname.sip: SIP: REGISTER sip:outside.ip.add.dress SIP/2.0
    05:40:35.139925 IP outside.interface.hostname.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized

     

    Inside interface:

    05:40:31.151401 IP 14-197-245-216.static.reverse.lstn.net.39596 > 172.19.1.9.sip: SIP: REGISTER sip:7777@172.19.1.9:5060 SIP/2.0
    05:40:31.152440 IP 172.19.1.9.sip > 14-197-245-216.static.reverse.lstn.net.39596: SIP: SIP/2.0 401 Unauthorized
    05:40:34.880131 IP 14-197-245-216.static.reverse.lstn.net.5110 > 172.19.1.9.sip: SIP: REGISTER sip:172.19.1.9:5060 SIP/2.0
    05:40:34.881069 IP 172.19.1.9.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.103579 IP 14-197-245-216.static.reverse.lstn.net.5110 > 172.19.1.9.sip: SIP: REGISTER sip:172.19.1.9:5060 SIP/2.0
    05:40:35.104239 IP 172.19.1.9.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 403 Forbidden
    05:40:35.119122 IP 14-197-245-216.static.reverse.lstn.net.5110 > 172.19.1.9.sip: SIP: REGISTER sip:172.19.1.9:5060 SIP/2.0
    05:40:35.119918 IP 172.19.1.9.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.125002 IP 14-197-245-216.static.reverse.lstn.net.5110 > 172.19.1.9.sip: SIP: REGISTER sip:172.19.1.9:5060 SIP/2.0
    05:40:35.125695 IP 172.19.1.9.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.132265 IP 14-197-245-216.static.reverse.lstn.net.5110 > 172.19.1.9.sip: SIP: REGISTER sip:172.19.1.9:5060 SIP/2.0
    05:40:35.133105 IP 172.19.1.9.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized
    05:40:35.138992 IP 14-197-245-216.static.reverse.lstn.net.5110 > 172.19.1.9.sip: SIP: REGISTER sip:172.19.1.9:5060 SIP/2.0
    05:40:35.139695 IP 172.19.1.9.sip > 14-197-245-216.static.reverse.lstn.net.5110: SIP: SIP/2.0 401 Unauthorized

     

     

  • 0 in reply to Kevin Kretz

    I agree that that packet capture seems to demonstrate that the inbound packets are not responses, but I'm not a VoIP guy, so I don't know that.

    What does Sophos Support have to say about this?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0 in reply to Kevin Kretz

    I agree that that packet capture seems to demonstrate that the inbound packets are not responses, but I'm not a VoIP guy, so I don't know that.

    What does Sophos Support have to say about this?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
Unfiltered HTML