Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Gold

Custom SMTP sig for open relay

I'm attempting to create a custom sig that will fire on incoming SMTP sessions where rcpt to: <value> is _not_ one of the domains we relay mail for. Is this possible using the regex? For example:

[Rr][Cc][Pp][Tt][ \t]+[Tt][Oo][ \t]*:.*<insert regex expression here that matches anything that does NOT match a specific pattern>

So basically, if what follows the rcpt to: is NOT @mydomain.com an event is triggered.

2 REPLIES
Cisco Employee

Re: Custom SMTP sig for open relay

Not really possible.

The sensor does not have the ability to fire an alarm when a full regular expression is Not matched.

The sensor does have the ability to do single character negation, but that may not fully give you what you want.

So with your example of "@mydomain.com".

Assume each example regex begins with:

[Rr][Cc][Pp][Tt][ \t]+[Tt][Oo][ \t]*:.*

Just like in your original email.

and I add:

@[^m][^y][^d][^o][^m][^a][^i][^n][^.][^c][^o][^m]

The alarm won't fire if the message says:

rcpto: joe@mydomain.com

But it WILL fire (false positive)if the message says:

rcpto: jim@someplace.net,joe@mydomain.com

The sensor sees the first @ and then does a character by character check

s matches [^m]

o matches [^y]

m matches [^d]

e matches [^o]

p matches [^m]

l matches [^a]

a matches [^i]

c matches [^n]

e matches [^.]

. matches [^c]

c matches [^o]

o matches [^m]

So it fires because the first address matches the regular expression not even having checked the second address.

You could even swap the 2 addresses:

rcpto: joe@mydomain.com,jim@someplace.net

And the alarm WILL still fire (false positive).

It will check the first @mydomain and continue checking, and when it gets to the second @ it will simply make joe@mydomain.com,jim be part of the ".*" in the regular expression and try matching @someplace.com to the rest of the regular expression.

Additional the following will NOT fire (false negative) the alarm:

rcpt: bob@12345678.com

This because the . in the ninth place after @ does NOT match [^.] which prevents the alarm from firing.

Additonally the following email will NOT fire (false positive) the alarm:

rcpto: mary@myhome.net

This is because the m as the first character after the 2 fails the regular epxression match [^m].

To do what you wanted the sensor would have to support the negation of an entire sequence of characters rather than the negation of several single characters like:

!(@mydomain.com)

But that is not supported.

So you could try writing a simple pattern like:

@[^m][^y]

Instead of writiing the full pattern using all of the characters.

It will fire on any email where one of the addresses does not have "@my" in it.

You will still get false positives and false negatives.

You can even play around with adding more characters to the regular expression to see if the rate of false positives and false negatives increases or decreases. It really depends on how closely the other addresses resemble your addresses as to how often the alarm will misfire.

In the end it depends on what exactly you will be doing with the end alarm. If it is just to show how much your server is being used for relays that it shouldn't be used for. Then a few false positives and some false negatives may be OK for what you are wanting.

Something else to consider:

If you have more than one domain:

@mydomain.com

@overthere.net

Then you would need to do a character by character combination within each negation in the regular expression:

@[^mo][^yv][^de][^or].......

This could result in even more false positives and false negatives and that may or may not be OK for what you are doing.

Gold

Re: Custom SMTP sig for open relay

Thanks for your response.

>>But it WILL fire (false positive)if the message

>>says: rcpto: jim@someplace.net,joe@mydomain.com

Doesn't the RCPT TO: command have to be issued for each recipient? Anyway, our mail servers seem to toss any attempts to specify multiple comma separated values. This should eliminate a lot of the false positives you mention.

>>Additional the following will NOT fire (false

>>negative) the alarm: rcpt: bob@12345678.com

>>This because the . in the ninth place after @ does

>>NOT match [^.] which prevents the alarm from

>>firing.

Hmm...I think you're right. In fact, if _any_ of the above characters match in any position (i.e. m2345678.com) then the event won't trigger. Pretty much defeats the purpose.

>>To do what you wanted the sensor would have to

>>support the negation of an entire sequence of

>>characters rather than the negation of several

>>single characters like

Yes, that's exactly what I'm looking for. Something like Perls lookahead assertions. Cisco, if you listening...add this functionality please. Out of curiousity, I'm going to see what snorts capabilities are in the arena tonight.

119
Views
0
Helpful
2
Replies
CreatePlease to create content