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]> <[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.
