[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKE transport (was INITIAL-CONTACT issues)
My apologies for the late reply. First I would like to bring up that
firewalls are placed in more places in a network topology than just
protecting oneself from the Internet. Finance, Engineering, System Admin,
and different classes of users all require different security policies and
therefore different security devices to protect them.
I personally do not believe that IPSEC is the silver bullet to security.
Firewalls, IDS, network management, dutiful reading of logs (apps, servers,
firewalls, etc), etc. are still required. In addition, the network
infrastructure needs to strictly enforce security policies regarding
directions data may to and from.
> "Burden, James" wrote:
> > Personally, I am wary of allowing any UDP through a firewall.
>
> Question: why would you be less wary of allowing tcp through?
>
Generally, logging of TCP connections, and tracing connections to the
originator are both easier with TCP than UDP. The firewall is my first line
of defense. I have to allow bad UDP packets forever through the firewall,
and let the application take care of itself.
>
> > In addition, UDP requires some mechanism to prevent IP
> spoofing. This is
> > all done at layer 7. The application (and the
> implementation) must be
> > trusted, and you could potentially lose your defense in
> depth with the
> > firewall.
>
> Again, why would tcp be different?
In a private network where you can control the routing tables (using static
or floating static routes, or the use of a routing protocol that takes
advantage of summarizing subnets)and prevent IP spoofing from subnet to
subnet. The 3-way handshake becomes a great friend.
>
> > I would agree that a DoS attack is easily mounted against
> TCP, but it would
> > be easier to defend than UDP.
>
> How so?
Yes, you can do a SYN attack against TCP, but you can limit the timers
(after taking the necessary metrics), limit the number of sessions, and with
UNIX you can use tcp_wrappers as an additional layer of defense. Someone
spoofing the SYN packets will be soon dropped, and the real client will be
able to establish a connection as he will have a valid return route for the
3-way handshake.
I do see your point in that the initial TCP packet, and all the UDP packets
are roughly equivalent. The major difference is that the network devices
can protect the TCP connections, where the app stands alone. Even the
operating system can do little to help. UDP is susceptible to buffer over
flows, where I do not think that TCP would be until after the session was
set up (I could be wrong).
Which is more reliable, the network/security devices or the applications?
This would probably be more of a religious war. My feelings are probably
evident, as security devices are normally not used until they have been both
proven and have withstood peer review. Applications on the other hand are
first to market, and where other things such as cost and time are given
higher priorities than security, to include security software.
If I could equate this to chess, then the application would be like the
king. What good are the other pieces? Even though Steinitz said the king
could take care of himself, he still used the other pieces to their utmost
potential.
Someone in another email said that we should start trusting somebody
sometime, and that the Security Gateway could replace the firewall/or run in
parallel.
+-----+ Internet +----+ ipsec tunnel +-----+
| E1 |===========| FW |===============| E2 |
+-----+ +----+ +-----+
E1 and E2 are now of the same security policy (the weakest). In addition,
each has to fully trust each other. In most physically secure environments
you give a visitor a badge, and escort them. Would you do less with a
visitor on your network?
Jim
Follow-Ups: