Cloudmin with ConfigServer

8 posts / 0 new
Last post
#1 Sun, 05/13/2018 - 03:55
Steffan
Steffan's picture

Cloudmin with ConfigServer

I have a Xen host running CentOS 7. The NICs in use for the wan are p1p1 and xenbr0.

I installed CSF and the webmin module but am not achieving any level of protection for the host. I've tried auto selection of the NIC (by default) and setting the NIC to both p1p1 and xenbr0 one at a time.

With the NIC set to p1p1, the guest OSes are still accessible, however the host os is completely unreachable. Switching the NIC to xenbr0, nothing is blocked.

Suggestions?

Tue, 05/15/2018 - 08:57
scotwnw

CSF should be on for the main interface, not the bridge. Although it can be on for 'all' or 'any' number of interfaces. I believe it defaults to all, which I have never changed. And Each VM needs it own firewall. The server firewall has nothing to do with protecting VMs on a bridged network.
CSF is only going to protect the main server. It is not going to protect the VMs if they are on a bridged network. Because by being bridged, they are acting like they are just another physical server with their own nic and net connection. So you need CSF on all VMs you want to protect just like you would need CSF on all physical servers. IF you're using a bridged setup that is. If VMs are NAT'd, its a different story.

bridged = VMs get public ip on their own and are directly connected to net, just like a physical server. Can have Many public IPs. NAT'd = like your house Internet, where VMs are behind a router and traffic is forwarded to different machines, VMs. 1 public IP and many lan Ips.

"With the NIC set to p1p1, the guest OSes are still accessible, however the host os is completely unreachable" This tells me its working fine. Main server is blocked, but VMs on bridge public IPs are not. You just need to open port or allow IPs in to manage main server. OR check to be sure your IP hasnt been banned. CSF defaults to permanent bans. Have you turned off test mode? If so, turn it on so it will allow you back in after 5min.

Tue, 05/15/2018 - 10:24
scotwnw

FYi, checked and my interfaces settings in CSF is blank, meaning firewall is applied to all interfaces. I also had to add a line to /etc/csf/csfpost.sh to allow forwarding on the bridge port br0.

In /etc/csf/csfpost.sh add to match your bridged interface name

iptables -A FORWARD -i br0 -o br0 -j ACCEPT

Wed, 05/16/2018 - 02:35
Steffan
Steffan's picture

I set this up exactly as you said. I can see in the log that it is running the command csfpost.sh. I blocked port 22 just to test it and sure enough, I can still get right to the host. Any other ideas?

Wed, 05/16/2018 - 02:40
Steffan
Steffan's picture

Alright... Feeling dumb... When you install CSF, it automatically whitelists your IP. It is working. I just need to ensure I have all necessary ports open for Cloudmin to do its bit. Recommendations?

Wed, 05/16/2018 - 10:57
scotwnw

All you need open to access cloudmin is port 10000. Then For cloudmin to manage VMs, it will need to access to 10000:10010 on the VMs.

In CSF, I have 10000 for TCP_IN and 10000:10010 in TCP_out. The "IN" port allows you in from outside and the "OUT" allows cloudmin to get out to talk to VMs or talk to other physical servers.

Firewalls on the VMs will also need to allow 10000:10010 from the cloudmin host, that is If you're in control of the VM. If a user controls his own VM, cloudmin will not have access and in the server list, it will just show up as ALIVE. Can still be start, stopped, rebooted. Just no internal management abilities.

The most confusing thing for me at first with CSF was it blocks ALL traffic (in and out). Most other firewalls allow all outgoing, which can make setup easier. So as long as you remember to open outgoing ports as well, should have no issues. Like in the example above we know ports 10000:10010 need to be open on the input side of the VM. This also means the same ports need to open on the output side of the host.

Another tip on abusive VM users. Say like a spammer. When I ask them to stop and they dont... that file csfpost.sh can be used to block what ever port they are using at the bridge before it gets to their VM. They have generally locked you out of SSH and ping so, as in the post above we are forwarding all bridge traffic. So just put a line above that to drop all traffic on certain port for the offending iP. (fix the glitch) lol. His machine will still work, but the spam wont go through, and he wont know why. He should have listened to the first request.

Wed, 05/16/2018 - 11:14
Steffan
Steffan's picture

After checking listening ports and verifying a few things, here is what I found I needed:

IN: 22,53,111,822,5800:5810,5900:5910,10000:10010
OUT: 22,25,53,80,111,443,822,2211,2222,5800:5810,5900:5910,10000:10010

On the out, I have a couple people running SSH on odd ports so I had to include those. Without some of those ports, other than 10000:10010, CM showed all systems were down.

Only thing now is to do some more reading on the rsyslog restrictions so that lfd will be more accurate etc.

Wed, 05/16/2018 - 11:25
scotwnw

Good call, had forgotten CM needed SSH also. Although I have had clients that blocked SSH and ping from the host before. First sign they will be a spammer.

Topic locked