RE: scanning/checking/validating a vendor's remote client before it connects to

From: captgoodnight captgoodnight <captgoodnight@hotmail.com>
Date: Mon Jun 19 2006 - 00:54:34 AKDT

Hmmm.

I need a little more info, like what kind of access do these guys want?
Applications, network, single host...?

Could a host based vpn client too a same brand vpn gateway/firewall with
zone/object based restrictions work?

The firewall requires the guest (vpn client) to prove that a recent updated
virus/spyware scan has taken place before granting him access to the target
network or IP. With this, at the same firewall, have IPS on; block high risk
and log medium to low, log with snmp or syslog...Aswell, have AV/Gateway AV
at the VPN zone, at the same gateway.

The quick solution I'm thinking of will cost though. It's very zone/object
based and user friendly. It does require the client software (av and vpn
client)...Maybe your current border devices can do this already?

Could a ssl vpn work? Probably not.

How would this be done in linux, for a M$ client?

Snort could be the IPS, iptables the firewall of course, ipsec... It's the
av/spyware bridge, that's the question...How to make a linux box ask/receive
proof of updated malware scans and sigs, without the need of client
software? Quick home hack would be pulling the log, proof, whatever off the
m$ box and testing it, simple conditional. It could be something as simple
as a reg key. Interesting...Is there a medium/small biz solution like this
for linux? I see it... finding the "proof of health" from all the different
av vendors would be tricky though...

2 cents,

--eddie

>From: "lee" <lee@afabco.com>
>To: "aklug" <aklug@aklug.org>
>Subject: scanning/checking/validating a vendor's remote client before it
>connects to our system?
>Date: Sun, 18 Jun 2006 20:40:27 -0800
>
> I take care of a 'designated infrastructure critical' system (utility
> scada system) (whoo-hoo). Anyway, I've been so far successful about
> being pig-headed, er "adamant" about keeping our system contained to
> our system, no [known] connections to the outside, any outside, and I
> police it and monitor it pretty closely.
>
>However, the system is past end-of-life, and we are in the process of
>spec'ing a replacement system, and I can see the writing on the wall.
>The vendor, whoever it happens to be, is going to want to remote in to
>do tech support. And I'm not totally opposed to that. Necessarily.
>Totally.
>
>It could have advantages.
>
>Maybe.
>
>To cut to the chase, I want a way to do a virus/trojan/malware/badboy
>scan on the vendor's dialup client and have it pass before I'll even
>close the (physical) connection between the outside firewall and our
>network.
>
>The vendor of course is going to say 'trust us. We do our own scans
>etc'. Which is of course a non-starter.
>
>Nor can I imagine the vendor letting us install stuff on their machine
>(though we could make that part of the contract, I guess).
>
>What do others do for this kind of thing?
>
>I'm very familiar with working with GPL'ed stuff so hopefully there's a
>reasonable solution there, but I'm not averse to pay or subscription
>solutions either.
>
>Brainstorming, I guess I'd look for something like a trendmicro
>housecall or whatever symantec calls their online scan that we could put
>on our DMZ that the client would have to pass before letting me know I
>can close the switch. Or even, if we do this via public internet
>(unlikely), can redirect the client to housecall. It's a 99.9% sure
>thing the vendor is going to be a microsoft drone, so the housecall
>(style) thing should work.
>
>Or maybe there's a much better more comprehensive way?
>
>Thanks!
>Anyone who puts a small gloss on a fundamental technology, calls it
>proprietary, and then tries to keep others from building on it, is a thief.
>-Tim O'Reilly
>
>--
>http://www.fastmail.fm - A fast, anti-spam email service.
>
>---------
>To unsubscribe, send email to <aklug-request@aklug.org>
>with 'unsubscribe' in the message body.
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Jun 19 00:55:11 2006

This archive was generated by hypermail 2.1.8 : Mon Jun 19 2006 - 00:55:11 AKDT