Re: Query: Role of Firewalls within a SAN environment itself not just the periphery

[david () lang hm]

On Wed, 13 Apr 2011, Fetch, Brandon wrote:

> Brian,
> I think you may be missing a single key bit of information in your discussion - fiber channel (FC) layer 2 (L2) is 
> immensely different form Ethernet L2.
> Yes, both protocols run IP "on top" (at layer 3) and both run on fiber but to be able to put a firewall and/or filtering 
> device between hosts, FC switches, or disk you're talking a whole different animal.
>
> Not to leave specifics out of a reply to your question but the details would involve a rather lengthy post.
> Suffice it to say that involving any sort of filtering on a fiber channel (FC) switch would seriously degrade disk 
> performance and by extension not be usable in a production environment.

that all depends on the latency that the filtering adds.

> Though I'm not familiar with the specific documentation you were reviewing, I'd bet money the filtering they reference 
> is more for the management interface rather than the VSAN interfaces or physical ports themselves: limiting what hosts/networks 
> are allowed to connect/reach the device for management and via which protocols.

there are switches that you can configure what systems~ are allowed to 
access what devices at the switch level. These sorts of things are very 
course, and frequently just lock down what ports are allowed to talk to 
what other ports, but sometimes will go beyond that. With the proper 
hardware support in the switch they can operate at wire speed with very 
little latency (after all, they are only looking at the address, not the 
contents)

given that you can buy ethernet switches that can implement ACLs at 10Gb
wire speed, the fact that you can do 4Gb fiberchannel filtering of this 
type should not be a shock.

David Lang

> The term VSAN is something of a misnomer (used mainly to provide an easily understood parallel to Ethernet) in that it's more of an L2 
> descriptor.  It's used to segment & identify the disk frames as they traverse the switch and to verify whether a specific world-wide-name 
> (WWN - think of it like an Ethernet MAC address) is allowed to speak on a particular VSAN.  I'm not sure if anyone's ever reported someone 
> successfully impersonating another's WWN while on a FC switch and successfully reading or writing to disks on the assigned VSAN.
>
> Essentially where an Ethernet hosts (and switches) can "automagically" build their forwarding tables using ARP and rARP 
> requests or broadcasts, an FC switch will have to have these tables built statically by the operator.
> This goes more to having absolute confirmation a block was received & written by a device (FC) rather than a system 
> being able to wait for timeouts or errors and possibly re-request the same information (Ethernet).
>
> I hope that helps explain why you can't "firewall" a SAN.
>
> Regards,
> Brandon
>
> ________________________________
> From: firewall-wizards-bounces () listserv icsalabs com [mailto:firewall-wizards-bounces () listserv icsalabs com] On 
> Behalf Of brian dorsey
> Sent: Tuesday, April 12, 2011 6:12 AM
> To: firewall-wizards () listserv icsalabs com
> Subject: [fw-wiz] Query: Role of Firewalls within a SAN environment itself not just the periphery
>
> Hi all,
>
> I am wondering what your view point is with respect to firewalls within a Storage Area Network (SAN) environment.
>
> I am a SAN novice and I am interested in getting to know this area further.
>
> The literature that I have found since yesterday does not seem to have major role for a firewall within the SAN 
> environment itself. I see that some documentation places a firewall a the edge of the SAN. But what about firewalls 
> between switches/routers etc within the SAN?
>
> As I understand it, SAN switches like those from Cisco (just reading documentation on Cisco 9000 series switches) provide IP/port 
> filtering of packets and can create VLAN-like SAN's called VSAN's.
>
> The thing is, would it not also be wise to install firewalls either network-based or locally on end SAN systems to 
> provide defense in depth and also provide greater filtering granularity if required?
>
> > From what I can see, at the switch level only basic filtering can be done.
>
> Has anyone any documentation or diagrams of a typical SAN architecture that also include (traditional non-switch based) 
> firewalls?
>
> These switches maybe managed over telnet and ssh ports etc. And I presume a firewall in conjunction with a switch's own 
> access controls would provide additional security in restricting who (administrator IP address) can communicate with the 
> switch over such ports.
>
> Similarly, there maybe a requirement for DPI or stateful inspection of some packets/communications for whatever reason. A 
> firewall such as Linux iptables (is what I am familiar with) can provide this level of fine-grained access control on behalf 
> of the switches where the switches don't appear to have this level of granularity.
>
> I also notice, that the Cisco 9000 series switches only allow a maximum of 250 IP filter rules. I have not read up on 
> other technologies yet, but this may or may not be the normal limit for filtering at a switch level.
>
> I also notice that the SAN switches seem capable of filtering/firewall at the layers 3 and 4 of the TCP/IP stack! I 
> always presumed that switches operated at layer 2 (MAC addresses). So, this is interesting for me to have learnt.
>
> So basically, I want to discover what your opinions are with respect to the role of firewalls (be that packet filters, 
> SPI and/or DPI) within the SAN network itself. [I presume IDS has a role also]
>
> [I know that it is considered best practice that firewalls be placed upfront in the traditional way: at the 
> gateway/Internet, in between the DMZ and application servers network and in between the application server tier and the 
> SAN at the back-end.
>
> many thanks,
> Brian.
>
>
> This message is intended only for the person(s) to which it is addressed
> and may contain privileged, confidential and/or insider information..
> If you have received this communication in error, please notify us
> immediately by replying to the message and deleting it from your computer.
> Any disclosure, copying, distribution, or the taking of any action concerning
> the contents of this message and any attachment(s) by anyone other
> than the named recipient(s) is strictly prohibited.
_______________________________________________
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