Hear, hear, Bart!  As an infosec pro, I was a bit appalled after first installing HamWAN and seeing such lax security, akin to leaving the front door open all day&nite of your house in Sodo.  I removed the remote access and reporting configuration from my client nodes for this reason, but now I hear the control nodes have their doors open?  Recipe for disaster and subsequent need for DR that can be prevented.

Stephen W9SK

All of the network's control points are on public non-firewalled IPs.  

This is the worst security.  It was done this way for the sake of 

simplicity.  Our netops volunteers had to get up to speed with 

unfamiliar concepts like routing, funky netmasks, dynamic routing 

protocols, policy routing, VRRP, firewalls, MTUs, MSS control, IPsec, 

etc.  We reaped the rewards of KISS from broader volunteer engagement, 

but lately we've been paying too heavy of a price for the awful security 

this simplicity creates.  In the most recent breach we've lost important 

source code that will now need to be re-created.  We escaped total 

disaster by the thinnest of margins, as one critical hypervisor just 

happened to be patched to 1 version higher than exploitable.  This 

simplicity is not a good tradeoff anymore, so the time has come to 

introduce more complexity to the network to protect all control points.

This is not a simple problem, since there are many fragility vs security 

tradeoffs, as well as complexity cost concerns.  If you have experience 

or thoughts around this area, and can commit to a few weeks of design 

and implementation work on this project, please indicate your interest.  

We'll assemble a small working group in the next few days and start 

discussions.  I expect the working format will involve some virtual 

meetings, since email is not high bandwidth enough to hash out 

everything quickly.

Here's hoping we don't make it worse,

--Bart

_______________________________________________

PSDR mailing list

PSDR@hamwan.org

http://mail.hamwan.net/mailman/listinfo/psdr