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?

> 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).

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?"

In article <(E-Mail Removed)>,
ray <(E-Mail Removed)> 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 (E-Mail Removed)

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

> In article <(E-Mail Removed)>,
> ray <(E-Mail Removed)> 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 (E-Mail Removed)

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.

In <(E-Mail Removed)> 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.

Vernon Schryver wrote:
> In article <(E-Mail Removed)>,
> ray <(E-Mail Removed)> 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.

In article <4603ddb4$0$31516$(E-Mail Removed)>,
David Brown <(E-Mail Removed)> 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 (E-Mail Removed)

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 |

Vernon Schryver wrote:
> In article <4603ddb4$0$31516$(E-Mail Removed)>,
> David Brown <(E-Mail Removed)> 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 (E-Mail Removed)