RE: Hardware/Software Solution for Standalone DSL User
From: Rob Hughes (rob@robhughes.com)Date: 07/21/02
- Previous message: rohit sharma: "another query httport"
- In reply to: David@cawdgw.net: "RE: Hardware/Software Solution for Standalone DSL User"
- Next in thread: Mike Whalen: "RE: Hardware/Software Solution for Standalone DSL User"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Rob Hughes <rob@robhughes.com> To: Security-Basics <SECURITY-BASICS@SECURITYFOCUS.COM> Date: 21 Jul 2002 10:22:19 -0500
I think there's a couple of points in this post that would benefit from
some clarification, or at least another point of view. See notes inline.
On Sat, 2002-07-20 at 18:30, David@cawdgw.net wrote:
> I think there is some confusion.
>
> A cable/DSL router is not a real "hardware security solution".
Everything requires software, even if it runs from firmware, so agreed.
However, the distinction is usually that it's much more difficult to
trojan a firmware based solution than it is a truly software based one,
though things like processes running in jails with no write access can
mitigate that somewhat.
>
> Truths:
> - Stateful Packet Inspection DOES stop outside connections that did not
> originate from your system
But these can often be spoofed, and do little with regards to session
hijacking, if the dest ip is being spoofed.
> - Filters DO stop outgoing connections on specific ports or ranges of ports
> IF used
Clarification: port filtering can encompass src ports, dest ports, or a
combination.
> Misunderstandings:
> - Port filtering only works if used, if set up properly, and then only if
> the connection is using ports you don't allow through. If the connection
> uses ports such as 80 or 25 or 110 or 443, it will get through if you use
> these ports (http, send mail, pop, ssl https)
This is not necessarily true. If you allow a destination port of 80,
connections coming into port 80 won't be allowed through. The only case
where this would be true is if you have a rule like allow tcp from any
to any port=80. So, from this the importance of *proper* implementation
becomes evident.
> - if you allow port forwarding, anything using that port can start a
> connection on that port
I'm not sure what you're exact meaning here is. If you combine stateful
inspection and anti-spoofing rules with port-forwarding, then the
connection would only be allowed if it originates from a certain network
or networks. For instance, even though I use port forwarding, I can't
connect to my web server via the external address. I have to use the
internal address due to the rules I have set up which see my connection
to the external address from the internal address as an an attempted
address spoof.
> A hardware solution such as a Cisco PIX 501 does more than NAT. An easy
> example is a NAT forwarding all port 80's will direct port 80 to your web
> server, but a 501 will identify the connection as being CodeRed and stop it.
> (Well, should stop it. Let's not get too detailed)
This is due to the PIX have the ability to do some basic content
inspection. A firewall that's much better at this is the Cyberguard
series which can provide both circuit-level, as well as
application-level proxies, and filter on anything you want since they
completely destroy the packet on one interface, then completely rebuild
it before sending it out the other.
>
> A PIX == Configuration takes some time. Updates are more time. Stops quite a
> bit of stuff, though likely not cutting edge exploits/worms (until the new
> update to combat it is developed and available)
This just shows a weakness that Cisco calls a strength. Yes, port
filtering is faster than proxying. But, proxying is much more secure
than port filtering. This is basically what the PIX does: port
filtering, with a bit of content inspection. For instance, I told a CYBG
box to only allow web connections, and the use the http proxy, and guess
what? My users trying to get IM clients to use http tunneling all
stopped working. Why? Because it wasn't true http protocol they were
speaking. This also stopped every other test I tried, tunneling telnet,
ssh, and everything else I threw at it over http. This illustrates the
primary difference between a true proxy and port filter. Also, using
these methods, I was able to redirect code red requests (which are legit
http traffic) to a null address and terminate the session.
> a Linux, etc box firewall == building this is lots of man-hours depending on
> OS and other factors (like is the default already got all ports shut?).
> Finding safe sources is a bit difficult. Stops even more stuff. More
> granular than a PIX (You can even build you own trap triggers) still doesn't
> stop cutting edge
There are plenty of linux, *BSD, etc. based solutions that will boot and
run from either a floppy or CD, or the hard drive, if you so choose.
These take no more time to set up than a PIX, and all the hardening has
already been done for you.
>
> Software firewall== Annoyance level is high. Configuration is a drill in
> patience. Stops everything you tell it to. The first time you tell it to let
> all anything through (all pop connections as example) anyone connecting 110
> has you.
Again, I think you misunderstand port filters a bit. Yes, if you allow
traffic from your box with a dest port of 110 through, then anything
coming *from* 110 can potentially get through, but not traffic *to* port
110 on your system. This may have been what you meant, but you weren't
clear here. However, many of the "personal firewalls" can be told to
only allow traffic to/from a specific address on port 110, thereby
mostly eliminating this issue (address spoofing in the absence of
stateful inspection/anti-spoofing is still an issue). It should also be
remembered that most connections from a system will not use privileged
ports (those below 1024) as their source port.
>
> The cheapest protection from hacking and DoS is a router AND a firewall. But
> the true savior is a protected good back up of a well patched system. When
> CodeRed first came out, the fast fix was to restore from a backup. Granted,
> an hour into CodeRed's deployment, so many boxes were hunting for unpatched
> boxes, you were toast, but at least when the patch came out, you had a clean
> backup to start the rebuild and patching process, rather than starting with
> an OS install CD.
Actually, when code red hit, the fix was to have applied the patch that
came out about a month before. I had http boxes on the net that were
never infected. Although when I was getting over 50000 hits a day, my
dinky connection groaned.
> Backups, especially things like a ghost image, are the most cost efficient
> thing a user can have. 90% of hacks are because of something the user
> installed, read, or somewhere the user went to. Then it's on the system.
Unless you have a good proxy and use a policy of least privilege. If the
exploit can't get past the firewall, and the user doesn't have the
rights to infect the box, nothing the user does will infect the box,
short of a local root/administrator exploit.
However, in relation to the original poster's question, all of the
above, will cost something, even if it's only the hardware. That's why I
don't throw out those old 233's. They make great little BSD firewalls.
So, for a single home user running dsl, a combination of a good
anti-virus package, a good personal firewall, and running from a
non-administrator account on a well-patched system should be sufficient
in the vast majority of situations.
The problem is that most home users don't understand what the firewall
is telling them, and either open up too much, or not enough. I also get
an almost incessant stream of questions over what they see in the logs,
wanting to know if they've been "hacked" or not.
The ideal solution for the home user is to have someone with some
expertise harden the system, then use an av package and don't install
any services. At that point, you're a mostly a blackhole on the net,
anyway, only generating limited connections, and accepting none.
> D. Weiss
>
HTH
Rob
-- Remember: the only difference between being the champ and the chump is u.
- application/pgp-signature attachment: This is a digitally signed message part
- Previous message: rohit sharma: "another query httport"
- In reply to: David@cawdgw.net: "RE: Hardware/Software Solution for Standalone DSL User"
- Next in thread: Mike Whalen: "RE: Hardware/Software Solution for Standalone DSL User"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
