This message was deleted.
# neuvector_suse-security
a
This message was deleted.
a
curl, wget, nc - nothing gets noticed by neuvector, can this be correlated to https://github.com/neuvector/neuvector/issues/1800 ?
I’m on 5.4.7
okay after some more trying im just more confused - nothing I tried with the network rule has had ANY effect. trying my luck with the WAF and a sensor which has google.com as a pattern blocked the dns query between my pod and coredns but happily kept allowing the actual curl command towards google.com (???) This seems to be quite an issue, happy to get some feedback on it since the issue I linked from gh doesn’t seem to get any notice
q
The group where your workload lives; what mode is it in?
💡 note: In general, it is a best-practice to avoid deny rules when practicable. NeuVector has a vey zero-trust strategy.
In your use case above (with the disclaimer that I might be misunderstand it 🙂 ) you should find the learned rule that allowed
nv.yourapp.namespace
➡️
external
and just deleted it. If you want this actually enforced, the group needs to be in Protect mode.
a
ye I’m just trying to understand the way network rules work or dont^^ neuvector does not have any app -> external rule the deployment is set to network protect mode (for me that would imply curl or ping commands of any kind should not work) but I can still happily ping and curl google: k exec -it test -- ping google.com PING google.com (142.250.185.142) 56(84) bytes of data. 64 bytes from fra16s50-in-f14.1e100.net (142.250.185.142): icmp_seq=1 ttl=117 time=19.4 ms the sole network rule is for coredns since i’m using hostnames in this example, app in network=protect mode no learned rule to access external site only rule is to access coredns which was learned am I missing the point?
also enforcer and controller pods are quiet as a mouse, they show no logs for any of that and neither does it in security events
restarted controller and enforcer, created a dedicated deny external rule while also being in protect mode none of that had any use
q
Lots to unpack here. 😄
go to Policy... Network and find the rule that matches your group to 'External.' Delete it.
a
😄 I know right? The Policy isnt the issue though, I’ve created the policy after I tried to ping/curl/nc google.com by only setting the group to protect so the policy is not the issue it was merely another possible solution^^ Done and network traffic still goes through (group is still set to protect)
q
but did you delete the group I suggested above?
a
yes
q
yeah hmm okay this seems very weird
but there's several moving parts above
To be clear, what you are attempting to do is supposed to work and it's typically pretty straightforward to do. So I think we need to figure out what's special in your environment.
a
ye thats why I’m confused as well 😄 I will completely remove the app and anything possibly still existing about it, restart the whole neuvector deployment and see if its maybe a caching issue or something, maybe from my testing some old rules/policies are still “stuck” somewhere
👍 1
okay…here is what I did now: 1. restart all deployments and daemonset of neuvector 2. create a new pod: k run test --image=nicolaka/netshoot:v0.14 --command sleep 3600 3. move over to neuvector and switched the group nv.test.test to Network=Protect, Process=Discover 4. run a simple curl command: k exec -it test -- curl google.com 5. it should not succeed…but it does…
here is my NV config:
Copy code
controller:
  federation:
    mastersvc:
      type: LoadBalancer
      annotations:
        "<http://coredns.io/hostname|coredns.io/hostname>": "xxx"
  apisvc:
    type: ClusterIP
  internal:
    certificate:
      secret: neuvector-internal
  pvc:
    accessModes:
      - ReadWriteMany
    capacity: 5Gi
    enabled: true
    existingClaim: false
    storageClass: longhorn
  replicas: 1
crdwebhook:
  enabled: false
cve:
  scanner:
    internal:
      certificate:
        secret: neuvector-internal
enforcer:
  internal:
    certificate:
      secret: neuvector-internal
internal:
  autoGenerateCert: true
  autoRotateCert: true
  certmanager:
    enabled: true
    secretname: neuvector-internal

manager:
  ingress:
    annotations: {}
    enabled: true
    host: xxx
    ingressClassName: haproxy
    path: /
    tls: true
    secretName: ""
  env:
    ssl: false
q
why shouldn't it work? We'd like to see the network rules, please.
a
here is the export of the group that should have everything in it no?
since it has no allow rules it should block any network connections no?
q
i'm trying to replicate....
1. I just deployed that app 2. shelled into the container 3. tested
curl
(it worked) 4. put group into Protect mode 5. deleted the Network rule allowing the group to
external
6. retried the
curl
command, and it's failing as expected.
¯\_(ツ)_/¯
a
funny thing is I do NOT have that policy which connects the group to external… well…
time to create an Issue in GH i suppose while doing some more troubleshooting super weird but thank you Jorn for trying to help me out^^ if I find a solution im gonna let you know haha 😅
q
yeah i think there's something I'm not getting about what you are seeing on your screen. 😄
you can see that the second time i tried it just gagged
a
ye thats what I want to see too 😄 but I don’t :C again, thank you! I will keep you updated when we have a solution! 💪
q
I found and deleted that last rule
a
one last thing thats coming to my mind…it won’t be an issue having neuvector deployed on a k3s cluster using cilium with proxy and iptable replacement no?
oh… IPv6 is not supported im running dual-stack…hm that might be a clue
yep…issue found haha
Copy code
k exec -it test -- curl -4 <http://google.com|google.com> --max-time 5
curl: (28) Connection timed out after 5002 milliseconds
command terminated with exit code 28
is there a reason why IPv6 is not supported? Is it being worked on or not of interest do you know anything Jorn?
q
IPv6 is "a lot of work"
I'm quoting. 😉
😄 1
a
gotcha 😄 well at least the mystery has been solved no ipv6 or dual-stack allowed then 👍 gotit^^
q
It's a feature request that's kind of stalled. But input from users like you helps nudge it along
yeah that was it the whole time! <sad trombone>
Working As Designed™ 🙃
😁 1
a
haha yeah guess RTFM does exist for a reason^^ time to get some sleep back, that kept me awake for too long now thanks again for trying to solve the issue! ❤️
q
We both died. We're dead. 🤣
😂 1