I tend to agree with you. 1) For most casual users, Facebook is almost an addiction, so talking to them nicely will not stop them. And it is definitely a productivity sink in my view. 2) Most casual users are not technical enough to do all the gymnastics of getting around the blockade.
So: HTTP proxy + fake DNS zones on our linux gateway should do the trick. And you can designate some IPs are special so they never get blocked. Our office sysadmin did it in a few minutes and has successfully blocked even the more technically-minded, so it is not that hard methinks. P. On Oct 14, 2012, at 20:48, sanga collins wrote: > you are over thinking the question. how do you break out of the network with > the proxy and firewall rules in place? Is there a way using the techniques > discussed in the previous posts. Physical security can be left for another > thread > > On Sun, Oct 14, 2012 at 1:18 PM, [email protected] > <[email protected]> wrote: > Are there Firewire ports present? Whether or not they are operational is > irrelevant. If yes, I would use the inherent DMA flaw in the IEEE1394 > standard to obtain full read/write access to RAM. Check mate from there, > pretty much. > > If no, then I would probably just photograph the screen. It's inelegant, but > it does the trick. If one wants fidelity one could introduce a program which > converts a data stream to a series of machine-readable graphic > representations (think animated QR codes) and record it with a camcorder for > later decoding. > > > sanga collins <[email protected]> wrote: > USB ports are disabled on the computers > > On Sun, Oct 14, 2012 at 1:01 PM, [email protected] > <[email protected]> wrote: > If I wanted to steal information, I would copy it to a flash drive and walk > out the door with it. Keep it simple. :) > > > sanga collins <[email protected]> wrote: > In my situation the only outbound traffic from workstations allowed is 80 and > 443. And even then that is only allowed through one IP, that of the proxy > server. Proxy server is a Zentyal server. The zentyal server IP is the only > one allowed to send DNS, smtp, ssl etc etc etc. > > How would some of the above techniques still work to defeat this setup? I > realize a standard user would not even dream of some of these steps like ICMP > tunneling or DNS tunneling, but lets say a hacker visits one of my locations > with a laptop and is trying to steal patient information and send it to a > crime syndicate in another country. > > Here is a sample of my juniper firewall rules. PLease note this a a very > simplified example please look at it in the context of the discussion. Its > not my exact firewall rule set but it does convey the idea > > source = Zentyal / Destination = WAN / Services = DNS,HTTP,HTTPS,SMTP / > Action = permit > source = LAN / Destination = Zentyal / Services = DNS,HTTP,HTTPS / Action = > Permit > source = LAN / Destination = VPN / Services = Custom / Action = Permit + log > source = LAN / Destination = WAN / Services = ANY / Action = Deny + Log > source = ANY / Desination = ANY / Services = AMY / Action = Deny + Log > > On Sun, Oct 14, 2012 at 10:26 AM, Benjamin Tayehanpour > <[email protected]> wrote: > Oh, and also, many captive portals use DNS as a capture method, so it will > not work there. > > > On 14 October 2012 16:23, Benjamin Tayehanpour <[email protected]> > wrote: > A very easy way of blocking DNS tunnelling (given a forced local DNS server > in your control) would be to block all TXT replies, or even to limit the > length of a query so the base32-encoded data simply will not fit. None of > these measures would hamper ordinary usage, and both of these are standard > configuration options in BIND, and, I'm sure, in many other DNS daemons, so > blocking it is quite trivial. > > But it probably will go unnoticed for quite some time, unless you use > disruptive amounts of resources. > > > On 14 October 2012 16:10, Rocco Radisch <[email protected]> wrote: > ICMP can be blocked, hence its boring. Look at DNS tunnelling and you will > quickly realise where the real hammer is. Ok, for speed reasons an openvpn > tunnel on udp port 53 might be an alternative if outgoing DNS traffic is not > blocked. DNS tunnelling uses the internal DNS servers to relay traffic, which > is difficult to block. So, with all outbound traffic blocked and with only > access to internal resources it is still possible to go to Facebook with the > help of an internal DNS server ;-) That can only be mitigated on the DNS > server itself and there are not so many options yet. Snort might be able to > tell the difference (if listening on LAN). > Same principles work with local provider's Hotspot - "please load more > credit" sites. Or, for the tech novices, just look up WiFree. It uses all > mentioned methods (udp, tcp, icmp, dns) seemingly together. > > Rocco > > > On 14/10/2012 12:42 PM, [email protected] wrote: >> However, most ops have probably not even heard about ICMP tunnelling. Even >> if this one has, examining the contents of the ICMP Echo payload will >> probably not be the first thing an ordinary op does. She will probably think >> you are ICMP flooding the target, though, and that is probably a graver >> offence than a little tunnelling. >> >> If it's a public hotspot you probably have nothing much to fear, though, as >> you are anonymous and practically impossible to trace. >> >> Phillip Simbwa <[email protected]> wrote: >> >The ICMP tunnelling trick was quite nifty. It will light most pieces of >> >network >> monitoring softwares up like Christmas trees, though, but chances are public >> hotspot providers do not monitor traffic that closely. >> >> My man is working with just a Linksys wireless router <cough> </cough> >> If i was one of his stress boys, and my casual reconn indicated that >> the Linksys was his strongest weapon; I wouldn't put much effort to it >> (it would be over kill). >> >> But if the wireless router is loaded with ddwrt, i would tread more >> carefully -- the network admin may not be the ordinary nice guy. He >> may have a few surprises up his sleeve (e.g dumping logs from the >> Linksys to some remote server for ana >> lysis). >> In such a situation, >> going with ICMP/DNS tunneling is like carrying a knife to a gun fight. >> >> >> >> >> _______________________________________________ >> The Uganda Linux User Group: http://linux.or.ug >> >> Send messages to this mailing list by addressing e-mails to: [email protected] >> Mailing list archives: http://www.mail-archive.com/[email protected]/ >> Mailing list settings: http://kym.net/mailman/listinfo/lug >> To unsubscribe: http://kym.net/mailman/options/lug >> >> The Uganda LUG mailing list is generously hosted by INFOCOM: >> http://www.infocom.co.ug/ >> >> The above comments and data are owned by whoever posted them (including >> attachments if any). The mailing list host is not responsible for them in >> any way. > > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way. > > > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way. > > > > -- > Sanga M. Collins > Network Engineering > ~~~~~~~~~~~~~~~~~~~~~~~ > Google Voice: (954) 324-1365 > E- fax: (435) 578 7411 > > > The Uganda Linux User Group: http://linux.or.ug > > > > > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > > > > > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > > > > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not respon > sible > for them in any way. > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way. > > > > -- > Sanga M. Collins > Network Engineering > ~~~~~~~~~~~~~~~~~~~~~~~ > Google Voice: (954) 324-1365 > E- fax: (435) 578 7411 > > > The Uganda Linux User Group: http://linux.or.ug > > > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > > > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not respon > sible > for them in any way. > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way. > > > > -- > Sanga M. Collins > Network Engineering > ~~~~~~~~~~~~~~~~~~~~~~~ > Google Voice: (954) 324-1365 > E- fax: (435) 578 7411 > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way.
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
