You have it about right..... server on the outside forwards what he wants
through an allowed port at the firewall, client on the inside listens on
this port and basically forwards to the correct port (or user) on the
inside. A more imaginative approach is to embed the data in a protocol such
as ICMP. Many administrators allow ICMP replies to go through the Firewall
and Hence an opportunity exists for a covert channel. The internal user
pings the external address, an entry is made in the state table to allow the
reply......... the channel is open and traffic freely flows.
A quick search on the internet and you can find free tools and actually a
server to embed the ICMP along with the client software to decode it on the
other side. Scarier thought than someone using ICQ, you have intellectual
property on the inside and you carefully filter and monitor ftp and smtp to
try to prevent internal users from liberating this data.... why not use the
http channel they have created to move the data...... you would never know
it went through.
How do you defend your self? If your just using a packet filter or stateful
filter I am not aware of a lot you can do other than analyze your logs see
where the traffic is coming from / going to and block that outside IP
address... and or deal with the individual on the inside. I would be
interested in hearing defense strategies from others when using basic
filtering techniques.
Not to start a flame war but the only way I am aware of to prevent this is
with a strong proxy. AGAIN I don't want to start a proxy / packet filter
debate, they both have their rightful place in security. But how would this
be handled if your not looking at the payload and further, breaking the
client server model? A strong proxy not only filters on specific commands
you allow (or deny) in the security policy but actually breaks the direct
client - server data path allowed by many Firewalls, rebuilds the packet
from scratch and only allows commands it knows and allows to be in the new
packet it creates. Hence if you embedded something in the packet / protocol
headers it will not be copied over to the new packet before it is passed
through the firewall. You can have it alert the admin when the garbage is
seen or be a little more creative and have it automatically block the
incoming IP address. He changes address and the proxy blocks him again...
eventually he goes to look for an easier target... in the mean time because
you are fully application payload aware you have the log files to prosecute
if you choose to.
Think about a current threat like stacheldraht, it is the beginning of a new
generation of intrusion methodologies. The commands to activate / perform
the remote coordinated DoS using stacheldraht agents is a covert channel in
ICMP. Why, because many administrators allow ICMP replies and the
predominate Firewalls currently deployed do nothing to break the covert
channel. The only response / choice you have would be to deny all ICMP......
what if RPC or HTTP is used as the channel... a little more inconvenient to
deny all with these necessary services.
Paul A. Henry
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Mailing Lists
Sent: Sunday, January 23, 2000 10:38 AM
To: [EMAIL PROTECTED]
Subject: Bypassing firewall
Hi!
Back where I work, we are using a firewall the blocks everything coming in,
and gives internal users permission to use the www, ftp, pop and mail
ports. (no icq, no aol, no nothing else).
But I overheard one of my users bragging that it bypassed the firewall
using two linux machines doing port redirection.
I did a little research on this and the most plausible way I found is that
he is running a linux inside the firewall which grabs everyhing on a
certain port (let's say the icq server port), then forward it through port
80 to another linux box outside the firewall which make the actual call to
the icq server on the right port. Is that possible? Is there any other
alternatives he can be using?
btw, I don't know what the firewall used is, I'm the sysadm for my
division, but we are using the corporate firewall.
Thanks!
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
