firewall-wizards@listserv.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com
You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Allowing Internet Access to MS Project Server
(Darden, Patrick S.)
2. Black Hat Tokyo + DC and Europe CfPs now open. (Jeff Moss)
3. Nat Limitations? (jason@tacorp.com)
4. Re: Nat Limitations? (Darden, Patrick S.)
----------------------------------------------------------------------
Message: 1
Date: Mon, 8 Oct 2007 08:33:20 -0400
From: "Darden, Patrick S." <darden@armc.org>
Subject: Re: [fw-wiz] Allowing Internet Access to MS Project Server
To: "D Sharp" <drsharp@pacbell.net>
Cc: firewall-wizards@listserv.icsalabs.com
Message-ID: <CBE22E5FF427B149A272DD1DDE1075240184E2DD@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"
Seriously, using Apache's reverse proxy would be easiest and very secure. Here's how you would do it:
1. set up the MS Project Server, complete with web access, on internal LAN, including all applicable AAA (e.g. ADS authentication, and making sure SSL is turned on.
2. set up the Apache reverse proxy on DMZ, allowing only SSL proxying, with only one target available--the MS Project Server. Turn off all other services. Turn on the personal firewall for the server. This link is a tutorial on how to do the Apache part of this: http://www.apachetutor.org/admin/reverseproxies
That's it. Simple and clean.
Cisco's SSL product--never used it. Their IPSEC products are good.
Juniper has great products in general. I have no experience with their SSL product. This reviewer loves it: http://www.networkworld.com/reviews/2005/121905-juniper-summ.html?review=sslvpn
I have used a few SSL vpn appliances, and the one I like best is Nortel's. Here is a comparison of some of the leaders: http://www.informationweek.com/story/showArticle.jhtml?articleID=166404268
--p
-----Original Message-----
From: D Sharp [mailto:drsharp@pacbell.net]
Sent: Friday, October 05, 2007 11:45 AM
To: Darden, Patrick S.
Subject: Re: [fw-wiz] Allowing Internet Access to MS Project Server
Patrick;
All good suggestions below. The freeware/open source is not what our company would normally use.
Also part of the requirement is to avoid "ipsec vpn" like solutions. Which in our company means laptops require the client and security issues the profile/credential.
We looked at CISCO's SSL/VPN product and have issues with it.
Have you heard anything good/bad about Juniper's SSL/VPN?
We have looked at this prior, but used Citrix AAC with Citrix presentation servers for another 3rd party gateway. The PS piece worked, but the AAC did not support the features claimed.
We will look more closely at Juniper.
Thank you in advance for any additional information you can share.
Thanks,
Duncan
You could use several solutions. Here are a few:
--apache reverse proxy, free and industry standard http://www.apachetutor.org/admin/reverseproxies
--squid https web proxy server, free and industry standard http://www.squid-cache.org
--secure citrix gateway http://www.citrix.com/English/ps2/products/product.asp?contentID=15005
--ssl vpn (dozens of these out there, but I like Nortel's: inexpensive, comes with IPSEC vpn too)
--ipsec vpn (again, I love Nortel's Contivity Extranet Switch series--inexpensive and utterly reliable)
--p
-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com
[mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of D
Sharp
Sent: Wednesday, October 03, 2007 12:40 PM
To: Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Allowing Internet Access to MS Project Server
------------------------------
Message: 2
Date: Mon, 08 Oct 2007 19:00:13 -0700
From: Jeff Moss <jmoss@blackhat.com>
Subject: [fw-wiz] Black Hat Tokyo + DC and Europe CfPs now open.
To: "firewall-wizards-honor.icsalabs.com"
<firewall-wizards@listserv.cybertrust.com>
Message-ID: <200710090203.l9923hMc012664@colossus.datamerica.com>
Content-Type: text/plain; charset="us-ascii"
We've finalized the speaker lineup for Black Hat Japan 2007, and we're looking forward to a great show. Attendees will be treated to a roster with more variety and depth than ever.
The schedule and speaker bios are available on-line at:
http://www.blackhat.com/html/bh-japan-07/bh-jp-07-en-schedule.html
http://www.blackhat.com/html/bh-japan-07/bh-jp-07-en-speakers.html
As always, we've worked hard to create a show with timely, technical content and a broad range of topics. Some highlights of this year's program include:
* A talk from Pedram Amini and Aaron Portnoy from Tipping Point about the Sulley fuzzing framework - a game changing, free, highly automated fuzzing suite.
* A talk from Halvar Flake, world-class reverse engineer and one of Black Hat's most sought-after speakers entitled "Automated Unpacking and Malware Classification."
* Brandon Baker of Microsoft will be speaking on the very timely topic of the security model of Windows Server Virtualization in Windows Server 2008.
Please bear in mind that on-line registration closes October 15, and it is a good idea to sign up now to avoid waiting in the long on site registration lines.
The Briefings will once again be held in the Keio Plaza Hotel in Tokyo, on Thursday, October 25 and Friday, October 26. On site registration begins at 09:00 both days.
In other news:
Presentations and white papers from Black Hat USA 2007 are on line, with audio and video coming soon. To know as soon as new content comes on-line, subscribe to our RSS feed at
http://www.blackhat.com/BlackHatRSS.xml
The Black Hat D.C. and Black Hat Amsterdam Call for Papers is now open.
The focus this year for Black Hat D.C. will be both on Offensive tools, techniques, and related technology as well as wireless and near field security. A more detailed CfP will be released next week.
https://cfp.blackhat.com/
See you in Tokyo!
Jeff Moss
------------------------------
Message: 3
Date: Tue, 9 Oct 2007 09:03:24 -0400 (EDT)
From: jason@tacorp.com
Subject: [fw-wiz] Nat Limitations?
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <20071009084916.A24145@phoenix.cnwr.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Hello,
I'm interested in hearing some thoughts on a topology I'm considering in
pursuing. On a mid sized college campus, we have the funding to
physically segment the residence halls from the rest of the campus
network. This is a huge win from a security perspective among other
things. We've also begun using a separate provider for bandwidth. A
long-term goal would be to hand the management of these buildings off to a
company who can maintain it to reduce our headaches.
So, in building it we want to make it as portable as possible. As such,
NAT comes to mind so we don't have to re-number it if a different provider
takes it. It also has a number of other advantages which I'm sure are
well known.
The problem is that I'm concerned about the number of translations that
will happen in these buildings. Currently this part of the network is
allocated a /19 and we estimate there are just over 4,000 residents.
I see some of the pitfalls being:
* The cisco FWSM is limited to 256K concurrent translations. That's only
64 per user. Bit-torrent is likely to slaughter that.
* It's harder to handle RIAA complaints since everything comes from a
different public address.
* Rate limiting (packet shaping) is currently done at the ISP for these
buildings. We'll have to move that inside (more $$) or do protocol
shaping instead of by IP address.
* Certain applications may break, etc.
So my question is:
Has anyone tried to NAT this many of a certain type of user?
and
Do the benefits outweight the caveats?
Jason Mishka - "I'm like a Subway in a land of McDonalds..."
------------------------------
Message: 4
Date: Tue, 9 Oct 2007 10:03:28 -0400
From: "Darden, Patrick S." <darden@armc.org>
Subject: Re: [fw-wiz] Nat Limitations?
To: "Firewall Wizards Security Mailing List"
<firewall-wizards@listserv.icsalabs.com>
Message-ID: <CBE22E5FF427B149A272DD1DDE1075240184E304@EX2K3.armc.org>
Content-Type: text/plain; charset="iso-8859-1"
>From what you have said, I am guessing you want to do this:
res hall 1 res hall 2 res hall 3....
| | |
\ | /
huge central fwsm
|
|
internet
I am guessing you want to segment each res hall off using a single
inclusive VLAN, then NAT it in a central switch or router. I think
you should reconsider. Instead of NATing centrally, why not NAT on
the edge? You can use multiple VLANs, one per res hall, and multiple
NAT's.
End result--further segmentation for better security, reduced load
on your central switch or router (save the CPU for BGP and/or
ACLs--and raw speed!)
Individual concerns:
1. concurrent translations limitation. Not a problem with the above.
2. I weep for the RIAA. You don't have to help them. You just have
to act in accordance with applicable laws. If they give you one of
their John Doe warrants with a single IP address that they claim
corresponds to one person, you can tell them to be more specific due
to NAT. The burden lies on them.
3. The above topography would work better for rate limiting. Less
people would be affected by one or two bandwidth hawgs.
4. Certain applications might well break. NAT tends to break UDP
apps more than TCP. It also tends to interfere with servers. Your
students will not be able to run servers as easily, except inside
the residence halls.
You might want to do this to one residence hall first to test it.
There is no substitute for real-world testing--who knows what
bizarre effects might occur.
One problem you might not have considered is the move to IPv6. You
should NOT invest this much time and effort into such a huge
NAT infrastructure if you plan to move to IPv6 in the next 4 years.
--p
-----Original Message-----
From: firewall-wizards-bounces@listserv.icsalabs.com
[mailto:firewall-wizards-bounces@listserv.icsalabs.com]On Behalf Of
jason@tacorp.com
Sent: Tuesday, October 09, 2007 9:03 AM
To: Firewall Wizards Security Mailing List
Subject: [fw-wiz] Nat Limitations?
Hello,
I'm interested in hearing some thoughts on a topology I'm considering in
pursuing. On a mid sized college campus, we have the funding to
physically segment the residence halls from the rest of the campus
network. This is a huge win from a security perspective among other
things. We've also begun using a separate provider for bandwidth. A
long-term goal would be to hand the management of these buildings off to a
company who can maintain it to reduce our headaches.
So, in building it we want to make it as portable as possible. As such,
NAT comes to mind so we don't have to re-number it if a different provider
takes it. It also has a number of other advantages which I'm sure are
well known.
The problem is that I'm concerned about the number of translations that
will happen in these buildings. Currently this part of the network is
allocated a /19 and we estimate there are just over 4,000 residents.
I see some of the pitfalls being:
* The cisco FWSM is limited to 256K concurrent translations. That's only
64 per user. Bit-torrent is likely to slaughter that.
* It's harder to handle RIAA complaints since everything comes from a
different public address.
* Rate limiting (packet shaping) is currently done at the ISP for these
buildings. We'll have to move that inside (more $$) or do protocol
shaping instead of by IP address.
* Certain applications may break, etc.
So my question is:
Has anyone tried to NAT this many of a certain type of user?
and
Do the benefits outweight the caveats?
Jason Mishka - "I'm like a Subway in a land of McDonalds..."
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
------------------------------
_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest, Vol 18, Issue 4
***********************************************
No comments:
Post a Comment