Is the firewall on the ReadyNAS far below acceptable level?

Jaap_van_Ekris wrote:
I can't believe I am the only one dealing with this issue?

Just for the record, I am not alone. In my search for people who did have a solution for this, I found the following threads:

• http://www.readynas.com/forum/viewtopic.php?f=35&t=44716 (iptables assistance)
• http://www.readynas.com/forum/viewtopic.php?f=35&t=45559 (iptables)
• http://www.readynas.com/forum/viewtopic.php?f=20&t=17390&p=103712&hilit=iptables#p103712 (Firewalling the NAS)
• http://www.readynas.com/forum/viewtopic.php?f=7&t=3676&p=21240&hilit=iptables#p21240 (firewalling / iptables on ReadyNAS)
• http://www.readynas.com/forum/viewtopic.php?f=20&t=21584&p=117795&hilit=iptables#p117795 (Readynas IPtables not configured into kernel?)
• http://www.readynas.com/forum/viewtopic.php?f=35&t=29064&p=160906&hilit=iptables#p160906 (iptables)
• http://www.readynas.com/forum/viewtopic.php?f=18&t=30476&p=187850&hilit=iptables#p187850 (Ipchains kernel support)
• http://www.readynas.com/forum/viewtopic.php?f=7&t=63733&p=357160&hilit=netfilter#p357160 (attempting to build kernel modules for readynas pro)
• http://www.readynas.com/forum/viewtopic.php?f=35&t=29947&p=346403&hilit=netfilter#p346403 (problem installing kernel modules on ReadyNAS Pro Pioneer)

Jaap

There does appear to be a major error, just not the one you describe.

Your post seems to suggest you are responsible for the purchase (or selection) of the ReadyNAS unit for use in your business environment.

So take a moment to consider that, despite specific (and reasonable) corporate requirements, you invested in equipment with no claim of firewall support and - based totally on your own assumption - instead chose to rely on using an unsupported access method to try to enable a totally unsupported capability.

You then expect us to agree with you that given this does not work the way you assumed this is "unacceptable" on the part of Netgear as you are "not in the business of fixing major errors by suppliers"?

As you have now discovered ReadyNAS devices do not feature full IP table support and there is no addon (official or community) to "fix" this.

If you cannot use your other network equipment to protect the NAS, personally I'd suggest the easiest option would be to consider a different supplier - perhaps one that claims firewall support?

sphardy wrote:
So take a moment to consider that, despite specific (and reasonable) corporate requirements, you invested in equipment with no claim of firewall support and - based totally on your own assumption - instead chose to rely on using an unsupported access method to try to enable a totally unsupported capability.

There are some requirements that are so extremely obvious, that it is almost criminal to sell professional equipment without it. Physical disk sizes, Electric compatibility, EMC, electric safety, etc. are also requirements we have but never check because every serious player always complies, but never takes the effort to report it in the spec-sheet (UL compliance can mean a lot of things when you look at it). Most warn you if they don't comply with expected specs for business use.

On the other hand, Netgear actively shows with all its advertised services (FTP, ReadyNAS Photos, ReadyNAS remote, ReadyNAS replicate, Egnyte Cloud Services) that this is a machine that is intended for connecting to the internet and should be reachable through the internet. And lets be serious here: who would connect a system like that to the internet without firewall?

Putting an extra firewall there isn't the solution. There are very good basic security architecture concepts that dictate that every system should take care of itself. This means that even when you have a corporate firewall, putting a system like this in a DMZ will also mean that it will get exposed to serious threats (from other potentially compromised systems). It is not a question of "if", but "when" this happens. And these security concepts dictate that a NAS like this should hold its own inside the DMZ, preventing the hack of a single system becomming a company-wide hack of your customer facing systems (and potentially your internal systems). So adding another firewall isn't a solution, it isn't even close to a bandaid.

Jaap

Jaap_van_Ekris wrote:
... This means that even when you have a corporate firewall, putting a system like this in a DMZ will also mean that it will get exposed to serious threats (from other potentially compromised systems)...

I believe that ReadyNAS Photos, ReadyNAS remote, ReadyNAS replicate, and Egnyte Cloud Services do not require putting the NAS in the DMZ, or even port forwarding.

FTP also does not not require the DMZ either though it does require port forwarding if you use it outside of your corporate network. I would agree that it has a higher security risk since passwords are sent in the clear. A firewall doesn't really help that.

I think sphardy makes a good point. Netgear makes no claims that the Pro 6 has an internal firewall, and you presumed it had one. It would be a nice feature of course. But you can't really blame Netgear, as it appears that you simply didn't do your research.

StephenB wrote:
Jaap_van_Ekris wrote: ... This means that even when you have a corporate firewall, putting a system like this in a DMZ will also mean that it will get exposed to serious threats (from other potentially compromised systems)... I believe that ReadyNAS Photos, ReadyNAS remote, ReadyNAS replicate, and Egnyte Cloud Services do not require putting the NAS in the DMZ, or even port forwarding.

Any sane company requires that systems that can be contacted from the outside world, are in a DMZ. ReadyNAS photos can be browsed by external people, so I guess that kind of service would definitely put it in a DMZ. ReadyNAS remote allows users to change files on the server when on the Internet. That is also by definition internet-user controllable and thus ends up in a DMZ. The fact-sheet for the Pro 6 also says you can work through the internet from Unix/Linux, by definition making the ReadyNAS a system that needs some level of security.

Most enterprises I work for require firewalls on every server, including the ones on internal networks. Just to make sure that hackers don't find an open field they can harvest easily when they succeed in breaking the first layers of security. Just having an outside firewall was what we did in the early '90 's.

So it isn't that much of an expectation that when somebody claims to be enterprise ready and builds systems that directly interact with people on the internet, that you have some self-defence build in. As a supplier, you actively have to change default settings of the kernel to break iptables in the way that they did. By default, the kernel compiles netfilter/iptables with limits, mac-filtering and states. When it says Linux, 99% that is what you get. Even my $150 internet-radio's carry a better version of iptables!

And to be honest, I wish you guys would help solve my problem, instead of blaming me for having high expectations of a reputable supplier claiming to deliver business-ready solutions. A lot of the scenario's described in the business cases delivered for SME are totally idiocracy when you consider somebody would buy the "solution" and hook it up to the internet.

Jaap

Jaap_van_Ekris wrote:
Any sane company requires that systems that can be contacted from the outside world, are in a DMZ. ReadyNAS photos can be browsed by external people, so I guess that kind of service would definitely put it in a DMZ.

Those services all establish outbound connections to a cloud server, so in fact they do not need to be in a DMZ in order to get then to work. If you don't trust the cloud server, you might want to place a firewall between the NAS and the rest of your enterprise network. However, that is not a classic DMZ (at least not as I use the term).

Jaap_van_Ekris wrote:
...And to be honest, I wish you guys would help solve my problem...

sphardy and I are just users. You want Netgear to solve your problem - as you point out, they are kernel modules. And you shouldn't accept community solutions that you can't audit anyway. Have you opened a support request?

99% of the users out there would never need these. GPL sources are available, you could compile those additional modules if you really need them.

Hi Chirpa,

Thanks for your response.

chirpa wrote:
99% of the users out there would never need these. GPL sources are available, you could compile those additional modules if you really need them.

I have some questions on this:

• Wont that kill any upgrade path through the regular updates of Netgear?
• Is there any manual and config for this (all I can find is people reporting what not to do with old hardware, like this thread: viewtopic.php?f=35&t=29947)?

Jaap

If the kernel version changes in a new firmware release, you would have to rebuild the modules. So if you have some boot scripts running for these rules, you would probably want some error catching to notify you if they fail.

That linked thread goes back quite a ways to 4.2.5, very early on. Would take some experimenting.

chirpa wrote:
If the kernel version changes in a new firmware release, you would have to rebuild the modules. So if you have some boot scripts running for these rules, you would probably want some error catching to notify you if they fail.

That is in fact a maintenance nightmare, our internal name for such systems is "babysitter systems". This means that with an update you either run the risk of

• lock you out because the firewall blocks doesn't accept the MACs, Limits and ESTABLISHED rules
• disble the firewall (a good thing).

The ReadyNAS is going back, we will switch to another suppier.

Jaap