Send firewall-wizards mailing list submissions to
firewall-wizards@honor.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@honor.icsalabs.com
You can reach the person managing the list at
firewall-wizards-admin@honor.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: Discretionary WiFi Access (Orca)
2. PacSec/core05 Call For Papers (Dragos Ruiu)
3. Intel vs. special purpose FW-1 servers (Emily Conrad)
4. Forwarding traffic to an active IDS/Firewall (Vinicius Pavanelli Vianna)
5. Re: Discretionary WiFi Access (Vinicius Moreira Mello)
6. Internet accessible screened subnet - use public or private IPs? (Matt Bazan)
7. Re: Is NAT in OpenBSD PF UPnP enabled or Non UPnP? (Darren Reed)
8. Re: The Death Of A Firewall (Marcus J. Ranum)
9. Re: The Death Of A Firewall (Kerry Thompson)
10. Re: The Death Of A Firewall (Martin Hoz)
11. Re: The Death Of A Firewall (Devdas Bhagat)
12. Re: The Death Of A Firewall (Victor Williams)
--__--__--
Message: 1
From: "Orca" <klrorca@hotmail.com>
To: <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Discretionary WiFi Access
Date: Thu, 14 Jul 2005 18:30:40 -0700
I had this issue come up. What I did was feed a Wi-Fi network into a 3030
Cisco VPN concentrator. I then set up a key card access for passwords, ands
assigned multiple guest accounts. I used SB radius for AAA. I used RFC
1918
space for the DHCP so they had to NAT to get out, just to add another layer
(and use the firewall). I also made sure to kill split tunnel. I logged the
mac-address/IP address with the account login, so I had a audit trail for
forensics in case I ever needed it.
I used ACLs and physical separation for these accounts they could then
access the internet, and limited DMZ resources, but completely were cut off
from our intranet.
If a vendor needed them the receptionist would hand out a key card, the
client, log the time in and out, and make them present ID, so we knew what
account matched which guest.
I also checked the signal bleed outside the building, just to be sure, and
monitored the bandwidth with remote alerts for high bandwidth use, to watch
for abuse.
It worked very well, well enough that I did the same for employees - but
with more access.
Hope this helps.
-Steve
> >
> > Dave Null wrote:
> > > Its not firewall related, but there's some smart minds on this list.
> > > My company has started looking into campus-wide WiFi. I'll keep my
> > > personal feeling on this to myself though. One thing that keeps
> > > comming up is that one of the largest user communities that would take
> > > advantage of this would be non-employees. Vendors, Salesmen, people
> > > meeting with GMs/VPs/Execs are probably going to be the main users of
> > > this. My question is, if you currently have a similar situation in
> > > your work environment, how do you handle granting these people
> > > temp/guest WiFi access.
> > >
> > > Access controls for employees can be fairly stringent (i.e. only
> > > connect from company owned assets who's MAC is inventoried, use of 2
> > > factor authentication, etc), but a lot of this isnt applicable for
> > > temporary visitors. I know one company that would give you a WiFi card
> > > when you signed in that was in their database of 'allowed' MAC
> > > addresses (I know, dont get me started on MAC spoofing), however I
> > > would bet cash money that those cards walked away regularly. Similar
> > > thing with issuing a temporary token fob (SecureID or the like).
> > >
> > > I know the easy answer here is 'Dont give them WiFi access', but I
> > > don't think that is going to be an option. Thoughts, comments, flames?
> > >
> > > -noid
> >
> > I have setup an access point outside of our firewall for this express
> > purpose. It is wide open and I simply monitor port usage to keep an eye
> > out for any abuse, it hasn't been an issue so far.
> >
> > Josh
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards@honor.icsalabs.com
> > http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
> >
>
--__--__--
Message: 2
From: Dragos Ruiu <dr@kyx.net>
Organization: All Terrain Ninjas
To: firewall-wizards@honor.icsalabs.com
Date: Tue, 12 Jul 2005 11:44:13 -0700
Subject: [fw-wiz] PacSec/core05 Call For Papers
English url: http://pacsec.jp/speakers.html?LANG=ENGLISH
Japanese url: http://pacsec.jp/speakers.html?LANG=JAPANESE
PacSec/core05 CALL FOR PAPERS
World Security Pros To Converge on Japan November 15/16
TOKYO, Japan -- To address the increasing importance of information
security in Japan, the best known figures in the international security
industry will get together with leading Japanese researchers to share
best practices and technology. The most significant new discoveries
about computer network hack attacks and defenses will be presented
at the third annual PacSec conference.
The PacSec/core05 meeting provides an opportunity for foreign
specialists to be exposed to Japanese innovation and markets, and
to collaborate on practical solutions to computer security issues. In
a relaxed setting with a mixture of material bilingually translated into
both English and Japanese, the eminent technologists can socialize
and attend training sessions.
Announcing the opportunity to submit papers for the third annual
PacSec/core05 network security training conference. The conference
will be held November 15/16th in Tokyo at the Aoyama Diamond Hall.
The conference focuses on emerging information security tutorials - it
will be a bridge between the international and Japanese information
security technology communities.
Please make your paper proposal submissions before Aug 1 2005.
Slides for the papers must be submitted by October 1st 2005.
The conference is November 15th and 16th 2005, presenters need
to be available in the days before to meet with interpreters.
Some invited papers have been confirmed, but a limited
number of speaking slots are still available. The conference is
responsible for travel and accomodations for the speakers. If you
have a proposal for a tutorial session then please email a
synopsis of the material and your biography, papers and,
speaking background to core05@pacsec.jp. Tutorials are
one hour in length, but with simultaneous translation should
be approximately 45 minutes in English, or Japanese.
Only slides will be needed for the October paper deadline,
full text does not have to be submitted.
The PacSec/core05 conference consists of tutorials on technical
details about current issues, innovative techniques and best
practices in the information security realm. The audiences are a
multi-national mix of professionals involved on a daily basis
with security work: security product vendors, programmers,
security officers, and network administrators. We give
preference to technical details and new education for a
technical audience.
The conference itself is a single track series of presentations
in a lecture theater environment. The presentations offer
speakers the opportunity to showcase on-going research
and collaborate with peers while educating and highlighting
advancements in security products and techniques.
The focus is on innovation, tutorials, and education
instead of product pitches. Some commercial content
is tolerated, but it needs to be backed up by a technical
presenter - either giving a valuable tutorial and best
practices instruction or detailing significant new
technology in the products.
Paper proposals should consist of the following information:
1) Presenter, and geographical location (country of origin/passport)
and contact info (e-mail, postal address, phone, fax).
2) Employer and/or affiliations.
3) Brief biography, list of publications and papers.
4) Any significant presentation and educational experience/background.
5) Topic synopsis, Proposed paper title, and a one paragraph description.
6) Reason why this material is innovative or significant or an
important tutorial.
7) Optionally, any samples of prepared material or outlines ready.
Please forward the above information to core05@pacsec.jp to
be considered for placement on the speaker roster.
cheers,
--dr
--
World Security Pros. Cutting Edge Training, Tools, and Techniques
Tokyo, Japan November 15/16 2005 http://pacsec.jp
pgpkey http://dragos.com/ kyxpgp
--__--__--
Message: 3
From: "Emily Conrad" <emilydconrad@hotmail.com>
To: firewall-wizards@honor.icsalabs.com
Date: Tue, 12 Jul 2005 20:17:59 +0000
Subject: [fw-wiz] Intel vs. special purpose FW-1 servers
Hello,
We are working on a project to upgrade our firewall infrastructure.
One of the questions is whether to use FW-1 on a standard Intel server or to
use a special-purpose optimized version of FW-1 on a dedicated hardware
platform such as Nokia firewall appliance or Crossbeam systems C30/X40.
Does anyone have any advice on what factors are important when making such a
decision?
Thanks,
Emily
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar � get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
--__--__--
Message: 4
Date: Wed, 13 Jul 2005 18:39:35 -0300
From: Vinicius Pavanelli Vianna <ds@hacked.com.br>
To: firewall-wizards@honor.icsalabs.com
Subject: [fw-wiz] Forwarding traffic to an active IDS/Firewall
Hi all,
Anyone knows how I can forward all traffic the came to a Cisco Catalyst
swith to an gateway to do some IDS/Firewall/Traffic Shape?
In ipfw (freebsd) this would be done by an "fwd" rule to forward all
packets to an forced gateway, this can be done in an cisco device or i
need to emulate all the valid IPs on the switch and use a VLAN with the
servers so the IDS receive the packets and forward to the internal VLAN,
this would be a little harmful ;)
TIA,
Vinicius
--__--__--
Message: 5
Date: Wed, 13 Jul 2005 22:50:49 -0300
From: Vinicius Moreira Mello <vmmello@inf.ufrgs.br>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Discretionary WiFi Access
Jose Varghese wrote:
>
> Keeping it simple: Physical segregation and only Internet access
Sorry, but I don't agree. If you deploy and maintain the network you'll
be liable for any legal action against you in case of misuse. Making
reality simpler is not the same as creating simple solutions.
I would consider studying solutions #2 or #3 from John Adams's message.
There are some guides/howtos out there that show how to configure such
scenarios.
Best regards,
vmm.
--__--__--
Message: 6
Date: Fri, 15 Jul 2005 13:01:45 -0700
From: "Matt Bazan" <Mbazan@onelegal.com>
To: <firewall-wizards@honor.icsalabs.com>
Subject: [fw-wiz] Internet accessible screened subnet - use public or private IPs?
Is there a preferred method of setting up a Internet facing screened
subnet and the use of public or private IP addresses? Looking at
redesinging our DMZ to only include public resources (www, smtp, imap,
ftp). Presently we use a private IP address range for this that is
NAT'ed at our firewall. Any reasons to change this policy to using
public IPs in the DMZ? Thanks,
Matt
--__--__--
Message: 7
From: Darren Reed <darrenr@reed.wattle.id.au>
Subject: Re: [fw-wiz] Is NAT in OpenBSD PF UPnP enabled or Non UPnP?
To: "Paul D. Robertson" <paul@compuwar.net>
Date: Tue, 19 Jul 2005 03:42:42 +1000 (EST)
Cc: Darren Reed <darrenr@reed.wattle.id.au>,
Chuck Swiger <chuck@codefab.com>, firewall-wizards@honor.icsalabs.com
To return to a long forgotten about thead...
> On Sun, 5 Jun 2005, Darren Reed wrote:
>
> > > Security is about staid and static- that's part of the issue of why it's
> > > difficult to inject it into companies that don't have a real driver for
> > > it.
> >
> > I disagree. Security is about being conservative, which doesn't
> > necessarily imply being static/staid. I think being static/staid can
>
> Oh, but it does- the essence of security is about the tried and true.
> Basic principles haven't changed in thousands of years, even when applied
> to new technologies. Security evolves very slowly, which is why the
> marketing weasels have so much trouble with it.
>
> > lead you down a path that can increase your security risk rather than
> > maintain it. I think being conservative, when it comes to IT, is just
> > plain HARD and this is why companies find it difficult.
>
> Google define: conservative:
..
It might be similar to staid, but it's not the same as static.
> Anything poorly implemented can increase your security risk, however it's
> very rare that disallowing new content is one of them.
I'd contend that when it comes to the web, by default you generally
allow new content, whether you like it or not and may at some time
later decide it is bad.
> > I also think you're wrong about security needing to be a governor,
> > because security types are too conservative and being a governor is
> > to try and manage a situation you have no real control over. THey
>
> You're assuming security people don't have control. This, I think is
> Marcus's main point about giving in too soon. If I have the passwords to
> the firewall, I have control over what traverses it.
I'll argue that you don't have control over what traverses it - in terms
of content. You might control who connects to what.
> > As with the web, so too with any popular technology,
> > if the designers aren't security savvy then we will have problems by
> > design, later. If security misses out at this step then it is very hard
> > to shove it into the box later.
>
> Which is why we prefer to slow them down and make them get it right than
> to react to their dynamic ideas.
I don't think time makes any difference. Things need to be forced
through peer review with security analysis as the primary objective
of evaluation. Put a bunch of Microsoft programmers in a room and
it won't matter if you give them 6 months or 6 years, they'll still
come up with something insecure at the end. The only difference
the time will be the number of useless features.
Darren
--__--__--
Message: 8
Date: Mon, 18 Jul 2005 23:42:44 -0400
To: "James Paterson" <jpaterson@datamirror.com>,
<firewall-wizards@honor.icsalabs.com>
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: Re: [fw-wiz] The Death Of A Firewall
>http://www.securitypipeline.com/165700439
Well, there's the part that shows that he obviously doesn't
understand the underlying symmetries of security:
"Our new security posture gives our users access to more applications
regardless of their location and without sacrificing security"
mjr.
--__--__--
Message: 9
Subject: Re: [fw-wiz] The Death Of A Firewall
From: Kerry Thompson <kez@crypt.gen.nz>
To: firewall-wizards@honor.icsalabs.com
Date: Tue, 19 Jul 2005 16:12:23 +1200
On Sat, 2005-07-09 at 17:33 -0400, James Paterson wrote:
http://www.securitypipeline.com/165700439
>
> Be interesting to get the communities take on this article.
>
It was covered on slashdot a couple of weeks ago.
It starts off with grand contentious statements such as "I proposed to
our technology architects that we eliminate our network firewalls", but
in the details we see that they implement a tiered structure with a DMZ
and ACLs on layer-3 switches, which from a distance looks a lot like a
firewall structure to me.
So, they seem to have got rid of the commercial boxes with "FIREWALL" on
the front, and implemented defence in depth. Good on them for thinking
about the problem and implementing a nice workable solution, but its
hardly new.
--
Kerry Thompson CCNA CISSP
http://www.crypt.gen.nz
--__--__--
Message: 10
Date: Mon, 18 Jul 2005 23:35:49 -0500
From: Martin Hoz <martinhoz@gmail.com>
Reply-To: Martin Hoz <martinhoz@gmail.com>
To: James Paterson <jpaterson@datamirror.com>
Subject: Re: [fw-wiz] The Death Of A Firewall
Cc: firewall-wizards@honor.icsalabs.com
On 7/9/05, James Paterson <jpaterson@datamirror.com> wrote:
> http://www.securitypipeline.com/165700439
>=20
> Be interesting to get the communities take on this article.
>=20
I'd like to raise a couple of things:
A) the article says " By defining simple ACLs, we further isolate our
backend servers" - I ask, is not an ACL a firewall after all? - Packet
filter, but I think it fits in the definition of a firewall.
So, this makes me thing the author still thinks that some form of
firewall still has some use in the network, AFA I can tell
B) "The servers and their respective applications sit in their own
DMZ, protected by an Application-layer firewall". So, an application
firewall still has some uses too...
I find the article interesting but contradictory... because, if the
firewall is dead, how come there are still good uses to it?
Perhaps the author was referring to a "perimeter packet filtering
firewall", but still not sure...
My humble comments.
- Mart=EDn.
--__--__--
Message: 11
Date: Tue, 19 Jul 2005 15:23:17 +0530
From: Devdas Bhagat <devdas@dvb.homelinux.org>
To: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] The Death Of A Firewall
Reply-To: Devdas Bhagat <devdas@dvb.homelinux.org>
On 09/07/05 17:33 -0400, James Paterson wrote:
> http://www.securitypipeline.com/165700439
>
> Be interesting to get the communities take on this article.
He replaced a simple packet filter with a defense in depth security
architecture (more commonly known as a firewall).
Devdas Bhagat
--__--__--
Message: 12
Date: Tue, 19 Jul 2005 08:56:14 -0500
From: Victor Williams <vbwilliams@neb.rr.com>
To: James Paterson <jpaterson@datamirror.com>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] The Death Of A Firewall
I think it's misleading.
The article is titled "The Death Of A Firewall". Yet, in the fourth
paragraph, "By defining simple ACLs, we further isolate our backend
servers."
The word *firewall* is just another way to say ACL. But firewall has
somehow morphed into this word meaning that some *hardware device* needs
to be sitting between us and cruel world.
They should have titled the article "The Death of the single-function
hardware firewall appliance". Even so, I thought the content was pretty
worthless. Any administrator worth their salt knows that the firewall
is only a step in the total security of a solution. What the article
described is something that people have already been doing when building
new application networks. Until very recently, you couldn't do any
*stateful* ACLs with as many OS'es or network devices. Now that has
changed for the better I believe.
The firewall as the be-all/end-all appliance has been dead for years.
Why did we need someone to write an article that basically described
best-practices like it's some revelation?
James Paterson wrote:
> http://www.securitypipeline.com/165700439
>
> Be interesting to get the communities take on this article.
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>
--__--__--
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest
No comments:
Post a Comment