Re: Drilling through firewalls
- From: D Yuniskis <not.going.to.be@xxxxxxxx>
- Date: Wed, 21 Jul 2010 11:41:02 -0700
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
The problem lies in my expectation of a "(properly configured)"
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
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
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! :-/
- Re: Drilling through firewalls
- From: David Brown
- Re: Drilling through firewalls