User Agent matching

1. Brekeke Product Name and version:
Currently we have a v2 paid working in house but This issue is with the newest v3 3.0.6.3/333

2. Java version: 1.7.0_02

3. OS type and the version: centos 2.6.32-220.23.1.el6.x86_64

4. UA (phone), gateway or other hardware/software involved:no no no

5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/ ... terns.html :pattern 1


6. Your problem:

User agent stuff

The User_agent matching pattern is case sensitive, for example sending in "friendly-scanner" will be matched but "Friendly-scanner" would not. Could this be changed so that it ignores case?

Secondly the advice for v3 is to set the deloy patterns to $accept = false, however doing this with a user-agent that is matched results in a 404 not found, so I am still getting packets back. By using $action = 603 instead I get a 603 message back form the brekeke so i know the pattern is matching. We perfer the idea of not replying to any message, what am I doing wrong here?

Another issue is that you can have a user agent as user agent='n0n-friendly-scanner' (in the SIP itself) and brekeke will still match on the 'friendly-scanner' and ignore the first part of the string. I am unsure if this is by design but if it matches any part of the user agent it triggers the pattern. I am unsure if this is by design,

tl:dr
_ can we make user agent matching non case senstive?
_ is the accept = False working? from my tests I do not think it is.
_ partital matching on user-agent string is this by design?

can we make user agent matching non case senstive?

You can always put in Friendly-Scanner|friendly-scanner

_ is the accept = False working? from my tests I do not think it is.

You could always add $target=0.0.0.0 into the deploy

_ partital matching on user-agent string is this by design?
Brekeke uses regex - regular expressions. You can search for a regex tutorial.

Also, Auth=off should be in your deploy.

> The User_agent matching pattern is case sensitive, for example sending in "friendly-scanner" will be matched but "Friendly-scanner" would not. Could this be changed so that it ignores case?

Use $str.lowercase()

---------------------------------------
[Matching Patterns:]
$str.lowercase( User-Agent )= friendly-scanner|sundayddr
----------------------------------------

> Secondly the advice for v3 is to set the deloy patterns to $accept = false, however doing this with a user-agent that is matched results in a 404 not found,


The definition "$accept" must be used at the [Dial Plan] -> [Preliminary] .
It seems you set it at the [Dial Plan] -> [Rules].

See http://wiki.brekeke.com/wiki/Avoid-attacks

The [Preliminary] rules are evaluated before the SIP Server processes packets.
So the "$accept = false" will allow us to reject packet without any responses including "100 trying".

I have found that simply not replying does not stop the scan. If you really want to confuse them and stop the scan, send $response=200. Stops the scan every time because the scanner thinks it succeeded and takes the bogus login and password it thinks it succeeded with and sends it to level2 hacking software usually on another machine sometime later. It will try to login, fail and move on to easier targets usually.

The trick is never to return an accurate response which they use to learn how to penetrate your system.

Hello All

Thank you for taking the time to take a look at my issues.

janP = Your $str.lowercase works great thank you, also your point about the preliminary was correct. I had the rule in the wrong place.

voipwell.com = Thank you for the idea about the replying with 200, makes much more sense to make them move on, than for them to continue their assault

o7 have a good Friday all,

Glad to be of help.

Brekeke's approach is to stay stealthy and not respond to scan. That is wise. But to stop a scan that is affecting your bandwidth or processor, you only alternative is to 200 ok them away. I should disclose that rather than send an 200 ok every scan attempt, send it only on even or odd attempts or if the session id ends with 5 which should be every 1 out of 10 times. It just adds to their confusion preventing them from anticipating it and programming around it.

Here's a matching pattern to fire off 200 only if the session id ends with 1 3 or 5.

$sid=[135]$

I never cease being amazed at what can be done with Brekeke products.

janP wrote:> Secondly the advice for v3 is to set the deloy patterns to $accept = false, however doing this with a user-agent that is matched results in a 404 not found,


The definition "$accept" must be used at the [Dial Plan] -> [Preliminary] .
It seems you set it at the [Dial Plan] -> [Rules].

See http://wiki.brekeke.com/wiki/Avoid-attacks

The [Preliminary] rules are evaluated before the SIP Server processes packets.
So the "$accept = false" will allow us to reject packet without any responses including "100 trying".

In my case, BSS 3.0 Adv. (3.0.7.0) doesn't work "$accept=false"
(Dial-plan->Preliminary)
Is it bug?

what dial plan rule is it?
and how brekeke work like?

redmiru,
if you set "$accept=false" in Preliminary, Brekeke SIP Server doesn't accept matched requests.
It means there are no response.

james wrote:redmiru,
if you set "$accept=false" in Preliminary, Brekeke SIP Server doesn't accept matched requests.
It means there are no response.

Thank you for your reply!

Yes, It MUST no response but there is no effect.

Here is my rule (Agent filtering)

==================================
Matching Patterns
==================================
$request=^INVITE
User-Agent = !Bria 3 release 3.4.2 stamp 67300


==================================
Matching Patterns
==================================
$accept=false


and make a call with other client(Not a bria3), always success the call (BSS returns 200 OK...)

In case of change matching pattern, ($action = 603) then BSS return 603.

Really it works? (additionally, if I set $accept=false, "accept" string's color doesn't change to blue. It displayed black string)

tried with v3070 and work
maybe need to update software

Set "dialplan.debug.log = true" in the [Configuration]>[Advanced] page.
It allows you to get detailed log to show how DialPlan rules are evaluated.

After you make a test call, see the sv.xxx.log.

Thank you everyone! it works!

My mistake is matching pattern rules.


** test client
1) Bria iOS 2.1.3 (it MUST blocked)
2) Bria 3 release 3.4.2 stamp 67300 (It MUST accepted)

** matching pattern
$request=^INVITE
User-Agent = !Bria 3 release 3.4.2 stamp 67300



Maybe BSS ignored under space characters. (BSS understands "User-Agent = !Bria")

So Bria iOS client does not filtered by rule.


Last question

1) How can I filtering the Bria iOS client? I want to accept only PC version (Bria 3 release 3.4.2 stamp 67300)

redmiru,
I've tested the same situation and it worked without issue.
I mean the following definition must work.
User-Agent = !Bria 3 release 3.4.2 stamp 67300

Have you set "dialplan.debug.log = true" to get DialPlan log?


> 1) How can I filtering the Bria iOS client? I want to accept only PC version (Bria 3 release 3.4.2 stamp 67300)

Try this.
=========================
[Matching Patterns]
$request=^INVITE
User-Agent = Bria iOS

[Deploy Patterns]
$response = 603
=========================

According to the server log, it's my mistake.

============================================
PreCheck [Agent filter]
Pattern: $request = ^REGISTER
Input: $request = REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0
Result: true

Pattern: User-Agent = !Bria 3 release 3.4.2 stamp 67300
Input: User-Agent = Bria iOS 2.1.3
Result: false

============================================

User-Agent = !Bria 3 release 3.4.2 stamp 67300

_!Bria 3 release 3.4.2 stamp 67300
^

Here is my mistake. space character is included..OMG..


Thank you for your advice!!!

Did you edit the "dialplan.tbl" file directly?

No, I didn't.

but It seems copy&paste mistake.

Oh ok.