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. [cid:image001.png at 01CC2C46.97470A90]
On 06/16/2011 04:58 PM, 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.
It's pretty trivial in Kamailio/OpenSER, and if you stuck it in front of an Acme Packet you can make it extremely lightweight through stateless forwarding. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
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
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. [cid:image001.png at 01CC2CE9.2E6B0730] _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
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
How about using local-policy instead of HMR? From-address * To-address *@voip.myvoice.net<mailto:*@voip.myvoice.net> Policy-attributes Next-hop Softswitch Realms, etc, would be pursuant to your needs, of course. --- Brandon Buckner Switching Technician / VoIP Admin Iowa Network Services brandonb at netins.com<mailto:brandonb at netins.com> From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Chet Curry Sent: Thursday, June 16, 2011 3:58 PM To: voiceops at voiceops.org Subject: [VoiceOps] SBC's that drop traffic based on domain 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. [cid:image003.png at 01CC2C44.F5FE8C40]
participants (4)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
BrandonB＠netins.com -
CCurry＠telovations.com