Thanks Klaus.

Just to make sure I understand what you suggested, I should replace

if (uri!=myself) { t_relay(); break; }

with the code snippet you posted. Right?

Many Thanks, Paul

On 6/29/05, Klaus Darilion klaus.mailinglists@pernau.at wrote:

Hi!

It is simple, it just depends on your routing logic:

use domain module and check out-of-dialog methodes:

if ( !is_uri_host_local()) { if (is_from_local() { t_relay; break; } else { sl_send_reply("403", "Relaying not allowed"); } }

cheers, klaus

Java Rockx wrote:

...

Hi All.

This link is to a discussion on how to keep SER from being an open relay due to the following logic that most everyone uses in their ser.cfgfiles.

if (uri!=myself) { t_relay(); break; }

http://lists.iptel.org/pipermail/serusers/2003-October/003264.html

Some time has passed on this issue and the 2003 article described a few "in-progress" patches.

Does anyone know if SER now has the ability to prevent malicious users from exploiting (uri!=myself) code blocks?

Regards, Paul

---

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hello there

Zeus Ng wrote:

Yes, you just replace that one. Alternatively, if you don't want to load the domain module, you can try from_uri.

if (!uri == myself) { if (from_uri == myself) { t_relay(); break; } else { sl_send_reply("403", "Relaying not allowed");

please forgive my ignorance but shouldn't a "break" be included here?

}

}

another related doubt: shouldn't one protect the statements bellow, too?

# loose-route processing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); t_relay(); break; };

Cheers !3runo

Zeus Ng wrote:

See inline.

...

Hello there

Zeus Ng wrote:

...

Yes, you just replace that one. Alternatively, if you don't want to load the domain module, you can try from_uri.

if (!uri == myself) { if (from_uri == myself) { t_relay(); break; } else { sl_send_reply("403", "Relaying not allowed");

please forgive my ignorance but shouldn't a "break" be included here?

Yes, you are right.

...

...

} }

another related doubt: shouldn't one protect the statements bellow, too?

# loose-route processing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); t_relay(); break; };

Logically, you should protect it as well. However, the way loose route was constructed make it difficult to check uri. The best way is only allow in dialogue INVITE with to tag.

for example: A calls B. B forwards the call to C. If C sends the BYE, this will be loose route, but the From: header contains domain B, the To: header contains domain A, and the domin in the request URI contains the IP address of A. Thus, if you will check for domain C it will fail.

if (loose_route()) { if (method == "INVITE") { if (!has_totag()) { # can't remember the syntax sl_send_reply("403", "Cannot use this proxy as outbound proxy!"); break; }; } t_relay(); break; };

You can do checking on other requests (MESSAGE, INFO, OPTIONS ...) here as well.

I check all loose_route messages if they have a to-tag: if (loose_route()) { if (!has_totag()) { # can't remember the syntax sl_send_reply("403", "Cannot use this proxy as outbound proxy!"); break; }; t_relay(); break; };

regards, klaus

Zeus Ng wrote:

Klaus Darilion wrte:

...

...

allow in dialogue INVITE with to tag.

for example: A calls B. B forwards the call to C. If C sends the BYE, this will be loose route, but the From: header contains domain B, the To: header contains domain A, and the domin in the request URI contains the IP address of A. Thus, if you will check for domain C it will fail.

See the key words "in dialogue INVITE". I was trying to address one particular SIP method here. I did mentioned to check other method as well. Besides, there was no mentioning of uri check here, just to tag!

Of course. I just wanted to strengthen your statement and give an example why uri checks are not useful for loose_route processing. :-)

klaus