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 responsible for them in any way.
