OS fingerprinting and traffic shaping with iptables? - Networking

This is a discussion on OS fingerprinting and traffic shaping with iptables? - Networking ; Is it possible to check the OS of the remote clients and to prioritize some of the OS with iptables? For instance, is it possible to classify and slow down any SMTP connection from a Windows box?...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: OS fingerprinting and traffic shaping with iptables?

  1. OS fingerprinting and traffic shaping with iptables?

    Is it possible to check the OS of the remote clients and to prioritize
    some of the OS with iptables? For instance, is it possible to classify
    and slow down any SMTP connection from a Windows box?


  2. Re: OS fingerprinting and traffic shaping with iptables?

    > Is it possible to check the OS of the remote clients and to prioritize
    > some of the OS with iptables? For instance, is it possible to classify
    > and slow down any SMTP connection from a Windows box?


    Yes and No.

    I believe most versions of Netfilter contained enough facilities to
    identify the senders OS using passive fingerprinting, but no one bothered
    to write the necessary rules.

    Recent versions of Netfilter support using the BSD ruleset (see man
    iptables, section labelled "osf").

    Since incoming SMTP connections are by definition "incoming", there is
    little in the way of meaningful traffic shaping one can do. The Linux
    Advanced Routing and Traffic Control HOWTO discussed the problems with
    shaping incoming traffic.

    Since the "resources of the spambots" >>> "resources you have", I'd
    recommend only approaches that minimise the resource you expend per
    spambot. Consider say the Spamhaus PBL, which list IP addresses reported
    as allocated to end user systems (with a way for end users to remove
    themselves if they run an email server).

  3. Re: OS fingerprinting and traffic shaping with iptables?

    On Thu, 22 Mar 2007 09:50:42 -0700, totojepast wrote:

    > Is it possible to check the OS of the remote clients and to prioritize
    > some of the OS with iptables? For instance, is it possible to classify
    > and slow down any SMTP connection from a Windows box?


    Even if it is technically feasible, you might want to ask "is it ethical?"


  4. Re: OS fingerprinting and traffic shaping with iptables?

    In article ,
    ray wrote:

    >> Is it possible to check the OS of the remote clients and to prioritize
    >> some of the OS with iptables? For instance, is it possible to classify
    >> and slow down any SMTP connection from a Windows box?

    >
    >Even if it is technically feasible, you might want to ask "is it ethical?"


    Only those who would like to send unsolicited bulk email advertising
    or newsletters seriously question whether it is ethical to slow down,
    block, or blacklist spam or any sort of email based on any rules or
    procedures, no matter how strange or inaccurate. Each of us has the
    right to do anything with our SMTP servers (mail receiving systems),
    no matter how stupid it seems to other people.

    For some U.S. legal precedents, look for old AOL vs. Cyberpromo court
    cases. See also the CAN-SPAM Act.


    Some people have reported good results against botnet spam (the current
    majority) using the Linux TCP client fingerprinting tuned to detect
    Windows systems. However, I agree with the contributor to this thread
    who recommend Spamhaus' PBL instead. Besides being faster and easier
    to use than inferring operating system vendor from TCP options, window
    size, etc., the PBL is mostly a list of IP addresses of Windows boxes.


    Vernon Schryver vjs@rhyolite.com

  5. Re: OS fingerprinting and traffic shaping with iptables?

    On Thu, 22 Mar 2007 18:55:19 -0700, Vernon Schryver wrote:

    > In article ,
    > ray wrote:
    >
    >>> Is it possible to check the OS of the remote clients and to prioritize
    >>> some of the OS with iptables? For instance, is it possible to classify
    >>> and slow down any SMTP connection from a Windows box?

    >>
    >>Even if it is technically feasible, you might want to ask "is it ethical?"

    >
    > Only those who would like to send unsolicited bulk email advertising
    > or newsletters seriously question whether it is ethical to slow down,
    > block, or blacklist spam or any sort of email based on any rules or
    > procedures, no matter how strange or inaccurate. Each of us has the
    > right to do anything with our SMTP servers (mail receiving systems),
    > no matter how stupid it seems to other people.
    >
    > For some U.S. legal precedents, look for old AOL vs. Cyberpromo court
    > cases. See also the CAN-SPAM Act.
    >
    >
    > Some people have reported good results against botnet spam (the current
    > majority) using the Linux TCP client fingerprinting tuned to detect
    > Windows systems. However, I agree with the contributor to this thread
    > who recommend Spamhaus' PBL instead. Besides being faster and easier
    > to use than inferring operating system vendor from TCP options, window
    > size, etc., the PBL is mostly a list of IP addresses of Windows boxes.
    >
    >
    > Vernon Schryver vjs@rhyolite.com


    1) I did not ask if it was legal - just ethical - not much correlation.
    2) You're right - I don't see the sense in throttling all MS machines just
    because you don't like them. I believe that was the OPs thrust.



  6. Re: OS fingerprinting and traffic shaping with iptables?

    In ray:

    [Snip...]

    > I did not ask if it was legal - just ethical - not much correlation.


    When it's trespass on MY personal private property, it's both. There are a
    raft of (mostly useless) laws prohibiting spam; the vast majority of it is
    spew from cracked Windows installs and botnets. What to do?

    IMO, if it's MY property under assault, it's not only legal and ethical to
    RESIST it; it's my DUTY. I may use any legal and nonviolent (because I'm a
    nice guy) means to do so.

    If that means luzer toyware is throttled--too bad; it's not my problem. It
    is about the net, not Unca Bill's delicate sensibilities.

    We already went through this with Hipcrime (etc.) on Usenet years ago. IMO
    there isn't any there, there, about ethics or legality.

    > I don't see the sense in throttling all MS machines just because you don't
    > like them.


    That's beside the point. IMO M$ should either fix their botched toyware to
    make it suitable for the net, or get the hell off the net. In the meantime
    I will not be remembered as the nice guy who just went along with the rape
    of the net by the likes of Monkey Boy and Unca Bill.

    > I believe that was the OPs thrust.


    IMO you're close to blaming victims for the perp's antisocial behavior.

    JMO; YMMV...

    --
    Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
    Pardon any bogus email addresses (wookie) in place for spambots.
    Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
    Kids jumping ship? Looking to hire an old-school type? Email me.

  7. Re: OS fingerprinting and traffic shaping with iptables?

    Vernon Schryver wrote:
    > In article ,
    > ray wrote:
    >
    >>> Is it possible to check the OS of the remote clients and to prioritize
    >>> some of the OS with iptables? For instance, is it possible to classify
    >>> and slow down any SMTP connection from a Windows box?

    >> Even if it is technically feasible, you might want to ask "is it ethical?"

    >
    > Only those who would like to send unsolicited bulk email advertising
    > or newsletters seriously question whether it is ethical to slow down,
    > block, or blacklist spam or any sort of email based on any rules or
    > procedures, no matter how strange or inaccurate. Each of us has the
    > right to do anything with our SMTP servers (mail receiving systems),
    > no matter how stupid it seems to other people.
    >
    > For some U.S. legal precedents, look for old AOL vs. Cyberpromo court
    > cases. See also the CAN-SPAM Act.
    >
    >
    > Some people have reported good results against botnet spam (the current
    > majority) using the Linux TCP client fingerprinting tuned to detect
    > Windows systems. However, I agree with the contributor to this thread
    > who recommend Spamhaus' PBL instead. Besides being faster and easier
    > to use than inferring operating system vendor from TCP options, window
    > size, etc., the PBL is mostly a list of IP addresses of Windows boxes.
    >


    You are implying that windows-sourced smtp traffic is synonymous with
    spam. That is wrong on several levels. While it is undoubtedly true
    that most spam originates on a windows machine, the spam may then pass
    through a linux machine (it is perfectly possible to misconfigure a
    linux box as an open relay). It is also very common for companies to
    have windows-based email servers, sending out legitimate mail. So any
    system that deliberately delays windows-sourced smtp traffic will reduce
    spam rates, but will also delay real email.

    Of course, there are other uses for such shaping based on the source OS.
    You might trust "quality of service" flags from linux machines but not
    windows machines, for example. Or you might just prioritise linux
    clients so that they appear faster than windows clients, thus aiding a
    campaign to move all your companies desktops to linux.




  8. Re: OS fingerprinting and traffic shaping with iptables?

    In article <4603ddb4$0$31516$8404b019@news.wineasy.se>,
    David Brown wrote:

    >You are implying that windows-sourced smtp traffic is synonymous with
    >spam. That is wrong on several levels. While it is undoubtedly true
    >that most spam originates on a windows machine, the spam may then pass
    >through a linux machine (it is perfectly possible to misconfigure a
    >linux box as an open relay).


    "Botnet" or "trojan proxy" spam in general does not use open relays.
    It would be both counterproductive and an unnecessary hassle for a
    spammer using a botnet to funnel spam through an open relay. It
    would be counter-productive for the same reasons that botnets are
    now preferred by spammers over open relays. Open relays are far
    fewer and so more easily detected and blacklisted.

    > It is also very common for companies to
    >have windows-based email servers, sending out legitimate mail. So any
    >system that deliberately delays windows-sourced smtp traffic will reduce
    >spam rates, but will also delay real email.


    That is almost as wrong, except for unsolicited bulk email. Legitimate
    mail is unlikely to be significantly or even noticably delayed by such
    tactics. SMTP client timeouts limit the delays you can impose on
    legitimate SMTP sessions to minutes, as demonstrated by the bad effects
    seen with excessviely long sendmail "greet-pause" delays.

    Those limitations are an other reason why slowing SMTP transactions
    from Microsoft boxes less interesting than other tactics against spam
    such as rejecting mail from unfamiliar (i.e. not whitelisted) Microsoft
    boxes. Slowing SMTP from boxes might help against large dictionary
    attacks in which spammers try SMTP Rcpt_To commands for many thousands
    of possible usernames, although common SMTP servers now have defenses
    against the worst effects of dictionary attacks. Causing individual
    SMTP transactions to take even an hour ("teergrubing") is not effective
    against trojan proxy spam, because there are so many trojan proxies
    that the spammer can afford to out wait than your SMTP server.


    >Of course, there are other uses for such shaping based on the source OS.
    > You might trust "quality of service" flags from linux machines but not
    >windows machines, for example.


    That depends on the assumption that the QOS (or old TOS) bits in IP
    headers have not been changed by routers in the path. It is also
    relatively unusual for a host to care about IP QOS bits. Routers are
    more likely to care, but they are less likely to maintain the state
    needed to guess and use the brand name of the source host. Besides,
    given the excess of anti-clues among Linux users ("facts" they think
    they know and broadcast at volume and that are wrong), it would be wiser
    to ignore QOS bits coming from unfamiliar Linux boxes. (Never mind the
    difficulties in getting Winsock to generate QOS bits.)


    > Or you might just prioritise linux
    >clients so that they appear faster than windows clients, thus aiding a
    >campaign to move all your companies desktops to linux.


    That would be an effort to cause people to think something you know is
    false and so dishonest and unethical.


    Vernon Schryver vjs@rhyolite.com

  9. Re: OS fingerprinting and traffic shaping with iptables?

    Vernon Schryver wrote:
    > In article <4603ddb4$0$31516$8404b019@news.wineasy.se>,
    > David Brown wrote:
    >
    >> You are implying that windows-sourced smtp traffic is synonymous with
    >> spam. That is wrong on several levels. While it is undoubtedly true
    >> that most spam originates on a windows machine, the spam may then pass
    >> through a linux machine (it is perfectly possible to misconfigure a
    >> linux box as an open relay).

    >
    > "Botnet" or "trojan proxy" spam in general does not use open relays.
    > It would be both counterproductive and an unnecessary hassle for a
    > spammer using a botnet to funnel spam through an open relay. It
    > would be counter-productive for the same reasons that botnets are
    > now preferred by spammers over open relays. Open relays are far
    > fewer and so more easily detected and blacklisted.
    >
    >> It is also very common for companies to
    >> have windows-based email servers, sending out legitimate mail. So any
    >> system that deliberately delays windows-sourced smtp traffic will reduce
    >> spam rates, but will also delay real email.

    >
    > That is almost as wrong, except for unsolicited bulk email. Legitimate
    > mail is unlikely to be significantly or even noticably delayed by such
    > tactics. SMTP client timeouts limit the delays you can impose on
    > legitimate SMTP sessions to minutes, as demonstrated by the bad effects
    > seen with excessviely long sendmail "greet-pause" delays.
    >
    > Those limitations are an other reason why slowing SMTP transactions
    > from Microsoft boxes less interesting than other tactics against spam
    > such as rejecting mail from unfamiliar (i.e. not whitelisted) Microsoft
    > boxes. Slowing SMTP from boxes might help against large dictionary
    > attacks in which spammers try SMTP Rcpt_To commands for many thousands
    > of possible usernames, although common SMTP servers now have defenses
    > against the worst effects of dictionary attacks. Causing individual
    > SMTP transactions to take even an hour ("teergrubing") is not effective
    > against trojan proxy spam, because there are so many trojan proxies
    > that the spammer can afford to out wait than your SMTP server.
    >


    If delaying bulk mail helps stop it, while delaying real mail is seldom
    a problem, then why bother trying to identify the OS in the first place?
    I have read of the technique "greylisting", by which any previously
    unknown sender is first greeted with a temporary reject message. Real
    mail servers will try again after a short delay, while most spam bots
    will simply give up on that address - the receiver therefore lets the
    mail through on the second attempt (and whitelists the server to avoid
    the delay in the future).

    But I agree that there are far better ways to identify and block spam,
    which is why I think the whole thread is a little odd.

    >
    >> Of course, there are other uses for such shaping based on the source OS.
    >> You might trust "quality of service" flags from linux machines but not
    >> windows machines, for example.

    >
    > That depends on the assumption that the QOS (or old TOS) bits in IP
    > headers have not been changed by routers in the path. It is also
    > relatively unusual for a host to care about IP QOS bits. Routers are
    > more likely to care, but they are less likely to maintain the state
    > needed to guess and use the brand name of the source host. Besides,
    > given the excess of anti-clues among Linux users ("facts" they think
    > they know and broadcast at volume and that are wrong), it would be wiser
    > to ignore QOS bits coming from unfamiliar Linux boxes. (Never mind the
    > difficulties in getting Winsock to generate QOS bits.)
    >


    I think it is the router's job to determine QOS and traffic shaping
    priorities - I am just trying to think of other reasons for wanting to
    identify the source OS.

    >
    >> Or you might just prioritise linux
    >> clients so that they appear faster than windows clients, thus aiding a
    >> campaign to move all your companies desktops to linux.

    >
    > That would be an effort to cause people to think something you know is
    > false and so dishonest and unethical.
    >


    I should probably have added a smiley at the end of that paragraph - I
    was not being serious!

    >
    > Vernon Schryver vjs@rhyolite.com


  10. Re: OS fingerprinting and traffic shaping with iptables?

    In article <46041a35$0$24618$8404b019@news.wineasy.se>,
    David Brown wrote:

    >> Those limitations are an other reason why slowing SMTP transactions
    >> from Microsoft boxes less interesting than other tactics against spam
    >> such as rejecting mail from unfamiliar (i.e. not whitelisted) Microsoft
    >> boxes. Slowing SMTP from boxes might help against large dictionary
    >> attacks in which spammers try SMTP Rcpt_To commands for many thousands
    >> of possible usernames, although common SMTP servers now have defenses
    >> against the worst effects of dictionary attacks. Causing individual
    >> SMTP transactions to take even an hour ("teergrubing") is not effective
    >> against trojan proxy spam, because there are so many trojan proxies
    >> that the spammer can afford to out wait than your SMTP server.

    >
    >If delaying bulk mail helps stop it, while delaying real mail is seldom
    >a problem, then why bother trying to identify the OS in the first place?


    I didn't intend to say that delaying bulk mail is a good spam filter.
    A defense against a dictionary attack need not be a useful spam filter.

    Delayed bulk mail suffers more delays than non-bulk mail. Slowing down
    an SMTP client trying to deliver 10,000 copies by delaying each copy
    90 seconds might conceivably cause the bulk mailer to give up, without
    detectably slowing non-bulk mail from other SMTP clients. Of course,
    such delays will have more effects on more legitimate bulk mailers,
    for values of "legitimate" including unsolicited bulk mailers that use
    only their own computers instead of botnets and open relays.

    If I were to try to filter spam by identifying the SMTP client, I would
    not just delay mail from Microsoft systems, but reject it if it were
    an unfamiliar (i.e. not locally whitelist) system. As I said earilier,
    I would try to "fingerprint" the SMTP client's operating system only
    if I could not use Spamhaus's PBL, because to a first approximation,
    the PBL is a list of unsanctioned Microsoft SMTP clients.


    > I have read of the technique "greylisting", by which any previously
    >unknown sender is first greeted with a temporary reject message....


    Greylisting is one of those spam defenses, like counting fuzzy checksums
    of mail messages, that should not be effective but are. My take
    on greylisting can be seen at
    http://www.dcc-servers.net/dcc/greylist.html
    See also
    http://www.google.com/search?hl=en&q=greylist
    and
    http://www.google.com/search?hl=en&q=greylisting


    >>> Or you might just prioritise linux
    >>> clients so that they appear faster than windows clients, thus aiding a
    >>> campaign to move all your companies desktops to linux.


    >I should probably have added a smiley at the end of that paragraph - I
    >was not being serious!


    That's a example of why smileyes are bad ideas. Strange punctuation
    neither keeps someone from taking offense at a bad joke nor fixes
    unfortunate or unclear word choices. In this context, many people would
    have understood a smiley to mean something like "I'm grinning because
    that would be such a great thing to do to those #$%$#@! MS fanboys."


    Vernon Schryver vjs@rhyolite.com

  11. Re: OS fingerprinting and traffic shaping with iptables?

    ["Followup-To:" header set to comp.os.linux.misc.]
    On 2007-03-23, Vernon Schryver wrote:
    >
    > If I were to try to filter spam by identifying the SMTP client, I would
    > not just delay mail from Microsoft systems, but reject it if it were
    > an unfamiliar (i.e. not locally whitelist) system. As I said earilier,
    > I would try to "fingerprint" the SMTP client's operating system only
    > if I could not use Spamhaus's PBL, because to a first approximation,
    > the PBL is a list of unsanctioned Microsoft SMTP clients.


    It's not _that_ good an approximation. The PBLs are
    indicscriminate and blindly punish legitimate folks who run
    secure operating systems in proper manner and whose only
    crime is attempting to use SMTP to send email as it was
    intended to be used, directly from one computer to another
    while using residential DSL or FIOS service. Attempts to
    get delisted are entirely futile. PBL creators simply don't
    believe it is possible to send legitimate email directly
    without going through some ISP's "blessed" host.

    A good friend of mine commented, "Spam has broken the
    internet."

    Fortunately, after a lot of searching, I found how to use
    Postfix's transport list to selectively route outbound
    messages based on destination address. The transport list
    contains a "snob list" of destination domains who are too
    snobbish to accept legitimate direct email, and outbound
    messages to those domains is sent through my ISP's
    "outgoing" mail server. Mail to everyone else is sent
    directly as SMTP was/is supposed to work.

    I would have one request for those who use the PBLs to
    blindly reject direct email: Please, at least reject the
    messages during the SMTP session, rather than accepting the
    message and then silently throwing it in /dev/null. If you
    reject the message, then I can add your domain to the snob
    list and resend.

    Flames claiming I should send everything through my ISP's
    "blessed, outgoing" mail server to /dev/null. If I wanted
    it to take many minutes, hours, or maybe days for the
    message to _probably_ get delivered without any ability to
    do "mailq" to check on status, I would do so.

    --
    Robert Riches
    spamtrap42@verizon.net
    (Yes, that is one of my email addresses.)

  12. Re: OS fingerprinting and traffic shaping with iptables?

    In article ,
    Robert M. Riches Jr. wrote:
    >["Followup-To:" header set to comp.os.linux.misc.]


    changed back because this thread has little to do with Linux or any
    particular UNIX-like operating system. The closest reasonable newsgroup
    is in the original list is comp.protocols.tcp-ip. SMTP uses TCP and
    the original question involved guessing operating system brands from
    TCP and IP header values.

    If you want to argue about spam filters and DNSBLs, try
    news.admin.net-abuse.email or news.admin.net-abuse.blocklisting See
    http://www.killfile.org/~tskirvin/nana/
    or
    http://www.google.com/search?q=news.admin.net-abuse


    >> if I could not use Spamhaus's PBL, because to a first approximation,
    >> the PBL is a list of unsanctioned Microsoft SMTP clients.

    >
    >It's not _that_ good an approximation. The PBLs are
    >indicscriminate and blindly punish legitimate folks who run
    >secure operating systems in proper manner and whose only
    >crime is attempting to use SMTP to send email as it was
    >intended to be used, directly from one computer to another
    >while using residential DSL or FIOS service. Attempts to
    >get delisted are entirely futile. PBL creators simply don't
    >believe it is possible to send legitimate email directly
    >without going through some ISP's "blessed" host.


    That is a bunch of silly anti-clues starting with the confusion between
    Spamhaus's Policy Block List and the more general notion of a DNSBL or
    DNS blacklist or "blocklist." See
    http://www.google.com/search?q=dnsbl

    Individual users of IP addresses that should not be in Spamhaus' PBL
    can remove them instantly, subject to defenses against obvious abuses.
    http://www.spamhaus.org/pbl/index.lasso

    Additional nonsense involves the notion that the services sold by
    residential providers to home lusers with explicit prohibitions in
    contracts against "servers" are the same as real Internet services.

    Then there is the notion that paying less than what real Internet service
    costs entitles a consumer to real Internet service. Real Internet
    services cost more and so are priced higher, because the provider must
    do more, starting with actually paying attention to reports of abuse
    of the network.

    There is also the odd notion that when consumer ISPs register their
    own blocks of consumer IP addresses with Spamhaus for inclusion in the
    PBL, Spamhaus is being "indiscriminate." I wouldn't even go so far
    as saying the other, "dynamic IP address" DNSBLs that are based on
    what I call "name magic" (reverse DNS names) are "indiscriminate."



    >I would have one request for those who use the PBLs to
    >blindly reject direct email: Please, at least reject the
    >messages during the SMTP session, rather than accepting the
    >message and then silently throwing it in /dev/null. If you
    >reject the message, then I can add your domain to the snob
    >list and resend.


    Reasonable spam filters never silently discard anything, which leaves
    the choice between rejecting spam during the original SMTP transaction
    or sending an NDR or "bounce" later. Rejecting spam during the original
    SMTP transaction is a good idea if you want to keep your IP addresses
    out of DNSBLs. Sending enough bounces can get you blacklisted, because
    many of them will go to innocent third parties whose addresses have
    been forged as return addresses.


    >Flames claiming I should send everything through my ISP's
    >"blessed, outgoing" mail server to /dev/null. If I wanted
    >it to take many minutes, hours, or maybe days for the
    >message to _probably_ get delivered without any ability to
    >do "mailq" to check on status, I would do so.


    As far as I'm concerned you are free to violate your contract with
    your ISP. However, your ISP is at least as free to deal with those
    violations with the usual sanctions ranging from installing port 25
    filters in its routers to terminating your account to suing you.

    There aint no such thing as a free lunch,
    and those who think they are entitled to freebies deserve worse than
    what they get. To a first approximation, the spam problem is due
    entirely to any one of the following:

    - ISPs that don't feel obligated to police their own users, starting
    with terminating any account of any user caught running a Microsoft
    abuse vector and charging an honest clean-up fee for re-instatement.
    (Take one of the estimates of global costs of spam, divide by an active
    botnet population number, and you get a value of well over $100 and
    possibly even more than $1000.)

    - users who don't feel obligated to ensure that their systems never
    send spam, DoS packets, or other abuse

    - The Tragedy of the Commons


    Vernon Schryver vjs@rhyolite.com

  13. Re: OS fingerprinting and traffic shaping with iptables?

    On Fri, 23 Mar 2007, Vernon Schryver wrote:
    > Additional nonsense involves the notion that the services sold by
    > residential providers to home lusers with explicit prohibitions in
    > contracts against "servers" are the same as real Internet services.
    >
    > Then there is the notion that paying less than what real Internet service
    > costs entitles a consumer to real Internet service. Real Internet
    > services cost more and so are priced higher, because the provider must
    > do more, starting with actually paying attention to reports of abuse
    > of the network.


    Speaking as someone who pays a premium for real Internet service,
    including static IP addresses and the privilege of running servers, I
    wholeheartedly agree with what Vernon says here.

    People who use outgoing-SMTP on a "home user" Internet connection are, in
    effect, stealing from those who pay for real Internet service. So do
    people who run servers, although I am somewhat more sanguine on this
    point.

    The sooner that the privilege of connecting to port 25 is restricted to
    those who pay for real Internet service, the better. It's coming.

    In fact, I'll go further and say that, by treaty, the privilege of
    connecting to port 25 should be licensed, authenticated, and taxed by the
    relevant national authorities. I'll happily pay a tax for my outgoing
    port 25 connections if I knew that the entity connecting to my incoming
    port 25 was also paying.

    -- Mark --

    http://staff.washington.edu/mrc
    Science does not emerge from voting, party politics, or public debate.
    Si vis pacem, para bellum.

  14. Re: OS fingerprinting and traffic shaping with iptables?


    "Mark Crispin" wrote in message
    news:alpine.WNT.0.83.0703231643200.3536@Shimo-Tomobiki.Panda.COM...
    : On Fri, 23 Mar 2007, Vernon Schryver wrote:
    : > Additional nonsense involves the notion that the services sold by
    : > residential providers to home lusers with explicit prohibitions in
    : > contracts against "servers" are the same as real Internet services.
    : >
    : > Then there is the notion that paying less than what real Internet
    service
    : > costs entitles a consumer to real Internet service. Real Internet
    : > services cost more and so are priced higher, because the provider must
    : > do more, starting with actually paying attention to reports of abuse
    : > of the network.
    :
    : Speaking as someone who pays a premium for real Internet service,
    : including static IP addresses and the privilege of running servers, I
    : wholeheartedly agree with what Vernon says here.
    :
    : People who use outgoing-SMTP on a "home user" Internet connection are, in
    : effect, stealing from those who pay for real Internet service. So do
    : people who run servers, although I am somewhat more sanguine on this
    : point.
    :
    : The sooner that the privilege of connecting to port 25 is restricted to
    : those who pay for real Internet service, the better. It's coming.
    :
    : In fact, I'll go further and say that, by treaty, the privilege of
    : connecting to port 25 should be licensed, authenticated, and taxed by the
    : relevant national authorities. I'll happily pay a tax for my outgoing
    : port 25 connections if I knew that the entity connecting to my incoming
    : port 25 was also paying.
    :
    Use port 110, its free (as in you paid for it).



  15. Re: OS fingerprinting and traffic shaping with iptables?

    In article ,
    MikE Šampbell wrote:

    >: The sooner that the privilege of connecting to port 25 is restricted to
    >: those who pay for real Internet service, the better. It's coming.


    >Use port 110, its free (as in you paid for it).


    Telling someone to "Use port 110, its free (as in you paid for it)"
    is like advising someone to "Tell the bus driver to take you home."
    It can be good advice, unless it is being given to the bus driver
    instead of a passenger, in which case it suggests confusion or
    limited familiarity with the subject matter.

    Real Internet service generally does not include POP service, except
    when a consumer account is included at no extra cost. Real Internet
    service is raw, unfiltered IP bandwidth and little if anything more.
    You are expected to be the bus driver, or network and system administrator.
    It generally comes without any other services except sometimes reverse
    DNS for the IP addresses and perhaps inclusion of the IP addresses in
    a BGP AS. It is neither "shared hosting" nor part of a package that
    includes plain old telephone service and a subscription to HBO. It is
    about as useful and interesting to most Internet users as the class C
    driver's license required to drive a bus in the U.S. See
    http://www.fmcsa.dot.gov/registratio...ng/cdl/cdl.htm

    Of course, that doesn't stop zillions of Cliff Clavins ranting about
    the unfair, indicscriminate, punishing restrictions on their basic
    human right to drive whatever, whenever, and wherever they want. See
    http://www.google.com/search?q=%22Cliff+Clavin%22


    Vernon Schryver vjs@rhyolite.com

  16. Re: OS fingerprinting and traffic shaping with iptables?

    totojepast wrote:
    > Is it possible to check the OS of the remote clients and to prioritize
    > some of the OS with iptables? For instance, is it possible to classify
    > and slow down any SMTP connection from a Windows box?
    >

    Tell us what problem you're trying to solve and we may be able to help.

    Asking about throttling smtp connections depending on the OS without
    saying what you're trying to achieve by doing it is a waste of
    everybody's time.

    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |

  17. Re: OS fingerprinting and traffic shaping with iptables?

    Vernon Schryver wrote:
    > In article <46041a35$0$24618$8404b019@news.wineasy.se>,
    > David Brown wrote:
    >
    >>> Those limitations are an other reason why slowing SMTP transactions
    >>> from Microsoft boxes less interesting than other tactics against spam
    >>> such as rejecting mail from unfamiliar (i.e. not whitelisted) Microsoft
    >>> boxes. Slowing SMTP from boxes might help against large dictionary
    >>> attacks in which spammers try SMTP Rcpt_To commands for many thousands
    >>> of possible usernames, although common SMTP servers now have defenses
    >>> against the worst effects of dictionary attacks. Causing individual
    >>> SMTP transactions to take even an hour ("teergrubing") is not effective
    >>> against trojan proxy spam, because there are so many trojan proxies
    >>> that the spammer can afford to out wait than your SMTP server.

    >> If delaying bulk mail helps stop it, while delaying real mail is seldom
    >> a problem, then why bother trying to identify the OS in the first place?

    >
    > I didn't intend to say that delaying bulk mail is a good spam filter.
    > A defense against a dictionary attack need not be a useful spam filter.
    >


    That's certainly true, but entirely independent of the OS.

    > Delayed bulk mail suffers more delays than non-bulk mail. Slowing down
    > an SMTP client trying to deliver 10,000 copies by delaying each copy
    > 90 seconds might conceivably cause the bulk mailer to give up, without
    > detectably slowing non-bulk mail from other SMTP clients. Of course,
    > such delays will have more effects on more legitimate bulk mailers,
    > for values of "legitimate" including unsolicited bulk mailers that use
    > only their own computers instead of botnets and open relays.
    >
    > If I were to try to filter spam by identifying the SMTP client, I would
    > not just delay mail from Microsoft systems, but reject it if it were
    > an unfamiliar (i.e. not locally whitelist) system. As I said earilier,
    > I would try to "fingerprint" the SMTP client's operating system only
    > if I could not use Spamhaus's PBL, because to a first approximation,
    > the PBL is a list of unsanctioned Microsoft SMTP clients.
    >


    I still don't think that treating every windows system as a spam source
    is reasonable, even if you are unable to use a more accurate blacklist
    such as Spamhaus. While most addresses on that list belong to windows
    machines, many windows mail servers are not spam sources - spam checking
    should always err on the side of letting through spam rather than
    blocking legitimate mail.

    >
    >> I have read of the technique "greylisting", by which any previously
    >> unknown sender is first greeted with a temporary reject message....

    >
    > Greylisting is one of those spam defenses, like counting fuzzy checksums
    > of mail messages, that should not be effective but are. My take
    > on greylisting can be seen at
    > http://www.dcc-servers.net/dcc/greylist.html


    That is useful reading - thanks!

    > See also
    > http://www.google.com/search?hl=en&q=greylist
    > and
    > http://www.google.com/search?hl=en&q=greylisting
    >
    >
    >>>> Or you might just prioritise linux
    >>>> clients so that they appear faster than windows clients, thus aiding a
    >>>> campaign to move all your companies desktops to linux.

    >
    >> I should probably have added a smiley at the end of that paragraph - I
    >> was not being serious!

    >
    > That's a example of why smileyes are bad ideas. Strange punctuation
    > neither keeps someone from taking offense at a bad joke nor fixes
    > unfortunate or unclear word choices. In this context, many people would
    > have understood a smiley to mean something like "I'm grinning because
    > that would be such a great thing to do to those #$%$#@! MS fanboys."
    >


    Fair enough - sometimes it is easy to forget that there are people out
    there who really think like that, and thus my comment could be
    interpreted that way.

    >
    > Vernon Schryver vjs@rhyolite.com


  18. Re: OS fingerprinting and traffic shaping with iptables?

    In article <46054bf7$0$22541$8404b019@news.wineasy.se>,
    David Brown wrote:

    >> If I were to try to filter spam by identifying the SMTP client, I would
    >> not just delay mail from Microsoft systems, but reject it if it were
    >> an unfamiliar (i.e. not locally whitelist) system. As I said earilier,
    >> I would try to "fingerprint" the SMTP client's operating system only
    >> if I could not use Spamhaus's PBL, because to a first approximation,
    >> the PBL is a list of unsanctioned Microsoft SMTP clients.

    >
    >I still don't think that treating every windows system as a spam source
    >is reasonable, even if you are unable to use a more accurate blacklist
    >such as Spamhaus. While most addresses on that list belong to windows
    >machines, many windows mail servers are not spam sources - spam checking
    >should always err on the side of letting through spam rather than
    >blocking legitimate mail.


    As they say "Your network, your rules."

    Perhaps I should mention that I use neither the PBL nor O/S fingerprinting.
    But then perhaps I should say that I don't use the PBL because it
    includes legitimate DNS servers such as Comcasts and that I like to
    check MX, NS, and A RRs seen in SMTP envelopes and bodies.

    People whose livelihoods depend in part on receiving mail tend to
    prefer false negatives to false positives. People for whom email
    is recreation often prefer not receiving any spam. Many of them
    would be best served by a pure whitelisting system, where they can
    receive email by pre-arrangement. People for whom mail and the
    Internet in general doesn't involve their income tend to buy consumer
    grade intead of real Internet service.

    It has belatedly occurred to me to point out the official IETF
    standard definition of real Internet service in RFC 4084. Never mind
    that for political reasons it uses "Full Internet Connectivity." See
    http://www.ietf.org/rfc/rfc4084.txt


    Vernon Schryver vjs@rhyolite.com

  19. Re: OS fingerprinting and traffic shaping with iptables?

    On Fri, 23 Mar 2007, Vernon Schryver wrote:
    > In article ,
    > MikE ?ampbell wrote:
    >> Use port 110, its free (as in you paid for it).

    > Telling someone to "Use port 110, its free (as in you paid for it)"
    > is like advising someone to "Tell the bus driver to take you home."
    > It can be good advice, unless it is being given to the bus driver
    > instead of a passenger, in which case it suggests confusion or
    > limited familiarity with the subject matter.


    True; and it's even sillier to give that advice to someone who is in the
    manufactures buses. [I wrote one of the more widely-used port 110
    servers.]

    In any case, port 110 (POP3) is not a substitute for port 25 (SMTP); the
    mail sending capabilities in some POP3 servers is an unofficial hack,
    based upon the presumption that authorization to read mail is equivalent
    to authorization to send mail. The substitute is port 587 (SUBMISSION),
    which requires authentication.

    > Real Internet service generally does not include POP service, except
    > when a consumer account is included at no extra cost. Real Internet
    > service is raw, unfiltered IP bandwidth and little if anything more.


    Complete agreement!

    -- Mark --

    http://panda.com/mrc
    Democracy is two wolves and a sheep deciding what to eat for lunch.
    Liberty is a well-armed sheep contesting the vote.

  20. Re: OS fingerprinting and traffic shaping with iptables?

    Vernon Schryver wrote:
    > In article <46054bf7$0$22541$8404b019@news.wineasy.se>,
    > David Brown wrote:
    >
    >>> If I were to try to filter spam by identifying the SMTP client, I would
    >>> not just delay mail from Microsoft systems, but reject it if it were
    >>> an unfamiliar (i.e. not locally whitelist) system. As I said earilier,
    >>> I would try to "fingerprint" the SMTP client's operating system only
    >>> if I could not use Spamhaus's PBL, because to a first approximation,
    >>> the PBL is a list of unsanctioned Microsoft SMTP clients.

    >> I still don't think that treating every windows system as a spam source
    >> is reasonable, even if you are unable to use a more accurate blacklist
    >> such as Spamhaus. While most addresses on that list belong to windows
    >> machines, many windows mail servers are not spam sources - spam checking
    >> should always err on the side of letting through spam rather than
    >> blocking legitimate mail.

    >
    > As they say "Your network, your rules."
    >


    Of course - but I am always interested in listening to more experienced
    people for ideas, opinions, and advice.

    > Perhaps I should mention that I use neither the PBL nor O/S fingerprinting.


    My interest in this thread was curiosity as to whether OS fingerprinting
    was a useful technique - whether to help block spam, or for any other
    legitimate purpose. It looks like it is not useful - anything it could
    help with, can be done better in other ways.

    > But then perhaps I should say that I don't use the PBL because it
    > includes legitimate DNS servers such as Comcasts and that I like to
    > check MX, NS, and A RRs seen in SMTP envelopes and bodies.
    >
    > People whose livelihoods depend in part on receiving mail tend to
    > prefer false negatives to false positives. People for whom email
    > is recreation often prefer not receiving any spam. Many of them
    > would be best served by a pure whitelisting system, where they can
    > receive email by pre-arrangement. People for whom mail and the
    > Internet in general doesn't involve their income tend to buy consumer
    > grade intead of real Internet service.
    >


    Email is increasingly important for everyday use. At the office, my
    livelihood depends on email. At home, my way of life depends on it. I
    don't know how things are in your country, but here in Norway it is
    common for email to be an essential part of the way people receive
    information. When I get a bill, I am informed by email. When I buy a
    plane ticket, it is sent as a pdf in an email, for me to print out
    myself. If I ever win in the lottery, I'll be informed by email. Email
    is a service like telephones - you can live without them for a while,
    but they are an integral part of everyday life.

    However, I fully agree on the difference in quality and expectations of
    service and reliability between professional internet connections and
    home connections. I would be far happier if ISPs were obliged to block
    all SMTP traffic from home connections that was not directed through
    their own SMTP relay.


    > It has belatedly occurred to me to point out the official IETF
    > standard definition of real Internet service in RFC 4084. Never mind
    > that for political reasons it uses "Full Internet Connectivity." See
    > http://www.ietf.org/rfc/rfc4084.txt
    >


    I shall read it shortly.

    mvh.,

    David


    >
    > Vernon Schryver vjs@rhyolite.com


+ Reply to Thread
Page 1 of 2 1 2 LastLast