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