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