hosts.allow VERSUS access.db - email spam - Unix

This is a discussion on hosts.allow VERSUS access.db - email spam - Unix ; I'm just learning unix...I hope my questions are clear and would appreciate any comments I'm receiving lots of email spam from 2 IP addresses. The email "From" field is spoofed to appear as if it's from either my domain or ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: hosts.allow VERSUS access.db - email spam

  1. hosts.allow VERSUS access.db - email spam

    I'm just learning unix...I hope my questions are clear and would appreciate
    any comments

    I'm receiving lots of email spam from 2 IP addresses. The email "From"
    field is spoofed to appear as if it's from either my domain or other domains
    that we have regular email communications with. I can tell that it's
    spoofed because the header indicates these users are using dsl or cable
    accounts.

    I'd like to block these messages, but was wondering which is better -
    hosts.allow or access.db?

    One person told me to put the following in my hosts.allow file
    ALL : IP : DENY (where IP, IP2, etc are the numeric IP addresses that I want
    to block)
    ALL : IP2 : DENY

    I was thinking about using the following access.db entry
    IP DISCARD (where IP, IP2, etc are the numeric IP addresses that I want to
    block)
    IP2 DISCARD

    Are there any benefits to using the hosts.allow method versus the access.db
    method? As far as syntax in either hosts.allow or access.db, are there
    spaces or tabs between each item on a line - for example is it
    ALL:IP:DENY or are tabs used? What about
    access.db....IPDISCARD or tab?

    All comments will be greatly appreciated. Thanks very much. I'm on a
    freebsd platform with the latest version of sendmail.

    Don



  2. Re: hosts.allow VERSUS access.db - email spam

    Begin
    On 2005-12-14, dcraw wrote:
    > I'm receiving lots of email spam from 2 IP addresses. The email "From"
    > field is spoofed to appear as if it's from either my domain or other domains
    > that we have regular email communications with. I can tell that it's
    > spoofed because the header indicates these users are using dsl or cable
    > accounts.
    >
    > I'd like to block these messages, but was wondering which is better -
    > hosts.allow or access.db?


    That depends on the situation. tcpwrappers deals with TCP connections,
    but access.db may allow you to reject on the SMTP level (instead of on
    the TCP level). At the cost of talking SMTP to the other side[1], you
    buy the opportunity to give back a customized rejection message. Do
    not expect spammers to read those, but receivers of rejection notices
    on false positives (rejected non-spam) might, and you might explain
    (shortly; one line, not a screenful) on what grounds you declined to
    receive the offered mail.

    Spammers tend to move around a lot as they are evicted from hoster after
    hoster. For that reason you might want more generic rules than blocking on
    specific IP. (Altough you still might want to do that!)

    A simple option there is to have your MTA (ie, sendmail) check the IP
    address for reverse resolution (``rDNS'') and then check whether it
    matches the forward (found name resolves back to the originating ip) or
    the name it gives as HELO string. In fact, a lot of anti-spam tricks
    involve verifying the things the sender claims and whether or not the
    sender is listed as a known spammer in various lists of known spamming
    hosts.


    > Are there any benefits to using the hosts.allow method versus the access.db
    > method? As far as syntax in either hosts.allow or access.db, are there
    > spaces or tabs between each item on a line - for example is it
    > ALL:IP:DENY or are tabs used? What about
    > access.db....IPDISCARD or tab?


    Those should be documented with the software that uses them. The
    format for hosts.allow is (on my system, at least) documented in the
    hosts_access(5) manpage[2]. I don't know where access.db is documented
    but if it belongs to sendmail then undoubtedly somewhere in the sendmail
    documentation.

    Maybe you'll pardon me for saying so; I'm not very much worried about
    the difference in syntax for both files, as they are fairly simple and
    human editable. I think the difference in what they do more important.


    > All comments will be greatly appreciated. Thanks very much. I'm on a
    > freebsd platform with the latest version of sendmail.


    FreeBSD (in use here) also allows you to employ a firewall, it even
    offers three different flavours (with slightly different features). With
    that you also can reject (return a TCP RST, ``no service'') or drop[3]
    connections (never answer, causing timeouts and retries) coming in, but
    again you lost the option of returning a customized SMTP error.

    This is not an exhaustive list of things you can do, for an elaborate
    and advanced example see OpenBSD's spamd which does graylisting in
    conjunction with the pf firewall, using port redirects and dynamic
    rules. What you do depends heavily on how you wish to organize this and
    on things like traffic considerations.


    [1] Since that is what sendmail does best, it should not be a great cost.
    Given enough volume, however, you still might not want to spend it.
    [2] Issue the command ``man 5 hosts_access'' on a prompt near you.
    [3] Unless there are traffic volume considerations[4], it is usually better
    to reject or to return proper ICMP error messages than to drop outright.
    [4] Think 10s or 100s of connections per second.

    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  3. Re: hosts.allow VERSUS access.db - email spam

    Couple of other questions for clarification -

    > the TCP level). At the cost of talking SMTP to the other side[1], you
    > buy the opportunity to give back a customized rejection message.


    If I go the SMTP route and the mail is spoofed to look like it came from my
    domain, will I get the rejection notice? On our email server,
    anything@ourdomain.com goes to a catchall account, so I don't want this
    inbox to get these "rejection" messages.

    Do I understand it correctly that using the hosts.allow route will just
    ignore all connection requests from an IP - http, email, ftp, etc.

    jpd, thanks very much for your original reply. I appreciate the fact that
    it was very detailed and helps me understand what's going on.


    "jpd" wrote in message
    news:40b2egF19pkahU1@individual.net...
    > Begin
    > On 2005-12-14, dcraw wrote:
    >> I'm receiving lots of email spam from 2 IP addresses. The email "From"
    >> field is spoofed to appear as if it's from either my domain or other
    >> domains
    >> that we have regular email communications with. I can tell that it's
    >> spoofed because the header indicates these users are using dsl or cable
    >> accounts.
    >>
    >> I'd like to block these messages, but was wondering which is better -
    >> hosts.allow or access.db?

    >
    > That depends on the situation. tcpwrappers deals with TCP connections,
    > but access.db may allow you to reject on the SMTP level (instead of on
    > the TCP level). At the cost of talking SMTP to the other side[1], you
    > buy the opportunity to give back a customized rejection message. Do
    > not expect spammers to read those, but receivers of rejection notices
    > on false positives (rejected non-spam) might, and you might explain
    > (shortly; one line, not a screenful) on what grounds you declined to
    > receive the offered mail.
    >
    > Spammers tend to move around a lot as they are evicted from hoster after
    > hoster. For that reason you might want more generic rules than blocking on
    > specific IP. (Altough you still might want to do that!)
    >
    > A simple option there is to have your MTA (ie, sendmail) check the IP
    > address for reverse resolution (``rDNS'') and then check whether it
    > matches the forward (found name resolves back to the originating ip) or
    > the name it gives as HELO string. In fact, a lot of anti-spam tricks
    > involve verifying the things the sender claims and whether or not the
    > sender is listed as a known spammer in various lists of known spamming
    > hosts.
    >
    >
    >> Are there any benefits to using the hosts.allow method versus the
    >> access.db
    >> method? As far as syntax in either hosts.allow or access.db, are there
    >> spaces or tabs between each item on a line - for example is it
    >> ALL:IP:DENY or are tabs used? What about
    >> access.db....IPDISCARD or tab?

    >
    > Those should be documented with the software that uses them. The
    > format for hosts.allow is (on my system, at least) documented in the
    > hosts_access(5) manpage[2]. I don't know where access.db is documented
    > but if it belongs to sendmail then undoubtedly somewhere in the sendmail
    > documentation.
    >
    > Maybe you'll pardon me for saying so; I'm not very much worried about
    > the difference in syntax for both files, as they are fairly simple and
    > human editable. I think the difference in what they do more important.
    >
    >
    >> All comments will be greatly appreciated. Thanks very much. I'm on a
    >> freebsd platform with the latest version of sendmail.

    >
    > FreeBSD (in use here) also allows you to employ a firewall, it even
    > offers three different flavours (with slightly different features). With
    > that you also can reject (return a TCP RST, ``no service'') or drop[3]
    > connections (never answer, causing timeouts and retries) coming in, but
    > again you lost the option of returning a customized SMTP error.
    >
    > This is not an exhaustive list of things you can do, for an elaborate
    > and advanced example see OpenBSD's spamd which does graylisting in
    > conjunction with the pf firewall, using port redirects and dynamic
    > rules. What you do depends heavily on how you wish to organize this and
    > on things like traffic considerations.
    >
    >
    > [1] Since that is what sendmail does best, it should not be a great cost.
    > Given enough volume, however, you still might not want to spend it.
    > [2] Issue the command ``man 5 hosts_access'' on a prompt near you.
    > [3] Unless there are traffic volume considerations[4], it is usually
    > better
    > to reject or to return proper ICMP error messages than to drop
    > outright.
    > [4] Think 10s or 100s of connections per second.
    >
    > --
    > j p d (at) d s b (dot) t u d e l f t (dot) n l .
    > This message was originally posted on Usenet in plain text.
    > Any other representation, additions, or changes do not have my
    > consent and may be a violation of international copyright law.




  4. Re: hosts.allow VERSUS access.db - email spam

    Begin
    On 2005-12-14, dcraw wrote:
    > Couple of other questions for clarification -
    >> the TCP level). At the cost of talking SMTP to the other side[1], you
    >> buy the opportunity to give back a customized rejection message.

    >
    > If I go the SMTP route and the mail is spoofed to look like it came from my
    > domain, will I get the rejection notice? On our email server,
    > anything@ourdomain.com goes to a catchall account, so I don't want this
    > inbox to get these "rejection" messages.


    That heavily depends on what exactly it is you're doing and also on who
    is sending the mail. If you look at how SMTP works, you'll see that
    there is a difference between getting a ``can't deliver, don't try
    again'' response (with your custom message) in the protocol session,
    and an actual bounce message, transmitted back on a separate protocol
    session in the other direction. If the MTA talking to you when you
    are responding with a rejection is not the one originally sending the
    mail, it may end up generating a bounce with your rejection in it and
    it may end up in your mailbox after all. Whether this actually happens
    is another thing, and you can do a thing or two to stop it, should it
    happen too often.


    > Do I understand it correctly that using the hosts.allow route will just
    > ignore all connection requests from an IP - http, email, ftp, etc.


    You can make it so, in so far as all applications use it, but it doesn't
    have to be. hosts.allow selects on application, not on destination port.
    See the reference I gave you (hosts_access(5)) for more details on how
    the mechanism works.


    > jpd, thanks very much for your original reply. I appreciate the fact that
    > it was very detailed and helps me understand what's going on.


    You're welcome. But please don't ``top post'' or include the complete
    original message. You might want to consider that I normally killfile
    for that. See RFC1855 or google for ``netiquette'' for elaboration on
    the point. At the risk of sounding patronizing: You do need to follow
    references given, as it saves me a lot of work and will give you a
    better explanation than I'm prepared to give in a particular posting.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

+ Reply to Thread