DNS will definitely work. Not sure about ICMP. Why don't you try it? :)
sanga collins <[email protected]> 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]> <[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
>>>>>
>>>>>
_______________________________________________
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.
