Drilling through firewalls
in [Embedded]
|
From: Tim Wescott on 21 Jul 2010 13:55 On 07/21/2010 10:52 AM, D Yuniskis wrote: > Hi Vladimir, > > Vladimir Vassilevsky wrote: > >> D Yuniskis wrote: >> >>> I'm looking for ideas on ways to subvert firewalls for >>> short messages. I.e., passing what *appears* to be >>> *legitimate* traffic through a (properly configured) >>> firewall that is, in fact, *not* acting in the "apparent" >>> purpose. In particular, I'm interested in some of the >>> "less obvious" ways of doing so. >>> >>> I'm concerned with "classic" firewalls, here (e.g., >>> running on a bastion host) -- not the MS variety >>> (the idea of running a firewall on a desktop machine >>> seems *too* funny! :> ) >> >> To establish any communication, at least one computer outside must >> have open server port. Clients could connect to it and communicate to >> each other through whatever outbound connections allowed by firewall. >> There is no problem to encapsulate your data into http or any other >> common protocol. > > The problem lies in my expectation of a "(properly configured)" > firewall. > > A good security officer will look at *each* node on his network > and configure the firewall to allow the *minimum* connectivity > REQUIRED by the device in question. Then, write rules to > restrict the traffic between that node and the outside world > to *exactly* that level -- nothing more. > > If, for example, the device in question is a laptop, then the > MAC/IP associated witht he laptop will probably have very > permissive rules regarding what it can and can't talk to on > the outside. > > OTOH, if the device in question is a temperature sensor (recall > this is c.a.e), chances are it *won't* be allowed to access > websites, send email, etc. directly with the outside world! :> > Likewise, the outside world will be "hindered" from accessing > that device as well (no doubt, this example would have the > device "not routed"... but, with some thought, you can come > up with a device that *will* be routed -- though with limits > placed on its connectivity). > > So, the task is to come up with "non-obvious" (see my post) > ways of drilling through the firewall's rule set. > > Before the days of switches, this would have been easier > as network/peer discovery was almost "free". But, now the > switch limits just what traffic you see and, thus, how much > you can glean about the rest of the network (and the traffic > that the firewall is allowing for those *other* nodes) If the IT staff is that attentive and the firewall that restrictive, then turn the problem around: your equipment isn't defective if it can't talk through the firewall, the problem is with the firewall and/or the people managing it. Is there a comp.arch.embedded.corporate.politics group? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
From: jacko on 21 Jul 2010 14:02 On 21 July, 17:43, D Yuniskis <not.going.to...(a)seen.com> wrote: > Hi, > > I'm looking for ideas on ways to subvert firewalls for > short messages. I.e., passing what *appears* to be > *legitimate* traffic through a (properly configured) > firewall that is, in fact, *not* acting in the "apparent" > purpose. In particular, I'm interested in some of the > "less obvious" ways of doing so. > > I'm concerned with "classic" firewalls, here (e.g., > running on a bastion host) -- not the MS variety > (the idea of running a firewall on a desktop machine > seems *too* funny! :> ) > > Thx, > --don If the firewall is routing a connection for a machine inside (A), then sending a packet in may get routed, but then if the IP source is checked, it may be blocked (depends on firewall), the problem then becomes that A will reject the sequence order or end up crashing or time out in a CRC error resend loop, as packet number n-1 is never refetched. Not difficult really, more irritating.
From: D Yuniskis on 21 Jul 2010 14:41 Tim Wescott wrote: > On 07/21/2010 10:52 AM, D Yuniskis wrote: >> Hi Vladimir, >> >> Vladimir Vassilevsky wrote: >> >>> D Yuniskis wrote: >>> >>>> I'm looking for ideas on ways to subvert firewalls for >>>> short messages. I.e., passing what *appears* to be >>>> *legitimate* traffic through a (properly configured) >>>> firewall that is, in fact, *not* acting in the "apparent" >>>> purpose. In particular, I'm interested in some of the >>>> "less obvious" ways of doing so. >>>> >>>> I'm concerned with "classic" firewalls, here (e.g., >>>> running on a bastion host) -- not the MS variety >>>> (the idea of running a firewall on a desktop machine >>>> seems *too* funny! :> ) >>> >>> To establish any communication, at least one computer outside must >>> have open server port. Clients could connect to it and communicate to >>> each other through whatever outbound connections allowed by firewall. >>> There is no problem to encapsulate your data into http or any other >>> common protocol. >> >> The problem lies in my expectation of a "(properly configured)" >> firewall. >> >> A good security officer will look at *each* node on his network >> and configure the firewall to allow the *minimum* connectivity >> REQUIRED by the device in question. Then, write rules to >> restrict the traffic between that node and the outside world >> to *exactly* that level -- nothing more. >> >> If, for example, the device in question is a laptop, then the >> MAC/IP associated witht he laptop will probably have very >> permissive rules regarding what it can and can't talk to on >> the outside. >> >> OTOH, if the device in question is a temperature sensor (recall >> this is c.a.e), chances are it *won't* be allowed to access >> websites, send email, etc. directly with the outside world! :> >> Likewise, the outside world will be "hindered" from accessing >> that device as well (no doubt, this example would have the >> device "not routed"... but, with some thought, you can come >> up with a device that *will* be routed -- though with limits >> placed on its connectivity). >> >> So, the task is to come up with "non-obvious" (see my post) >> ways of drilling through the firewall's rule set. >> >> Before the days of switches, this would have been easier >> as network/peer discovery was almost "free". But, now the >> switch limits just what traffic you see and, thus, how much >> you can glean about the rest of the network (and the traffic >> that the firewall is allowing for those *other* nodes) > > If the IT staff is that attentive and the firewall that restrictive, > then turn the problem around: your equipment isn't defective if it can't > talk through the firewall, the problem is with the firewall and/or the > people managing it. If you've workeed with IT/IS departments at larger organizations, you'll find them RETENTIVE (beyond "ATtentive") -- BofH comes to mind :> There seems to be a mindset that borders on "control freak". As if the network (and everything attached to it) was their *personal* property (and they never learned to "share" as children :> ). Couple that with the fact that they don't understand anything that isn't a PC. And, can't *control* those other things ("no user serviceable parts inside") puts them really on the defensive. In one case, they made such a stink that a separate network was installed (for fear that these "black boxes" would CORRUPT their precious network). Then, responsibility for the network was given to another NON-IT group (which *really* frosted them as all the new automation was now beyond their jurisdiction -- money is being spent on "electronic goodies" and they have no say in how or where that money is spent). I don't want to play politics. I just want to solve (technical) problems and move on. To that end, I have found that doing things in a more clandestine manner is easier than fighting the good fight (if you "win", you've made enemies; if you "lose", you end up dealing with a bunch of ignorant, pompous asses). > Is there a comp.arch.embedded.corporate.politics group? I'm not sure they know how to access USENET! :-/
From: Clifford Heath on 22 Jul 2010 06:09 D Yuniskis wrote: > I'm looking for ideas on ways to subvert firewalls Skype is very good at drilling through firewalls. Quite apart from the obvious HTTP (CONNECT, etc) facilities, it can open a port in a packet-filtering FW using "hole punching". Google it, but basically it relies on a 3rd party to make firewalls at both clients *think* that both clients are attempting an outbound connection to the other, so they allow packets to come in. The 3rd party is there to guess the ports that will next be allocated. Cunning. Or just sign up as a Skype developer and use their API. Clifford Hesth.
From: D Yuniskis on 21 Jul 2010 21:07 Hi Clifford, Clifford Heath wrote: > D Yuniskis wrote: >> I'm looking for ideas on ways to subvert firewalls > > Skype is very good at drilling through firewalls. > Quite apart from the obvious HTTP (CONNECT, etc) facilities, > it can open a port in a packet-filtering FW using "hole > punching". Google it, but basically it relies on a 3rd > party to make firewalls at both clients *think* that > both clients are attempting an outbound connection to > the other, so they allow packets to come in. The 3rd > party is there to guess the ports that will next be > allocated. Cunning. Yes, but this only works if the clients (skype#1 & skype#2) can get *out* through their respective firewalls *first*! I.e., they have to either exploit a *poorly* (vs. *properly*) configured firewall *or* leverage protocols that the firewall *will* pass (for their IP). E.g., skype wouldn't work in an institution where it was trying to originate connections from a node constrained to be an NNTP server/client. (think in terms of *appliances* instead of "PC"s) > Or just sign up as a Skype developer and use their API.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: FM radio in mobile phones Next: Black box inventor David Warren dies at 85 |