Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[caclmgrd] Fix subnet mask recognizing for drop ip2me rules #7178

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

ghost
Copy link

@ghost ghost commented Mar 29, 2021

Why I did it

Resolves #7008
As described in #7008, currently, caclmgrd applies drop rules for network interfaces with ip_ntwrk.max_prefixlen, instead of real subnet mask prefix, what makes the rules are not valid. The changes make possible to apply iptables rules with a real subnet mask prefix.
As the changes makes the device inaccessible via SSH, SNMP and makes impossible to use NTP on MGMT interface due to result of execution of function generate_block_ip2me_traffic_iptables_commands, new function generate_commands_for_mgmt_intf has implemented to add missing iptables rules for SSH, SNMP and NTP to the system.
As ACL_SERVICES is currently used for generating rules for MGMT interface, it has renamed to stay clear in its purpose.

How I did it

By recognizing and setting a real prefix of subnet mask, instead of ip_ntwrk.max_prefixlen.
To stay possible to use SNMP, SSH and NTP on MGMT interface, new function generate_commands_for_mgmt_intf has added to caclmgrd. It adds the required rules and drops all the traffic, which has no related rules.

How to verify it

Boot the switch and try to connect to it via SSH. SSH should work normal, as same as SNMP and NTP, if configured.
See the logs with show logging | grep caclmgrd. All the applied rules will be listed after Issuing the following iptables commands:. All the rules should have its own subnet mask prefixes, not ip_ntwrk.max_prefixlen.

Example:

Apr 29 19:06:47.341051 sonic INFO caclmgrd[2475]:   iptables -A INPUT -d 10.0.0.28/31 -j DROP
Apr 29 19:06:47.343867 sonic INFO caclmgrd[2475]:   iptables -A INPUT -d 10.0.0.30/31 -j DROP
Apr 29 19:06:47.345009 sonic INFO caclmgrd[2475]:   iptables -A INPUT -d 10.0.0.22/31 -j DROP
Apr 29 19:06:47.346226 sonic INFO caclmgrd[2475]:   iptables -A INPUT -d 10.0.0.26/31 -j DROP
Apr 29 19:06:47.347987 sonic INFO caclmgrd[2475]:   iptables -A INPUT -d 10.0.0.34/31 -j DROP
Apr 29 19:06:47.349138 sonic INFO caclmgrd[2475]:   iptables -A INPUT -d 10.0.0.10/31 -j DROP
Apr 29 19:06:47.353227 sonic INFO caclmgrd[2475]:   iptables -A INPUT -p udp -d 192.168.111.0/24 --dport 123 -j ACCEPT
Apr 29 19:06:47.354688 sonic INFO caclmgrd[2475]:   iptables -A INPUT -p tcp -d 192.168.111.0/24 --dport 161 -j ACCEPT
Apr 29 19:06:47.356006 sonic INFO caclmgrd[2475]:   iptables -A INPUT -p udp -d 192.168.111.0/24 --dport 161 -j ACCEPT
Apr 29 19:06:47.357527 sonic INFO caclmgrd[2475]:   iptables -A INPUT -p tcp -d 192.168.111.0/24 --dport 22 -j ACCEPT
Apr 29 19:06:47.358928 sonic INFO caclmgrd[2475]:   iptables -A INPUT -d 192.168.111.0/24 -j DROP
Apr 29 19:06:47.361097 sonic INFO caclmgrd[2475]:   iptables -A INPUT -m ttl --ttl-lt 2 -j ACCEPT
Apr 29 19:06:47.362360 sonic INFO caclmgrd[2475]:   ip6tables -A INPUT -p tcp -m hl --hl-lt 2 -j ACCEPT

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012

The fix is desirable, because it releases incoming traffic from useless data.

Description for the changelog

Fixed subnet mask prefixes for drop rules in caclmgrd. A missed rules for MGMT interface.

A picture of a cute animal (not mandatory but encouraged)

@ghost ghost marked this pull request as ready for review March 29, 2021 18:09
@ghost ghost requested a review from lguohan as a code owner March 29, 2021 18:09
@ghost
Copy link
Author

ghost commented Mar 30, 2021

retest this please

@ghost ghost force-pushed the fix_caclmgrd_mask branch from d50484d to 8ac07ed Compare April 12, 2021 09:51
@ghost ghost force-pushed the fix_caclmgrd_mask branch from 8ac07ed to 3c8d17d Compare April 20, 2021 07:08
d-dashkov and others added 3 commits October 18, 2021 14:48
* Implementing of recognizing of subnet masks for interfaces,
  found inside generate_block_ip2me_traffic_iptables_commands
  function. Using them for generating of iptables rules, instead
  of using of ip_ntwrk.max_prefixlen.

Signed-off-by: d-dashkov <Dmytro_Dashkov@Jabil.com>
Signed-off-by: Maksym Belei <Maksym_Belei@jabil.com>
* Adding acceptance rules for known ACL services on
  MGMT interface. This required, for example, for
  remote connecting to the device through MGMT interface.
* Droping all the rest incomming traffic on MGMT interface
  in the new function, instead of dropping it inside function
  generate_block_ip2me_traffic_iptables_commands.

Signed-off-by: Maksym Belei <Maksym_Belei@jabil.com>
* Renaming ACL_SERVICES to KNOWN_SYSTEM_SERVICES
  to stay consistant, because the service list
  is used for setting rules for MGMT interface,
  which is not related to ACL functionality.

Signed-off-by: Maksym Belei <Maksym_Belei@jabil.com>
@pshulik
Copy link

pshulik commented Oct 21, 2021

@lguohan, Could you please review the changes

@bluecmd
Copy link
Contributor

bluecmd commented Feb 3, 2022

I just found out this PR. I created a related / alternative fix: #9826. Hopefully either PR can be merged so this issue can be fixed.

bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Jan 31, 2023
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Mar 26, 2023
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Apr 16, 2023
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Apr 16, 2023
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Apr 23, 2023
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Apr 24, 2023
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Oct 31, 2023
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Feb 19, 2024
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
bluecmd added a commit to kamelnetworks/sonic-host-services that referenced this pull request Dec 23, 2024
Currently the first IP on the VLAN subnet is used, regardless of
whatever IP is actually assigned to the control plane. This fix uses the
correct IP.

See earlier work:
 - sonic-net/sonic-buildimage#9826
 - sonic-net/sonic-buildimage#7178
 - sonic-net/sonic-buildimage#7008

Signed-off-by: Christian Svensson <blue@cmd.nu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect iptable rules from caclmgrd
3 participants