virus risk

[Maarten]

Hi all,
We are designing a 'black box device' that drives an
apparatus. It will be connected to the LAN by TCP/IP. Our
customer communicates with it via their normal desktop PC
(s). Do I have to take some anti-virus precautions here?
....here is at the bbox running XPe

Any ideas/pittfall warnings are welcome

Maarten

 

[Davide Masino]

Hi Maarten,
sure you have! This doesn't necessary means an 'antivirus' solution
(even if microsoft is working on a native one with McAfee etc...), but
at least a well balanced hardening/firewalling implementation.
For example hardening could means disabling all useless services for you
(NetBT for instance or, better, like DCOM: think to the blaster worm!)
and firewalling could means using ICF, for instance, and leave open only
the ports you really need.
Regards,

-Davide

 

[Slobodan Brcin]

My approach to the problem is always isolate your computer from the network.

I know that this requires programming the complete simulation of TCP
protocol in your communication driver, but this allows that only your
program has access to network in manners you support.

If a apparatus (black box device) does not direct interaction with user,
then you can write kernel mode program that will acquire data process them,
and communicate trough TDI or NDIS interfaces.

Kernel mode (drivers) are much better written then ordinary Win32
applications and services, so if you can use only kernel mode then you
should be safe from any kind of network attack.
You can even use TCP/IP stack from MS, since TCP/IP alone does not impose
threat to security of your device.

BTW:
We are talking about XPe image size 8-15 MB.

Regards,
Slobodan

 

[Doug Hoeffel]

I agree. My product ships without antivirus s/w installed mainly because it
would be a performance hit and it would be very difficult to keep it
updated.

I do numerous things to lock down my device. I use IIS so I run IISLockDown
which now includes URLScan. I don't use the default http port of 80. I
implemented TCP/IP port filtering as well as other registry tweaks. I also
turn off anything I don't need that came along as baggage is my OS image,
i..e like the Remote Registry Service and the Messenger Service. This is
just a snippet of what I do.

Finally, when I think I'm done, I run the Retina tool targeting my device
and I fix anything that's still a vulnerability.

HTH... Doug

 

[Guest]

Hi Slobodan,

We can not force the customer to isolate their PCs ,
but we do write the drivers and protocols ourself. So our
box is save I think.
Why must the image be <15Mb ??!

Thanks,
Maarten

 

[Slobodan Brcin]

No, image size is irrelevant.
But if your image is based on only kernel mode. Then it is hard to create
bigger image from including drivers only.

You are safe in two cases. If you use above mentioned, kernel mode only.
Or if you disable or remove all services and programs that use standard
communication protocols.
If nothing from XPe is aware of network presence, then it can hurt you.

Regards,
Slobodan

 

[Maarten]

We will be save, thanx
....now the rest

Thanx,
Maarten

 

[Heidi Linda eMVP]

Hi all,
We are designing a 'black box device' that drives an
apparatus. It will be connected to the LAN by TCP/IP. Our
customer communicates with it via their normal desktop PC
(s). Do I have to take some anti-virus precautions here?
...here is at the bbox running XPe

It really depends on what you're running on the unit, but include nothing
you don't absolutely have to have in your build and you're a lot safer -
making sure it's behind a good firewall helps too. My device is immune to
all the virii I've tried to infect it with simply because there's not enough
of windows there to support them. Blaster, for example, complains of a
missing .dll and asks to be reinstalled.

 

[Slobodan Brcin]

But using firewalls expose you to another threat Denial Of Service attacks.
(Firewalls consume processor time to analyze incoming information)

If all your devices are located on Gigabit network (Probably same for 100
MB/s), one malicious computer can consume all processor resources on all
your devices. In some situations this can be very dangerous don't you think?

Regards,
Slobodan

 

[Davide Masino]

I could obtain a denial of service only by pinging the network broadcast
with the victim address as a spoofed src address, or, tipically on XPe,
initiating 15 TCP connections simultanely (more or lees, I don't
remember the limit now, but it's a license iussue to distiguish from
server products).... Generally firewall (not ICF...) can trig some 'rate
limits' exactly to avoid that.
However, in my experience, when a DoS is achieved, firewall hoverhead
does not rely very much.......

 

[Slobodan Brcin]

TCP is too slow to create attack on device.

But simulating UDP packets at rate of 50000 or 500000 packets per second
(can be done easily). Will block device that try to analyze this packet at
some higher level, and even if it does not block 100 % processor resources
it will take valuable time, that might be crucial for some applications.

So you must use very fast (what ever that this means) firewall. Or you don't
use any firewall at all. And also you remove all services that use UDP and
TCP ports, etc.

So you should analyze for yourself, if someone can tap into your local
network and do such a thing.
Or does this concern you at all. For most product this is irrelevant.

But if you are creating security monitoring systems, and let wholes that
someone can deliberately use to sabotage your system, well ....


Regards,
Slobodan

 

[Davide Masino]

Sorry Slobodan, but let me insist...

TCP is too slow to create attack on device.

hum... TCP is not fast as UDP, yes, but has some well known issues as
SYN DoS... very simply to take in place and you know that a SYN packet
is fast as a UDP one.

But simulating UDP packets at rate of 50000 or 500000 packets per second
(can be done easily). Will block device that try to analyze this packet at
some higher level, and even if it does not block 100 % processor resources
it will take valuable time, that might be crucial for some applications.

This is not the clue, I think: if my firewall let me define a rate limit
(to the best of my memory, for instance, ZA does and linux/netfilter
infrastructure surely does) then over that limit, packets are simply
dropped, avoiding to push them on the stack which, at this point, really
means overhead. No 'higher level' analysis is performed at all.

So you must use very fast (what ever that this means) firewall. Or you don't
use any firewall at all. And also you remove all services that use UDP and
TCP ports, etc.

remove all services that use UDP and TCP ports could not be enough...
what about ICMP (the 'redirect' one for instance........). And this is
only an example.

So you should analyze for yourself, if someone can tap into your local
network and do such a thing.
Or does this concern you at all. For most product this is irrelevant.

Someone tells me, a long time ago, that the most dangerous hacker is
always your employee....

But if you are creating security monitoring systems, and let wholes that
someone can deliberately use to sabotage your system, well ....

I guess not...


Cheers
-Davide

 

[Slobodan Brcin]

Davide,

You got the point.

Also it slipped from my mind that there are protocols embedded in TCP/IP
stack, that probably can't be disabled trough registry.
I have never used (or heard for until now) firewall that skips valid packets
after certain point.

Security of TCP/IP stack is one of most concerning issues for me.
I have video feeds that go at the approximate rate of 80MB/s. For this to
accomplish I have created drivers. But there are some pieces of program left
that communicate trough both UDP and TCP, infrequently but still there is a
TCP/IP stack. I guess that to be on the safe side I'll have to rewrite these
parts to go trough our driver also. And to remove completely TCP/IP stack.

Question is how many holes are there?
I hope that third party NIC minidrivers do not have holes in them as well
:-(

Regards,
Slobodan

 

[KM]

Sorry guys for jumping in to your conversation. Just wanted to confirm
Davide's point here though I'm not a security expert.
Many of recent (new/updated) firewalls allow you to have control over entire
TCP/IP stack. Now firewalls know how to prevent DoS attacks in the form of
ICMP echo bandwidth consumption, IP fragmenting, and SYN flooding, etc.

My personal preferences stand for RSDP (known BlackIce) even though it has
been already hacked (some of new viruses hack/stop the firewall).
Though it has been a while ago, I remember an easy integration of the
firewall client in to our XPe images (only some tweaks around IPFilter
driver) and it did not increase my image size dramatically (+2,5 Mb assuming
you got TCPIP stack included). More info here
http://blackice.iss.net/product_pc_protection.php.
And just aside of the windows firewalls but more general info on
BlackIce/IPFilter and attackes covered:
http://www.sans.org/rr/papers/21/815.pdf,
http://www.sans.org/rr/papers/30/346.pdf.

I think Slobodan's approach for replacing TCP/IP stack works good when you
have one/two network-dedicated application. IMHO, making sure your device is
most secure and protected you will need to cover many holes in the TCP/IP
stack anyway.

KM


DM> Sorry Slobodan, but let me insist...


DM> hum... TCP is not fast as UDP, yes, but has some well known issues
DM> as
DM> SYN DoS... very simply to take in place and you know that a SYN
DM> packet is fast as a UDP one.


DM> This is not the clue, I think: if my firewall let me define a rate
DM> limit (to the best of my memory, for instance, ZA does and
DM> linux/netfilter infrastructure surely does) then over that limit,
DM> packets are simply dropped, avoiding to push them on the stack
DM> which, at this point, really means overhead. No 'higher level'
DM> analysis is performed at all.


DM> remove all services that use UDP and TCP ports could not be
DM> enough...
DM> what about ICMP (the 'redirect' one for instance........). And this
DM> is only an example.


DM> Someone tells me, a long time ago, that the most dangerous hacker is
DM> always your employee....


DM> I guess not...


DM> Cheers -Davide

 

[Maarten]

Thank you all for your input,
Since the network protection is completely out of our
hands (read: not my/our responsibilty ), we only have
to concern ourselfs with TCP/IP on the device we develop.
And there we can close all but the port we listen to.

Maarten