Forbid traffic forwarding between device network ports #3837
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
milan-zededa
force-pushed
the
deny-forward
branch
from
4a05593
to
8f0bd35
Compare
It should not be possible to take advantage of EVE device and use it as a router to hop from one network to another. However, with out current iptables rules, EVE inadvertently allows icmp as well as tcp traffic on ports 22 (ssh), 4822 (Guacamole) and 5900-5999 (VNC) to get forwarded from one port to another. These are the protocols that we allow to be initiated from outside and enter EVE (if enabled by configuration), but we do not check if the traffic is locally destined or if it will continue out through another port. This is obviously a security issue. Luckily, it is not so easily exploitable - for an attacker to establish connection with an endpoint in another network, the routing in the other network must be configured such that the EVE device is used as the gateway (at least for the attacker's IP). Otherwise, the returning traffic will not take the same path and most likely will not reach the attacker. The solution in this commit is to first ensure that application traffic is always marked with app IDs (including for implicit ACL rules). Then, we can take advantage of the fact that only application traffic (non-zero app ID) should be allowed to be forwarded. Everything else that hits the FORWARD chain should be dropped. Signed-off-by: Milan Lenco <milan@zededa.com>
milan-zededa
force-pushed
the
deny-forward
branch
from
8f0bd35
to
7ebd749
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3837 +/- ##
=======================================
Coverage 17.51% 17.51%
=======================================
Files 3 3
Lines 805 805
=======================================
Hits 141 141
Misses 629 629
Partials 35 35 ☔ View full report in Codecov by Sentry. |
rouming
approved these changes
Apr 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It should not be possible to take advantage of EVE device and use it as a router to hop from one network to another.
However, with out current iptables rules, EVE inadvertently allows icmp as well as tcp traffic on ports 22 (ssh), 4822 (Guacamole) and 5900-5999 (VNC) to get forwarded from one port to another. These are the protocols that we allow to be initiated from outside and enter EVE (if enabled by configuration), but we do not check if the traffic is locally destined or if it will continue out through another port.
This is obviously a security issue. Luckily, it is not so easily exploitable - for an attacker to establish connection with an endpoint in another network, the routing in the other network must be configured such that the EVE device is used as the gateway (at least for the attacker's IP). Otherwise, the returning traffic will not take the same path and most likely will not reach the attacker.
The solution in this commit is to first ensure that application traffic is always marked with app IDs (including for implicit ACL rules). Then, we can take advantage of the fact that only application traffic (non-zero app ID mark) should be allowed to be forwarded. Everything else that hits the FORWARD chain should be dropped.