[VoiceOps] SBC's that drop traffic based on domain
anorexicpoodle
anorexicpoodle at gmail.com
Fri Jun 17 13:15:16 EDT 2011
Hmm that looks remarkably like what I am doing to block some other
things with HMR and it seems to work flawlessly.
Some suggestions:
1: On the session agent set all the session cap settings (max-sessions,
max-inbound-sessions, max-burst-rate, etc) to 1, also do this for the
max-register-burst-rate and register-burst-window.
2: You might try moving the dummy session agent to the same realm as the
traffic thats coming in (peer realm?), i notice its in core, but no
context is given on the HMR as to what realm it is applied to. Ill
presume its the peer realm since that is the sip-interface you have
shown.
3: Im not sure what code youre running but if its 6.2 I believe that all
this becomes purely academic and you can use the reject action in HMR
and the need to do all the sleight of hand with the session agent
becomes unnecessary.
I have attached what ive been using for this purpose and it works
surprisingly well (I am on 6.1 code so i cannot use the reject action).
On Fri, 2011-06-17 at 12:22 -0400, Chet Curry wrote:
> I really wish your suggestion worked. The SBC responds with 404
> Registrar Not Found. The intent is to drop the packet.
>
>
>
> Here is an example of my existing HMR. Invites are always responded
> to and any registration with a user at IP is responded to . If the
> registration Request-URI has sip:IP then it blocks the packet.
>
>
>
> Here is an example of the existing HMR.
>
>
>
> ### sip-manipulation ###
>
>
>
> sip-manipulation
>
> name addRoute
>
> description
>
> header-rule
>
> name isDomain
>
> header-name request-uri
>
> action store
>
> comparison-type case-sensitive
>
> match-value
>
> msg-type any
>
> new-value
>
> methods INVITE,REGISTER
>
> element-rule
>
> name isDom
>
> parameter-name
>
> type uri-host
>
> action store
>
> match-val-type any
>
> comparison-type case-sensitive
>
> match-value
> generic.voip.net|genericlab.voip.net
>
> new-value
>
> header-rule
>
> name addDisSA
>
> header-name Route
>
> action add
>
> comparison-type boolean
>
> match-value !$isDomain.$isDom.$0
>
> msg-type any
>
> new-value "<sip:1.2.3.4;lr>"
>
> methods
>
>
>
>
>
> ### session-agent ###
>
>
>
> session-agent
>
> hostname 1.2.3.4
>
> ip-address 1.2.3.4
>
> port 5060
>
> state disabled <<<<<<<<<<
>
> app-protocol SIP
>
> app-type
>
> transport-method UDP
>
> realm-id core
>
> local-response-map 503Rogue <<<<<<<<<<
>
>
>
> ### sip-response-map ###
>
>
>
> response-map
>
> name 503Rogue
>
> entries
>
> 503 -> 677 (Rogue)
>
>
>
> ### sip-interface ###
>
>
>
> sip-interface
>
> state enabled
>
> realm-id peer
>
> description
>
> sip-port
>
> address 192.168.0.3
>
> port 5060
>
> transport-protocol UDP
>
> tls-profile
>
> allow-anonymous all
>
> ims-aka-profile
>
> carriers
>
> options dropResponse=677 <<<<<<<<<<
>
>
>
> ### realm-config ###
>
>
>
> realm-config
>
> identifier peer
>
> in-manipulationid addRoute <<<<<<<<<<
>
>
>
>
>
>
> From: anorexicpoodle [mailto:anorexicpoodle at gmail.com]
> Sent: Thursday, June 16, 2011 5:43 PM
> To: Chet Curry
> Cc: voiceops at voiceops.org
> Subject: Re: [VoiceOps] SBC's that drop traffic based on domain
>
>
>
>
>
> You should be able to facilitate this a few ways in the Acme, the
> first and easiest would be to not configure a port with the IP in the
> sip interface, and use only configure the domain name. The second
> would be to use HMR to inspect the inbound packets and drop them. Im
> sure there are other options as well.
>
> On Thu, 2011-06-16 at 16:58 -0400, Chet Curry wrote:
>
>
>
>
>
> In an effort to mitigate DDOS attack’s I am trying to deny all traffic
> based on the request-uri host domain. The reason being from what I
> see is “most” attacks are sent to the SBC’s IP address and does use
> the domain name. When the proper domain is supplied I would like to
> allow that packet. All other I will not respond to period.
>
>
>
> Example of hacker Requet URI
>
> Ex. INVITE sip100:199.44.55.22 SIP/2.0
>
>
>
> Legit Request URI
>
> Ex. INVITE sip:7724558787 at voip.myvoice.net SIP/2.0
>
>
>
>
>
>
>
> I have tried to create an HMR on ACME with little success. I can get
> the registers to not respond yet only if sip:199.44.55.22 is use. If
> the attacker uses sip:100 at 199.44.55.22 the SBC still will respond with
> a 403.
>
> Besides that All invites are always responded to regardless even
> though the HMR(Header Manipulation) should be using Invite and
> registration meathods.
>
>
>
> I have tried to get ACME to come up with a solution yet have been
> unsuccessful. They will not even take my request for a feature
> enhancement.
>
>
>
> Has anyone had any successful experience at implementing this on any
> other SBC platform? I know there are many ways to protect yourself
> from DDOS attacks yet to me this is a simple first line of defense.
>
>
>
>
>
> Description: signature2
>
>
>
>
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110617/42b89a34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 56691 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110617/42b89a34/attachment-0001.png>
-------------- next part --------------
Configuration changes/addition to Block SIP Scanner/Vicious Messages
1. HMR Change to be implemented on the Access side in-manipulation
sip-manipulation
name isScanner
description
header-rule
name isScanner
header-name User-Agent
action store
comparison-type case-sensitive
match-value friendly-scanner
msg-type request
new-value
methods
header-rule
name addNullRoute
header-name Route
action add
comparison-type boolean
match-value $isScanner.$0
msg-type request
new-value "< sip:1.1.1.1;lr >"
methods
2.Session Agent -- Configuring a dummy Agent
session-agent
hostname 1.1.1.1
ip-address 1.1.1.1
port 5060
state enabled <----
app-protocol SIP
app-type
transport-method UDP
realm-id access
egress-realm-id
description
carriers
allow-next-hop-lp enabled
constraints enabled
max-sessions 1
max-inbound-sessions 1
max-outbound-sessions 1
max-burst-rate 1
max-inbound-burst-rate 1
max-outbound-burst-rate 1
max-sustain-rate 1
max-inbound-sustain-rate 1
max-outbound-sustain-rate 1
min-seizures 5
min-asr 0
time-to-resume 0
ttr-no-response 0
in-service-period 0
burst-rate-window 0
sustain-rate-window 0
req-uri-carrier-mode None
proxy-mode
redirect-action
loose-routing enabled
send-media-session enabled
response-map
ping-method
ping-interval 0
ping-send-mode keep-alive
ping-in-service-response-codes
out-service-response-codes
media-profiles
in-translationid
out-translationid
trust-me disabled
request-uri-headers
stop-recurse
local-response-map 503Rogue <-----
ping-to-user-part
ping-from-user-part
li-trust-me disabled
in-manipulationid
out-manipulationid
manipulation-string
p-asserted-id
trunk-group
max-register-sustain-rate 0
early-media-allow
invalidate-registrations disabled
rfc2833-mode none
rfc2833-payload 0
codec-policy
enforcement-profile
refer-call-transfer disabled
reuse-connections NONE
tcp-keepalive none
tcp-reconn-interval 0
max-register-burst-rate 1
register-burst-window 1
3. Sip-Response -- Response map to Map 503 to 677 , this has to be assigned to Session agent configured in the earlier step
response-map
last-modified-by admin at 10.10.10.10
last-modified-date 2010-11-01 12:09:10
name 503Rogue
entries
503 -> 677 ()
4. Sip-Interface on the access side to be configured with option to drop the messages with 677
ACMEPACKET(sip-interface)# options +dropResponse=677
More information about the VoiceOps
mailing list