[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: TBB on XP again
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: TBB on XP again
- From: "Kyle Williams" <kyle.kwilliams@xxxxxxxxx>
- Date: Sun, 18 Jan 2009 13:08:56 -0800
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Sun, 18 Jan 2009 16:10:15 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=JTOdMjg9azFtOv5v7fpY5PtG0lD/s4uGdqpCerYjkeY=; b=gozrUjZZmhLbrDwNgBLFkB9kcj7vmOTK8dDM4WqfJFPD1vx44TkgLDl+SNZNnldvS2 kyjTKHNUp4V3fTmlBf60cQ/FT3rY1QnctrhSGrCoIljxpRsSD4VXNy+tlJiFPerllZkw tb1QpOFKZc2z7+RlrcheFZbxyRiLdvjMl8fK8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=b9mkGiyPqnhf7P/AJSG3rW++C1mIrHTPKf42bUOGz1UqM3lLrU0Mlz7yTWRJqwaReZ JZnF2pBwFbuaN8+6LzNGFE4wQduCcUHozOmfjmbSiVOixVWrysjdHuq+7x4ljWAnE4CS VwmZ5hZHwHI5T8oWi8OKn1VIWDD/zP8ut/Rmw=
- In-reply-to: <20090117.235240.126.0@xxxxxxxxxxxxxxxxxxxxxx>
- References: <20090117.235240.126.0@xxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
By chance have you used any virtual machines on the host OS that runs your NIS firewall?
There are two networking modes I'd be curious about. The first being a 'bridged' networking interface. The second being a 'NAT' networking interface. I would think that 'bridged' networking would not be affected by NIS on your local system, and would be able to operate on the network without restrictions, since it appears as a completely separate device on the network. I'm curious about a NAT'd interface though. I would think that is would be affected by NIS, since all traffic would pass through the host OS before entering the network.
For my day job, I managed a global VM infrastructure. One of my duties is to make sure all the VM's stay up-to-date with the latest security patches for the different OS's . I've noticed that the securities measures that allow the company to audit "who is doing what" can be easily bypassed if a VM is brought online and doesn't have the proper management software installed. (However, network audits catch this within 24 hours.) This can be good or bad depending which side of the fence you're on. Perhaps in your case it might be good to use a VM that has a 'bridged' network interface to try and avoid NIS? If you don't have admin level access, then you are probably stuck using a NAT'd network interface for your VM.
The other advantages of using a VM with a 'bridged' network interface in a restrictive or monitored environment is:
1) Process auditing will only see that a VM was run (qemu.exe or vmplayer.exe) in the audit logs. (So what ran in the VM? Who knows... ;-)
2) Network auditing on the HOST OS will not see a direct connection between your VM's traffic and the HOST OS.
3) You can keep it with you on a USB flash drive. Maybe even a Live CD with a VM on it?
4) Use OS encryption on the VM itself to protect your VM in the event it becomes remotely audited, copied, or stolen.
Just my two cents worth...
On Sat, Jan 17, 2009 at 11:52 PM, mikel.anderson@xxxxxxxx <mikel.anderson@xxxxxxxx>
Well I'll be a monkey's uncle! Turns out both non-admin accounts had their NIS accounts set to the more restrictive Teenager level. TBB was stalled waiting to be granted access by the NIS firewall. Adult level users are notified about each request and may grant or deny each one. Users with more restrictive levels are not even notified.
Even with the correct account levels systems like mine are going to leave tracks in the firewall. TBB leaves a set of three tracks(tor, firefox, and polipo) for each user account on which it is successfully run.
Furthermore, this demonstrates how easy it would be to block the use of portable browsers on any kind of public computer.
Domain Registration - Click Here