search

melicertes / csp

The Cyber Security Platform MeliCERTes is part of the European Strategy for Cyber Security. MeliCERTes is a network for establishing confidence and trust among the national Computer Security Incident Response Teams (CSIRTs) of the Member States and for promoting swift and effective operational cooperation.
Other
31 stars 7 forks source link

Connection testing #32

Closed sim0nx closed 5 years ago

sim0nx commented 5 years ago

Hi,

Could you please not try to connect to google.com:443 for "internet connectivity" testing ? That seems to be pretty absurd for a controlled production environment, even more as the node already requires connectivity to the central. Checking for connectivity to the central should be enough.

thanosa75 commented 5 years ago

Comment understood and under consideration - address was chosen initially but already we have a set of various services (e.g STUN service) that we need to have accessibility to, global DNS, etc. The actual connections shall be enumerated (in the installer logs) and google.com:443 http://google.com:443/ shall be removed.

Central is indeed a must but also -for the time being- access to Docker Hub.

On 6 Jun 2019, at 10:41, Georges Toth notifications@github.com wrote:

Hi,

Could you please not try to connect to google.com:443 for "internet connectivity" testing ? That seems to be pretty absurd for a controlled production environment, even more as the node already requires connectivity to the central. Checking for connectivity to the central should be enough.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/melicertes/csp/issues/32?email_source=notifications&email_token=AAJ7HVYCYCJX6L37Y3AEEQ3PZC5T7A5CNFSM4HU5GV62YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GX6L2MA, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ7HV3ZUXC5OZQGUDYYFO3PZC5T7ANCNFSM4HU5GV6Q.

sim0nx commented 5 years ago

Good that google.com checking will be removed.

STUN should be hosted by those hosting the CENTRAL. Global DNS? You should use was is locally available, not some random open resolver.

Docker Hub access is not documented, neither is DNS, STUN, .... It seems that you expect people to run this VM with any/any access ?

ghost commented 5 years ago

Do not only check if the connection to the central node works, but also to the update server(s) of Alpine Linux!

apk update
apk upgrade

Otherwise you end up with an outdated system very fast.

ghost commented 5 years ago

It seems that you expect people to run this VM with any/any access ?

I currently have an open question with trust-central about firewall rules too (which are still badly/not described in the documentation). As far as I currently know 443/tcp outgoing to ANY is the recommendation (which prevents alpine updates...).

sim0nx commented 5 years ago

Thanks for the hint @wagner-certat . 443/tcp to any? lol, not doable. Where do I set proxy settings and where do I get a list of http/https destinations that should be enabled @thanosa75 ?

ghost commented 5 years ago

Thanks for the hint @wagner-certat . 443/tcp to any? lol, not doable.

According to an answer "only during the install check". So firewall rules for setup and afterwards differ :/

Rafiot commented 5 years ago

Is there any team using the soft in production at this point? That would probably be the most reliable way to figure that out.

sim0nx commented 5 years ago

Not yet. But I guess it would be a better starter to get the documentation completed / fixed.

Rafiot commented 5 years ago

That would be optimal, but that only works if the developers can/want to answer our questions. Otherwise, we will need to figure it out by ourselves.

thanosa75 commented 5 years ago

@Rafiot please do not assume that developers do not want to answer questions. We do have also other tasks.

It seems that you expect people to run this VM with any/any access ?

No this is not the case.

I currently have an open question with trust-central about firewall rules too (which are still badly/not described in the documentation). As far as I currently know 443/tcp outgoing to ANY is the recommendation (which prevents alpine updates...).

This is not a recommendation; please do not assume.

Documentation will be updated with minimum connectivity requirements. Bear in mind that the network administrator is expected to enforce own system policy. CSP cannot enforce or restrict this; your net-admin may choose to keep connectivity closed. Even for CSP-2-CSP communication, a list of approved IP addresses is maintained centrally, and if CSIRTs choose to include parties in their LTC to communicate, they should add in their firewall whitelists the relevant IP addresses. Now, choosing to use e.g VC bridge, will require e.g 10000/udp (media) - otherwise it will not work. Other integrated apps may have additional requirements.

Hope this clears it a bit.

iglocska commented 5 years ago

Just to skip the wall of text in this thread, so is there a definitive list of ports to open?