> That is something we often tend to do here (on LUG) similarly like "buying a machine gun to kill mosquitoes".
I prefer flamethrowers. On Oct 15, 2012 8:39 AM, "Edmonds Namasenda" <[email protected]> wrote: > > Somehow I got intrigued by the whole thread and almost lost track of what Godfrey & Justus were requesting for. > That is something we often tend to do here (on LUG) similarly like "buying a machine gun to kill mosquitoes". > > It should definitely be a simple practice for the initial inquiry with the addition of an HTTP Proxy running Firewall & DNS configs. And that literally means any simple specs machine with two NICs if you do not want to get more confused. > > And Godfrey (assuming Justus is not too), it is not quite a good practice for any level of a Network Admin to manage a LAN / WAN entirely on a basic WiFi router. Please correct me if my assumptions are overly and wrong. > > # Edz > > > On Mon, Oct 15, 2012 at 8:08 AM, Paul Bagyenda <[email protected]> wrote: >> >> 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. > > > _______________________________________________ > 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.
