Tesla coils are worth mentioning, too.
Kyle Spencer <[email protected]> wrote:
>> 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.
