Page 1 of 3 123 LastLast
Results 1 to 10 of 22
  1. #1
    Master Untangler
    Join Date
    Jan 2011
    Posts
    957

    Default rule to log/drop inbound email claiming to be from my own domain

    I want to disallow inbound email with a FROM address in my own domain. For various reasons I can't do this at my mail server, the best possible place to do it is at the firewall. Since the spam blocker has no such setting, the only way I can think of to do it is with an IPS rule that will simply not allow a packet containing "MAIL FROM:<someguy@mydomain.com>" and thus interrupting the SMTP conversation so that it can't complete.

    Starting from the blank rule provided by the IPS module when the "+Add" button is clicked, I did the following:

    alert tcp any any -> 1.2.3.4 25 ( msg:"mail from mydomain.com"; classtype:unknown; sid:1999999; content:"MAIL FROM:"; nocase; content:"@mydomain.com"; nocase; )

    where 1.2.3.4 is my public IP address, and mydomain.com is my domain name. The idea is to trigger on an inbound packet on port 25 that contains both the smtp command "MAIL FROM:" and the domain name prefixed with an @.

    However so far I've not seen this rule logged, though I am not 100% certain any email has come in claiming to be from our domain (but it happens a lot). I can't do a manual test via telnet, as I found that when typing the SMTP commands by hand the characters come in one at a time, so there's nothing for the IPS to look at.

    Can anyone see an error in my logic or rule?

  2. #2
    Untangler jcoffin's Avatar
    Join Date
    Aug 2008
    Location
    Sunnyvale, CA
    Posts
    6,592

    Default

    Generally this is best to do on the mail server itself since most email is delivered via encrypted TLS so the Untangle will not see the envelope.
    Attention: Support and help on the Untangle Forums is provided by
    volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  3. #3
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    22,202

    Default

    If your mail server is accepting mail from unauthenticated clients, that are sending from any of the domains it's authoritative for, it's misconfigured and needs attention.

    There are no "various reasons", fix the mail server, that's how you address this. You're supposed to IP limit the ability to do that, that's why we have SPF records and custom Exchange connectors.
    Last edited by sky-knight; 12-27-2017 at 05:32 PM.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  4. #4
    Master Untangler
    Join Date
    Jan 2011
    Posts
    957

    Default

    There's nothing to fix on the mail server, it isn't broken. I need the mail server itself to accept emails from it's own domain on the default port from any IP. It isn't exchange.

    Also, as to jcoffin's point, TLS is disabled so Spam Blocker can scan all the inbound emails.

    Anyone care to consider the actual question?

  5. #5
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    22,202

    Default

    Yes it is broken, it's a wide open relay. It may not be an open relay in the sense that it's forwarding mail to external hosts... but that's besides the point. It's a matter of best practices on any SMTP server to never accept unauthenticated mail for authoritative domains from anything unless it's IP authenticated.

    Untangle might be able to do what you want to do, I've even got a few ideas on how. But I will not provide such ideas here, because I cannot encourage such a dangerous practice.

    This is an ethical issue, perhaps if you can explain your use case better? The concept is simple enough but I cannot fathom a reason why a mail server would accept mail like this.

    And the SNORT documentation is rather clear, that it's not designed to be used like this. What you're attempting is a layer 7 operation, and best done on the mail server!

    Emails aren't packets... they are a session! Only the mail server will have all the information you need to make this decision.

    If the SMTP server cannot be modified the best safe option I have is to deploy another SMTP server, have it do the ACL work, and forward mail on to the receiving mail server. But that means redirecting mail flow to what's little more than an SMTP proxy.
    Last edited by sky-knight; 12-29-2017 at 12:36 PM.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  6. #6
    Master Untangler
    Join Date
    Jan 2011
    Posts
    957

    Default

    you're reading WAY too much into this. there's no ethical issue here. the server doesn't relay mail from any IP except those which I've specifically allowed. I have need for the mailserver itself to accept mail claiming to be from it's own domain, and relay it if it's been allowed to. yes, I can tell it not to accept email from it's own domain (or any domain I wish), and I can tell it whether to accept email at all from a given IP, but I can't tell it to accept mail from it's own domain from some ip addresses but not from others. no, I'm not trying to do a layer 7 operation.... all I want to do is trigger an alert (for testing, later a drop) on any single packet inbound to port 25 that contains the text "MAIL FROM:" and "@mydomain.com". I don't want to setup another mail server, when all I need is for Untangle to drop the offending packet.

    If you can see where my IPS rule is wrong or if you have other ideas on how to get untangle to do what I wish, I'd appreciate it.

  7. #7
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    22,202

    Default

    Actually I've been digging into this and I've about determined it flat won't work. Yes, you're trying to perform an application level decision on a firewall, that's layer 7. Snort is layer 3.

    Again, you need information from an SMTP SESSION, not from an SMTP PACKET. Snort works with packets, not sessions. So I don't see how you're going to selectively identify this and work with it with SNORT. There is no "mail from" in the packet header, that's in one packet's payload, one of many involved with the SMTP session. And dropping that one packet might cause ugly things to happen to either the sending or receiving service.

    What SMTP server are you using? Because you should be able to define various delivery rules, one for public use that wouldn't allow for the from address to be a domain on the server available to all IP addresses everywhere, and another that allows the internal network to do whatever it wants. I've never known an SMTP server that cannot do that.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  8. #8
    Master Untangler
    Join Date
    Jan 2011
    Posts
    957

    Default

    snort rules work with the payload too, that's what the content: conditions are for.... tons of snort rules work on content rather than headers. and yes, the only thing I need is the content of a single TCP packet, I don't care about the session. I know my end will handle aborted/timed-out SMTP sessions just fine, and I don't care about what happens to the spammer's SMTP session - it'll probably tarpit him a bit, that's fine by me.

  9. #9
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    22,202

    Default

    But won't be an aborted session though, you're just pulling a specific packet out of a session that TCP will report as undelivered, so it'll be sent again... and again... and again.

    You need the SMTP service to tell the client to take a hike.

    Untangle's Anti-Spam functionality doesn't truncate SMTP sessions, it actually sends the disconnect commands back to the client so it goes away.

    Seriously this must be done on the SMTP server.
    Last edited by sky-knight; 12-29-2017 at 03:18 PM.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  10. #10
    Master Untangler
    Join Date
    Jan 2011
    Posts
    957

    Default

    Why do I care if a spammer keeps trying to send a packet that I've decided I don't want to accept? I really don't see why you think this is a bad idea.

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2