Thoughts about restricting outgoing communication

The more I think about this issue I am convinced it can be done and
encourage comments about why it can not be done.

First I admit it would require intimate knowledge of TCP/IP
communication protocols; especially at a lower level.

Second, signivicant increases in software and hence hardware resources
would be required.

Lastly, total knowledge of the operating system (especially Vista, but
even Windows) and its corresponding drivers and wrappers. It also
would require total knowledge of layered software applications. Some
of which may have to be customized per application.

Now what reasons are individuals trying to accomplish these
limitations? I suspect they are at a minimum:

1. Malicous software
2. Privacy issues - I bought it but do not feel I give
suppliers/corporations the right to transmit unauthorized
data/information.
3. I have a right to know what is transmitted
4. It may be cracked software attempting to call home (This is the one
nobody likes to say out loud)

Ok, let the comments come and of course Sebastian will have plenty of
criticism as well.

Re: Thoughts about restricting outgoing communication

Post removed (X-No-Archive: yes)

Re: Thoughts about restricting outgoing communication

Predictable grandstanding from someone who spends the bulk of their
time consuming bandwidth with his dribble. It's one thing to have
knowledge and another to know when and how to use it.

And here's a surprise; I don't need a firewall to delete any of your
comments henceforth.

On Tue, 12 Dec 2006 23:35:26 +0100, Sebastian Gottschalk
wrote:

>Let's Think About This wrote:
>
>> Lastly, total knowledge of the operating system (especially Vista, but
>> even Windows) and its corresponding drivers and wrappers. It also
>> would require total knowledge of layered software applications. Some
>> of which may have to be customized per application.
>
>And that's where you're doomed to fail. There are various unauthenticated
>IPC protocols in Windows that allow you to 'remote' control any other
>application.
>
>> Now what reasons are individuals trying to accomplish these
>> limitations? I suspect they are at a minimum:
>>
>> 1. Malicous software
>
>See above: you lost.
>
>> 2. Privacy issues - I bought it but do not feel I give
>> suppliers/corporations the right to transmit unauthorized
>> data/information.
>
>That's identical to #1.
>
>> 3. I have a right to know what is transmitted
>
>Well, that's a job for WireShark. No need for any HBPF. At any rate, you
>know what encryption is?
>
>> 4. It may be cracked software attempting to call home (This is the one
>> nobody likes to say out loud)
>
>That's identical to #1 and #3.

Re: Thoughts about restricting outgoing communication

Let's Think About This wrote:
> The more I think about this issue I am convinced it can be done and
> encourage comments about why it can not be done.

Sure it can be done. It just can't be done without seriously breaking
Windows in its current state. You'd have to re-design the entire
windowing system and remove all the legacy options to remotely control
other software (e.g. DDE and OLE).

> First I admit it would require intimate knowledge of TCP/IP
> communication protocols; especially at a lower level.

Inspecting network traffic has several problems:

- You have to deal with *many* different protocols.
- You have to deal with protocol encapsulation.
- You have to deal with encryption.
- You have to deal with steganography.

You'd have to proxy every single application layer protocol, which will
make your filter very complex and thus very likely to have bugs.

> Second, signivicant increases in software and hence hardware resources
> would be required.

Most definitely. Which leads to the question: why would one want to
waste significant amounts of the system's resources on controlling
applications you don't trust instead of just not running applications
you don't trust?

> Lastly, total knowledge of the operating system (especially Vista, but
> even Windows) and its corresponding drivers and wrappers. It also
> would require total knowledge of layered software applications. Some
> of which may have to be customized per application.

Knowledge alone is not enough. You'd need to change the way the
windowing system works and remove lots of legacy code. Which would
probably be a re-write.

> Now what reasons are individuals trying to accomplish these
> limitations? I suspect they are at a minimum:
>
> 1. Malicous software
> 2. Privacy issues - I bought it but do not feel I give
> suppliers/corporations the right to transmit unauthorized
> data/information.
> 3. I have a right to know what is transmitted
> 4. It may be cracked software attempting to call home (This is the one
> nobody likes to say out loud)

The question is not whether these are valid reasons or not, but whether
it's possible to achieve the desired effect without having to waste
system resources on controlling software.

1. The best way to deal with malicious software is - of course - not to
run it in the first place. Software Restriction Policies, disabling
autoruns and AV software help with that.
=> no real need for outbound control
2. If the vendor of the software isn't trustworthy: why do you give him
money and use his software in the first place? Am I really the only
one considering this a rather stupid thing to do? Besides, most
software that is said to be "phoning home" can simply be configured
to not "phone home", because all it does is checking for updates
(which is a good thing to do, as it helps mitigating risks).
=> no real need for outbound control either
3. True. However, are you capable of understanding what's transmitted?
If you are, then a communication log can be a useful thing. However,
most users of personal firewalls aren't capable of understanding what
is transmitted (which is why the use a personal firewall in the first
place), so they can't make any sensible decision based on the
information in the communication log. Plus, the logs of personal
firewalls tend to be rather incomplete, to say the least. There are
ways (TCPView/netstat, Wireshark, Port Reporter) to achieve this
effect without (or at least with less of) the usual downsides of
personal firewalls.
=> no need for outbound control, though it may be helpful to the
initiate (if implemented in a sensible way)
4. Well, buy the software you're using. Period. Problem solved.
=> no reason at all for outbound control

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: Thoughts about restricting outgoing communication

Let's Think About This wrote:

snip.... of which may have to be customized per application.
>
> Now what reasons are individuals trying to accomplish these
> limitations? I suspect they are at a minimum:
snip...
>
4. It may be cracked software attempting to call home (This is the one
> nobody likes to say out loud)
snip...

I have been looking for ways to prevent my '_legitimate'_ software from
phoning home on my new HP DV8310 laptop.
Cracked software be damned...If i use cracked software I expect to take
what comes but when i purchase a preloaded computer and the manuf steals
my connection to mine my data from 135 'trusted apps.....
Sheesh, I think i am ranting!
Can I play of i promise to get along?
Miffed
PS, Sebastien has been helping me as we parry and thrust thru the other
forums.

Re: Thoughts about restricting outgoing communication

Ansgar -59cobalt- Wiechers wrote:

> Let's Think About This wrote:
>
>>The more I think about this issue I am convinced it can be done and
>>encourage comments about why it can not be done.
>
>
> Sure it can be done. It just can't be done without seriously breaking
> Windows in its current state. You'd have to re-design the entire
> windowing system and remove all the legacy options to remotely control
> other software (e.g. DDE and OLE).
snip.......
> cu
> 59cobalt

I agree with many of your points, a few I don't like "buy trusted
software". MS was trusted once...this is a long long long topic best
suited for drunken diatribes.

Is it any better to adopt the newer lowcost [or free] virtual
environments and circumvent the majority of unsolvable subtrifuges
inherent in MS OSs? By adopting i mean 'sandboxing' so as to get the
flexibility and hardware benefits of say MS-XP, but retain the ultimate
control over what gets out of the box? EG; XP within Redhat?

OR:Win95lite within redhat? you'd lose the 'hardware' advantage but gain
a less complex kernel environment no? Cripes, i still have my DOS3.1
diskettes and my BASIC files....and that 8088 in the corner....
Ok. I digressed.

Miffed

Re: Thoughts about restricting outgoing communication

Post removed (X-No-Archive: yes)

Re: Thoughts about restricting outgoing communication

Sebastian Gottschalk wrote:

> warf wrote:
>
>
>>By adopting i mean 'sandboxing' so as to get the
>>flexibility and hardware benefits of say MS-XP, but retain the ultimate
>>control over what gets out of the box? EG; XP within Redhat?
>
>
> Where exactly are the hardware benefits over virtualized hardware? And when
> you let it access the real hardware, you don't retain control.

I am promulgating not from a well established perspective with
programming savvy...I postulate based solely on the limited knowledge I
am acquiring as i evolve into a geek and dissolve my physical social
contact in favor of the virtual environs whereof i speak..ah, type to
this seemingly inteligent and interactive newsbot.

That said [tongue in cheek in case it be taken flamingly], I tried going
the Redhat route many years ago and found that the hardware support was
far outstripped by the software advantage. The advantage i was referring
to was the availability of intel based hardware, peripherals and drivers
on the discount and freeware market vs...what may be a misconception as
to the Linux hardware support these days.

Is this not an issue then? And are the security claims of Virt-OS not as
tight as I imagined?
I imagined that any calls to the kernel were made indirectly via the
virtOS and could be metered or redirected much the same way a rootkit
would do without our consent???
Miffy.

Re: Thoughts about restricting outgoing communication

warf wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> Let's Think About This wrote:
>>> The more I think about this issue I am convinced it can be done and
>>> encourage comments about why it can not be done.
>>
>> Sure it can be done. It just can't be done without seriously breaking
>> Windows in its current state. You'd have to re-design the entire
>> windowing system and remove all the legacy options to remotely
>> control other software (e.g. DDE and OLE).
>
> I agree with many of your points, a few I don't like "buy trusted
> software".

I said "don't use software you don't trust" and "pay for the stuff you
use if the vendor doesn't give it for free". That's not the same as "buy
trusted software". Not even remotely.

> MS was trusted once...this is a long long long topic best suited for
> drunken diatribes.

There isn't really much to be said about that. If you don't trust a
vendor: don't use their software. Period. Whether you do or don't want
to trust someone is entirely up to you.

> Is it any better to adopt the newer lowcost [or free] virtual
> environments and circumvent the majority of unsolvable subtrifuges
> inherent in MS OSs?

To achieve what?

> By adopting i mean 'sandboxing' so as to get the flexibility and
> hardware benefits of say MS-XP, but retain the ultimate control over
> what gets out of the box? EG; XP within Redhat?

You can use virtualization to control what's going in and coming out of
the box, yes. However, that doesn't give you any more control about
what's going on *inside* the box. Thus a sandbox may or may not help
solving your problem, depending on your actual requirements.

> OR:Win95lite within redhat? you'd lose the 'hardware' advantage but
> gain a less complex kernel environment no?

I haven't used it, so I can't comment on it. However, I doubt I'd feel
very comfortable using something that has "win95" in its name.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: Thoughts about restricting outgoing communication

Ansgar -59cobalt- Wiechers wrote:

> warf wrote:
snip...>
>>I agree with many of your points, a few I don't like "buy trusted
>>software".
>
> I said "don't use software you don't trust" and "pay for the stuff you
> use if the vendor doesn't give it for free". That's not the same as "buy
> trusted software". Not even remotely.

K, that's clear as ascii now.

snip..
>>Is it any better to adopt the newer lowcost [or free] virtual
>>environments and circumvent the majority of unsolvable subtrifuges
>>inherent in MS OSs?
>
>
> To achieve what?

To have a modicum of control over the data leaving ones' computer whilst
connected to the 'world'.
Please understand I am actually looking for your advice...

>>By adopting i mean 'sandboxing' so as to get the flexibility and
>>hardware benefits of say MS-XP, but retain the ultimate control over
>>what gets out of the box? EG; XP within Redhat?
>
>
> You can use virtualization to control what's going in and coming out of
> the box, yes. However, that doesn't give you any more control about
> what's going on *inside* the box. Thus a sandbox may or may not help
> solving your problem, depending on your actual requirements.

Ok; seems onerous to simply have the house keys in 'my' pocket without
the 3rd degree in comp-Sci and youthful exuberance. I suspect that I
will really only ever be able to keep my data from casual
abuse...concerted and persistent parties will always prevail and I
s'pose my data is not so valuable that I should care...beyond the
illusion I have autonomy.....?

>
>>OR:Win95lite within redhat? you'd lose the 'hardware' advantage but
>>gain a less complex kernel environment no?
>
>
> I haven't used it, so I can't comment on it. However, I doubt I'd feel
> very comfortable using something that has "win95" in its name.

Sure, i was thinking only from a small[er] footprint, lower obfuscation
sophistication, well revealed known exploit potential, time proven
unworthiness[i jest, kind of]...since knowing the vulnerabilities is as
important as assuming tech~ superiority no?
I thought it is easier for a late [slow] starter in inet
security/privacy with a desire [like me] to understand a small[er]
kernel stripped of the foliage [OE,IE] to control the workings at a
lower level than the overwhelming layered and linked system that is XP
and...HP.
perhaps that is a new thread?
warf.

> cu
> 59cobalt

Re: Thoughts about restricting outgoing communication

warf wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> warf wrote:
>>> Is it any better to adopt the newer lowcost [or free] virtual
>>> environments and circumvent the majority of unsolvable subtrifuges
>>> inherent in MS OSs?
>>
>> To achieve what?
>
> To have a modicum of control over the data leaving ones' computer whilst
> connected to the 'world'.

If you're "sandboxing" an entire operating environment instead of single
processes it won't give you any more control than proxying/inspecting
the traffic on a router. You'd still have to deal with the problems I
lined out in my initial post.

>>> By adopting i mean 'sandboxing' so as to get the flexibility and
>>> hardware benefits of say MS-XP, but retain the ultimate control over
>>> what gets out of the box? EG; XP within Redhat?
>>
>> You can use virtualization to control what's going in and coming out
>> of the box, yes. However, that doesn't give you any more control
>> about what's going on *inside* the box. Thus a sandbox may or may not
>> help solving your problem, depending on your actual requirements.
>
> Ok; seems onerous to simply have the house keys in 'my' pocket without
> the 3rd degree in comp-Sci and youthful exuberance. I suspect that I
> will really only ever be able to keep my data from casual abuse...
> concerted and persistent parties will always prevail and I s'pose my
> data is not so valuable that I should care...beyond the illusion I
> have autonomy.....?

Yes. No. Maybe. Whatever. 42.

I can't give you a simple answer to a question that broad.

>>> OR:Win95lite within redhat? you'd lose the 'hardware' advantage but
>>> gain a less complex kernel environment no?
>>
>> I haven't used it, so I can't comment on it. However, I doubt I'd
>> feel very comfortable using something that has "win95" in its name.
>
> Sure, i was thinking only from a small[er] footprint, lower
> obfuscation sophistication, well revealed known exploit potential,
> time proven unworthiness[i jest, kind of]...since knowing the
> vulnerabilities is as important as assuming tech~ superiority no?

It depends on what you are actually trying to achieve. A small footprint
usually is a good thing, because it means fewer bugs. However, Win9x
does not have user separation, which may or may not rule it out as a
solution, depending on your problem.

> I thought it is easier for a late [slow] starter in inet
> security/privacy with a desire [like me] to understand a small[er]
> kernel stripped of the foliage [OE,IE] to control the workings at a
> lower level than the overwhelming layered and linked system that is XP
> and...HP.

I don't think that something like win95lite is really going to help with
that. I'd say the first thing you need to understand is the fundamentals
of operating systems (kernel, processes, memory management, files,
filesystems, ...) and networks (Ethernet, TCP/IP, ports, sockets, OSI-
layers, major application layer protocols, ...). That's the basis for
making any even halfway educated decision security-wise. IMHO.

> perhaps that is a new thread?

Perhaps.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: Thoughts about restricting outgoing communication

Ansgar -59cobalt- Wiechers wrote:

> warf wrote:
snip...
>>I thought it is easier for a late [slow] starter in inet
>>security/privacy with a desire [like me] to understand a small[er]
>>kernel stripped of the foliage [OE,IE] to control the workings at a
>>lower level than the overwhelming layered and linked system that is XP
>>and...HP.
>
>
> I don't think that something like win95lite is really going to help with
> that. I'd say the first thing you need to understand is the fundamentals
> of operating systems (kernel, processes, memory management, files,
> filesystems, ...) and networks (Ethernet, TCP/IP, ports, sockets, OSI-
> layers, major application layer protocols, ...). That's the basis for
> making any even halfway educated decision security-wise. IMHO.

I'm getting right on it....next week I'll have a few questions
[grin.....sigh]

Maybe it would be more practicle to put that effort into Linux?
Seriously, I am led to believe many programmers are sloppy because
'they' don;t understand anything but GUI level programming...which means
bloated code and vulnerabilities due to the shear number of routines and ???

I am ashamed to say I got a few A's in the few elective courses I took
en-route to my MSc chem....shoulda coulda woulda. Maybe I can sue my
profs for allowing me to move on in ignorance!

Seriously....>Linux?

>>perhaps that is a new thread?
>
>
> Perhaps.

Certainly. Thanks for letting me down easy...
Toast.

> cu
> 59cobalt

Re: Thoughts about restricting outgoing communication

warf wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> warf wrote:
>>> I thought it is easier for a late [slow] starter in inet
>>> security/privacy with a desire [like me] to understand a small[er]
>>> kernel stripped of the foliage [OE,IE] to control the workings at a
>>> lower level than the overwhelming layered and linked system that is
>>> XP and...HP.
>>
>> I don't think that something like win95lite is really going to help
>> with that. I'd say the first thing you need to understand is the
>> fundamentals of operating systems (kernel, processes, memory
>> management, files, filesystems, ...) and networks (Ethernet, TCP/IP,
>> ports, sockets, OSI- layers, major application layer protocols, ...).
>> That's the basis for making any even halfway educated decision
>> security-wise. IMHO.
>
> I'm getting right on it....next week I'll have a few questions
> [grin.....sigh]
>
> Maybe it would be more practicle to put that effort into Linux?

You may find it easier on Linux (or maybe a *BSD), because Microsoft
tends to make things overly complicated, and with Linux you also have
the source code (given you're capable of understanding it). However,
it's not really dependant on the operating system. I learned the basics
on Windows before doing my first steps with Linux.

cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: Thoughts about restricting outgoing communication

Ansgar -59cobalt- Wiechers wrote:

> warf wrote:
>
>>Ansgar -59cobalt- Wiechers wrote:
>>
>>>warf wrote:
>>>
>>>>I thought it is easier for a late [slow] starter in inet
>>>>security/privacy with a desire [like me] to understand a small[er]
>>>>kernel stripped of the foliage [OE,IE] to control the workings at a
>>>>lower level than the overwhelming layered and linked system that is
>>>>XP and...HP.
>>>
>>>I don't think that something like win95lite is really going to help
>>>with that. I'd say the first thing you need to understand is the
>>>fundamentals of operating systems (kernel, processes, memory
>>>management, files, filesystems, ...) and networks (Ethernet, TCP/IP,
>>>ports, sockets, OSI- layers, major application layer protocols, ...).
>>>That's the basis for making any even halfway educated decision
>>>security-wise. IMHO.
>>
>>I'm getting right on it....next week I'll have a few questions
>>[grin.....sigh]
>>
>>Maybe it would be more practicle to put that effort into Linux?
>
>
> You may find it easier on Linux (or maybe a *BSD), because Microsoft
> tends to make things overly complicated, and with Linux you also have
> the source code (given you're capable of understanding it). However,
> it's not really dependant on the operating system. I learned the basics
> on Windows before doing my first steps with Linux.
>
> cu
> 59cobalt

Thanks for the support. I guess it is time to leave home and set out on
a new course...the linux course [ of course]
Then there is still the matter of internet protocol...
Warf.
PS, i gave you the nod in a different thread with Sebastien regarding
your comments about making a 'safe' internet.
I think maybe the dedicated , user unmodifiable approach we had in the
early years may in fact be the only way. as long as everybody can have a
go at it they will. Compatibility will tank again but then at least we
can choose....safe or mailable and adaptable [but hackable]
I know there will always be a subset of society bent on defeating that
inherent safety but at least it would be limited to the experts. By
shear reduction in the number of people and modes to watch it would be
much easier than the open ended 'have at it because we all want our cake
and eat it to' way of making all connections generic.

I was very opposed to the early proprietary crap we had but i wan
t aware of what the trade off would be .... much like child soldiers are
to war, educated and bored kids outnumber the 'pro's.

I'll gracefully step aside now and see what I can learn of linux.
Till then, thanks for the advice.
Warf
[gotcha!]

Re: Thoughts about restricting outgoing communication

Post removed (X-No-Archive: yes)