TCPmag.com
http://tcpmag.com/
http://tcpmag.com/rss
May 15, 2007
Editor: Gladys Rama (grama 1105media.com)
------------------------------------------------------------
------------
THIS ISSUE SPONSORED BY:
- Eliminating Your SSL Blind Spot: Free Paper
http://in
fo.101com.com/default.asp?id=38688
- Nortel Unified Communications Enhance Performance and
Reduce Costs
http://in
fo.101com.com/default.asp?id=38689
- EMC Improves Management of Exchange Deployments: Case
Study
http://in
fo.101com.com/default.asp?id=38690
------------------------------------------------------------
------------
IN THIS ISSUE OF TCPmag.com:
1. Q&A: Reflexive ACLs vs. CBAC
2. What's New on TCPmag.com
3. Interesting Employment in Washington, Texas, Virginia
************************************************************
************
SPONSOR: The Solution to Managing and Securing HTTPS
Traffic
************************************************************
************
This new paper discusses how HTTPS filtering (SSL scanning)
from
Secure Computing provides companies with the means to
counter threats
by fully extending Internet usage policies to HTTPS traffic,
and
thereby proactively closing the last known major network
security hole.
Get it today!
http://in
fo.101com.com/default.asp?id=38688
************************************************************
************
1. Q&A: Reflexive ACLs vs. CBAC
Send your toughest Cisco technical questions to editor tcpmag.com
with the subject line "Attn: Scott."
Scott,
What would be the main difference between reflexive ACLs and
CBAC
on Cisco routers? There seems to be a bit of overlap between
the two
methods, as far as I can tell.
-- James
------------------------------
James,
History, my friend. History is the difference!
In the beginning, we had access lists for packet filtering.
In some
instances, these are very basic methods of saying
"yes" or "no" on
a packet coming in or out of an interface. In many
instances, this
is a good way to filter information.
Now, let's start thinking about an Internet connection,
things our
users want to do and exactly what the packet is going to
look like.
Sniffers are often a good way to see the real packets on a
network
and get a good feeling about what things look like.
With a Web server, things are relatively basic. Your
outbound packet
will be directed to the Web server and will have a
destination TCP
port of 80. Your source port will be some random port
between 1024
and 65535 (known as an "ephemeral" port). So when
it comes to writing
an inbound access list that you would place on your
Internet-facing
port(s), what is that return traffic going to look like?
In the case of HTTP traffic, it's generally simple because
the source
port of the return traffic is TCP port 80. So we could write
an
access list for that as well. Some people find that
difficult or
confusing because it "looks wrong."
Access-list 101 permit tcp any eq www 200.200.200.0
0.0.0.255
Assuming, of course, that the 200.200.200.0/24 are my inside
addresses. How many other protocols work in this same
fashion?
Unfortunately, not all of them! It would be nice if everyone
followed
the rules set out a long time ago, where applications were
part of the
"well-known ports" below 1024, but I think with
the number of
applications we have possible today, things would become
fairly crowded.
The complexity of writing an inbound access list grows
tremendously
as we add more and more applications, so we had to come up
with some
solution to make the ACL a bit easier. Originally, with TCP,
we had
the "established" keyword. This would allow any
TCP session that had
completed the three-way handshake to come back in. Honestly,
all it
did was check for the ACK bit and, as far as malware goes,
it's not
really difficult to generate this on a packet. So that was
short-lived. And this did nothing for UDP traffic.
Reflexive ACLs were the next solution. This was the first
concept of
maintaining "state" (as in stateful firewall) on a
router. Instead
of having a wide-open ACL entry on the Internet side of
things
permitting any TCP/UDP traffic destined to any port between
1024 and
65535, we could check against a table.
There were two pieces to reflexive ACLs. An ACL to inspect
the
outgoing traffic from the users would "reflect" on
the traffic (e.g.,
build the table of active connections with exact
source/destination
entries). We could use this ACL to filter what users could
or could
not do, but in general it was used to simply build the
table.
Another ACL for inbound traffic from the Internet was used.
This ACL
will contain all of our static entries, such as for our Web
server
or e-mail server, or things that don't change. Normally, at
the end
we'd put "deny ip any any log" so that we could
see any violations.
Right ABOVE that line (since ACLs are processed top-down),
we would
use the "evaluate" command in order to tell the
router to check the
state table it had created and permit any return traffic
back in.
This worked for TCP and UDP sessions, and even understood
ICMP echo
and echo-reply pairing. It was not robust enough to handle
applications that changed ports dynamically, but it was a
good first
start at this.
Context-Based Access Controls, or CBAC, is the evolution of
this.
CBAC is the IOS Firewall Feature Set, or a more hearty
firewall that
we can use on our routers. Personally, I think it's easier
to
configure. But essentially, it does the same job of building
a state
table. It's more advanced and more robust in dealing with
some dynamic
protocols (no, it's not perfect, but it's not bad either),
so it's
a step up from reflexive ACLs.
Globally, you'll create your inspection rules for which
protocols
you want to watch. Then you'll inspect the traffic going to
the
Internet (OK, this may be oversimplifying things, but let's
stick
with the most common deployment analogy). Nothing else
really needs
to be done. CBAC will assume there are ACLs inbound at your
Internet
links permitting any static entries, and containing that
"deny ip
any any log" type of entry for good measure.
You don't need to add anything specific into those ACLs.
CBAC will
analyze the outgoing packet, and will automatically add
necessary
ACEs in order to handle the return traffic. CBAC is stateful
like
reflexive ACLs, but more advanced in terms of what
applications it
can handle.
That's the short answer for the differences, but another way
to look
at it is by your IOS version. Reflexive ACLs are part of the
"ip
plus" feature set. CBAC is part of the
"firewall" feature set. So
there may be cost differences there in your licensing of IOS
from Cisco.
Like any good, politically or accounting-driven IT
department, there
may be some non-technical reasons for choosing which method
to deploy.
Hope that helps,
-- Scott
Scott Morris, quadruple CCIE, JNCIE and all-around
Uber-Geek, can often
be seen traveling around the world consulting and delivering
CCIE
training. He has recently stepped up as VP of Curriculum
Development
for IPexpert and will oversee a new consulting practice. For
more
information on him check out http://www.ipexpert.com.
Send your questions for this column to editor tcpmag.com
with the subject line "Attn: Scott."
Miss a Q&A? Go online to http://tcpmag.com/qanda/
To comment on this Q&A, go to:
http://tcpmag.com/qanda/article.asp?editorialsid=379
************************************************************
************
SPONSOR: Case Study on Unified Communications
************************************************************
************
Tight integration between enterprise applications and
communications
allows users to reach each other and share information
within seconds.
And real-time communication requirements for an increasingly
mobile
work-force are met through such rich applications as video
and web
conferencing across roaming and fixed devices.
Read this case study today and find out how Nortel
implements unified
communications to enhance business performance and reduce
costs.
http://in
fo.101com.com/default.asp?id=38689
************************************************************
************
2. What's New on TCPmag.com
NEWS: "Another Cisco PIX, ASA Flaw Found"
It's been a rough stretch for Cisco Systems Inc.'s PIX and
ASA
appliances. Earlier this month, Cisco alerted users to the
existence
of multiple LDAP and denial-of-service (DoS) vulnerabilities
in
both products.
http://tcpmag.com/news/article.asp?editorialsid=1213
NEWS: "The Wireless Security Knowledge Gap"
Believe it or not, enterprise users aren't all that
knowledgeable
about the ins and outs of wireless security. That's the
mostly
tongue-in-cheek upshot of new research from market watcher
In-Stat,
which reports that enterprise wireless consumers are
typically most
concerned about security issues that are so last year.
http://tcpmag.com/news/article.asp?editorialsid=1214
RSS FEEDS ON TCPMAG.COM
If you're running an RSS client, then consider signing up
for feeds
from TCPmag.com. You'll automatically be notified when new
content
is posted. Learn more here: http://tcpmag.com/rss/
------------------------------------------------------------
------------
3. Interesting Employment in Washington, Texas, Virginia
Job postings courtesy of Monster.com.
NINTENDO, NETWORK SECURITY ANALYST
Position Type: Full time
Location: Redmond, Wash.
Salary: Not specified
Experience: 3 to 5 years
Desired Education: CCNA, MCSE
The network security analyst will be responsible for all
network
security issues, including ensuring compliane with
Sarbanes-Oxley,
training users and developing security policies. Must have
experience
with TCP/IP, routing, Linux and Unix.
To learn more, visit:
http://jobview.monster.com/getjob.asp?JobID=57531850
-----------------------------
WHOLE FOODS MARKET, NETWORK ENGINEER
Position Type: Full time
Location: Austin, Texas
Salary: Not specified
Experience: 3 to 5 years
Desired Education: CCNA
Responsibilities include performing daily maintenance of
company
network, troubleshooting, researching and implementing
network
solutions. Candidates must have experience with
routing/switching,
LAN/WAN, DHCP and DNS. Must also have knowledge of Linux,
Unix and
wireless technologies. After-hours, on-call availability
required.
To learn more, visit:
http://jobview.monster.com/getjob.asp?JobID=57499558
-----------------------------
VIRGINIA WORKERS' COMPENSATION COMMISSION, LEAD ENGINEER
Position Type: Full time
Location: Richmond, Va.
Salary: $90,000/year
Experience: 5 to 7 years
Desired Education: Bachelor's degree, MCSE, CCNA
The lead engineer will supervise two engineers and be
responsible for
maintaining the organization's network and server
infrastructure.
Duties include meeting SLAs, recommending improvements and
acting as
the organization's Information Security Officer. Must have
thorough
knowledge of LAN/WAN and Windows servers. Deadline for
resumes and
applications is May 25.
To learn more, visit:
http://jobview.monster.com/getjob.asp?JobID=57560074
************************************************************
************
SPONSOR: EMC Reduces Costs, Improves Management of Exchange
Deployments
************************************************************
************
Read this case study and learn how EMC can help you improve
management
of Exchange Server 2007 deployments with integrated hardware
and
software and a dedicated Microsoft-trained team for
planning,
integration, and support services.
Download it today:
http://in
fo.101com.com/default.asp?id=38690
************************************************************
************
FREE MAGAZINE OFFERS
Subscribe now to our free monthly magazines:
NEW! Redmond Developer News magazine
https://subscribe.1105pubs.com/sub/RW?WP=NEW
FREE&TC=1&PC=MK5
Redmond Channel Partner magazine
https://subscribe.1105pubs.com/sub/RN?WP=NE
WFREE&TC=1&P=OCP01
Redmond magazine
https://subscribe.1105pubs.com/sub/MI?WP=NEWF
REE&TC=1&P=TCP
Sign up for all our related FREE newsletters today.
https://newsletters.1105pubs.com/nl/RMG.do?NL=49
00&PC=TCPNLF
Encourage your peers to excel!
Please forward this newsletter to any IT professional.
************************************************************
************
To learn how you can sponsor a future edition of this
newsletter,
contact Matt Morollo at (508) 532-1418 or
e-mail mmorollo 1105media.com
Contact the editorial staff at editor tcpmag.com
Newsletter problems: RED 1105service.com
TCPmag.com
Redmond Media Group
16261 Laguna Canyon Road, Suite 130
Irvine, CA 92618-3608
Phone 949-265-1520
************************************************************
************
UNSUBSCRIBE OR CHANGE E-MAIL ADDRESS:
https://newsletters.1105pubs.com/nl/RMGf.do?e=nessto sharedlog.com&NL=4900
************************************************************
************
To review our Privacy Policy, visit our Web site at
http://www.1105
media.com/privacy.aspx
Copyright 2007 1105 Media Inc. TCPmag.com News may
only be redistributed in its unedited form. Written
permission
from the editor must be obtained to reprint the information
contained within this newsletter. Contact: editor tcpmag.com
|