Inherent insecurity of OSD daemons when using only a "public network"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Something I came across a while agao, but the recent discussion here
jolted my memory.

If you have a cluster configured with just a "public network" and that
network being in RFC space like 10.0.0.0/8, you'd think you'd be "safe",
wouldn't you?

Alas you're not:
---
root@ceph-01:~# netstat -atn |grep LIST |grep 68
tcp        0      0 0.0.0.0:6813            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:6814            0.0.0.0:*               LISTEN     
tcp        0      0 10.0.0.11:6815          0.0.0.0:*               LISTEN     
tcp        0      0 10.0.0.11:6800          0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:6801            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:6802            0.0.0.0:*               LISTEN     
etc..
---

Something that people most certainly would NOT expect to be the default
behavior.

Solution, define a complete redundant "cluster network" that's identical
to the public one and voila:
---
root@ceph-02:~# netstat -atn |grep LIST |grep 68
tcp        0      0 10.0.0.12:6816          0.0.0.0:*               LISTEN     
tcp        0      0 10.0.0.12:6817          0.0.0.0:*               LISTEN     
tcp        0      0 10.0.0.12:6818          0.0.0.0:*               LISTEN     
etc.
---

I'd call that a security bug, simply because any other daemon on the
planet will bloody bind to the IP it's been told to in its respective
configuration.

The above is with Hammer, any version.

Christian
-- 
Christian Balzer        Network/Systems Engineer                
chibi@xxxxxxx   	Global OnLine Japan/Rakuten Communications
http://www.gol.com/
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux