从IPv6技术要求设想未来合规问题

  • A+
所属分类:云安全

IPv6全面部署已初有成效,同时安全相关问题也开始凸显,那么有关IPv6的安全合规将会是怎样的,我们不妨大胆去设想一下。本文会分别从政策层面、技术层面、网络安全层面进行讨论,主要出发点是企业合规设想,旨在给大家做一个参考。

随着各国网络发展战略的出台,IPv6 进入快速发展阶段。2017 年 11 月中国中共中央办公厅、国务院办公厅印发了《推进互联网协议第六版(IPv6)规模部署行动计划》,提出用五至十年时间,形成下一代互联网自主技术体系和产业生态,建成全球最大规模的 IPv6 商业应用网络,实现下一代互联网在经济社会各领域深度融合应用,成为全球下一代互联网发展的重要主导力量。

2020年3月,为贯彻落实《推进互联网协议第六版(IPv6)规模部署行动计划》(厅字〔2017〕47号)任务要求,加快提升IPv6端到端贯通能力,持续提升IPv6活跃用户和网络流量规模,工信部印发《2020年IPv6端到端贯通能力提升专项行动的通知(工信部通信函〔2020〕57号)》,决定于2020年开展IPv6端到端贯通能力提升专项行动。

从IPv6技术要求设想未来合规问题

图1 全球各国 IPv6 部署程度(来源:Cisco,2019.10)

我国目前(截止2020年5月)IPv6部署主要集中在中央、政府、大型企业,覆盖率约在80%左右,IPv6活跃用户约3.18亿人,占比35%。

从IPv6技术要求设想未来合规问题

图2 中国 IPv6 发展情况(来源:国家IPv6发展监测平台,2020.05)

在全球大力发展IPv6的同时,问题也开始逐渐显现,无论是监管部门还是政府、企事业单位,习惯了每年一次的等保和安全检查,但是在面对IPv6的合规性方面,目前可以说是一种不知所措的状态,尤其是企业方面。近期了解到,一些企业开始询问关于IPv6的合规都要关心哪些问题,监管会重点检查什么?

政策层面

由于IPv6还没有相关的政策法规、条例或国标,只有行业(如广电、通信)标准,且大多针对部署和连通性测试。本文将根据已有网络安全相关标准(国标、法规)和IPv6政策文件(行动计划、专项行动)进行分析,梳理其中对企业的要求。

首先应明确,该行动计划由党中央、国务院牵头开展,依据《国民经济和社会发展第十三个五年规划纲要》、《国家信息化发展战略纲要》、《“十三五”国家信息化规划》制定,其效力并不弱于《网安法》的要求,因此,政府、企事业单位应积极响应并推行。

《行动计划》有三个主要目标,五个重点工作(互联网应用、网络基础设施、应用基础设施、网络安全、关键前沿技术)。

三个主要目标

目标1

对2018年末IPv6改造的要求。

目标2

  • 到2020年末,新增网络地址不再使用IPv4;IPv6用户活跃数达到5亿,互联网用户中占比50%(目前3.2亿左右,占比35%);

  • 2020年底以下企业需全面支持IPv6(注:排名是指用户量排名):

  • 国内Top100商业网站及应用

  • 市地级以上政府外网网站,新闻及广播电视媒体网站系统(能力覆盖85%+)

  • 大型IDC(机架数量在3000-9999范围)

  • Top10 CDN(支持IPv6节点数达85%+)

  • Top10云平台100%的云产品

  • 广电网络,5G网络及业务,各类新增移动和固定终端

从IPv6技术要求设想未来合规问题图3中国云产品IPv6支持情况(来源:国家IPv6发展监测平台,2020.05)

目标3

到2025年末,我国IPv6网络规模(部署率目前第十位)、用户规模(目前第二位)、流量规模位居世界第一位,网络、应用、终端全面支持IPv6。

合规关注点

总结一下,从2020年5月的数据来看,目标2的完成时间可能会推迟。那么对于政府、企事业单位(下文统称为“组织”),结合《2020年IPv6端到端贯通能力提升专项行动的通知》中对完成指标的最新调整,需要关心的有几个方面:

  • 现有外网网站或系统在年底前,最起码要达到85%以上的IPv6支持率,在未来1-2年内达到100%(国内前100商业网站、地市级政府网站、广电、新闻站点是强制要求);

  • 国内前10的内容分发网络(CDN)年底85%以上节点要支持IPv6;(被点名企业:阿里云、腾讯云、网宿科技、蓝汛、金山云、百度云、华为云、京东云、帝联科技、UCloud、白山云、七牛云、鹏博士、中国移动)

  • 广电、运营商新上线系统及业务(包括移动端和固定终端)从设计到开发到上线,需基于IPv6协议,不可以再用IPv4。

  • 年底前门户网站二级、三级链接的IPv6浓度达到85%+;(涉及部门包括:各省(区、市)通信管理局、部属各单位、部属各高校、基础电信企业)

  • App、应用、客户端、浏览器、论坛等需进行IPv6升级,尤其排名前100的网站和应用,允许4/6双栈连接,但优先IPv6连接;

  • 年底前完成政务、综治、金融、医疗等领域公共管理、民生公益等服务平台改造,即100%支持IPv6;

  • 工业互联网IPv6改造工作启动,没有明确要求,但需要由改造计划和阶段性成果;

  • 从超大型IDC扩展到大型IDC,也就是说机架总数超过3000个的IDC,年底前要完成100%IPv6改造;(三大运营商改造范围扩展到中小IDC;被点名企业Q3末要完成年报中全部数据中心的IPv6改造,包括阿里云、腾讯云、百度云、京东云、华为云、世纪互联、鹏博士、秦淮科技、新网互联、方正信息、西部数码、万国数据、光环新网)

  • 国内排名前10的云服务商,年底前所有云上产品(包括:云主机、容器引擎、负载均衡、域名解析、对象存储、MySQL云数据库、MongoDB云数据库、API 网关、Web 应用防火墙、DDoS 高防、文件存储(NAS)、对等连接服务(VPC)、HTTPDNS、数据库审计、微服务引擎、MapReduce服务、设备接入服务(IoT Hub)、区块链服务、视频直播、人脸识别等)要100%支持IPv6(被点名企业:阿里云、天翼云、腾讯云、沃云、华为云、移动云、百度云、金山云、京东云、UCloud、青云);

  • 完善针对IPv6的网络安全定级备案、风险评估、通报预警、灾难备份及恢复等工作;即开始建立针对IPv6网络的安全评估和应急预案等文档体系。

技术合规

由于当前缺乏可参考的法规和标准,不能确定未来监管会重点检查哪些方面以及衡量指标。但是,鉴于国家对电信、广电行业的强制性要求,可以将该行业(包括地方文件)的实施指南类文档作为参考,大概预测一下IPv6技术合规方面需要企业关注的重点。

IPv6部署

  • 应制定IPv6升级改造的人员组织架构,明确责任人和各岗位职责分工;

  • 组织应提前制定IPv6部署计划,其中充分考虑对现有系统的IPv6演进路径及可能影响;

  • 组织应采取先试验,逐步小规模部署,在部署成熟后开始大范围推广,整个过程中应做好安全防护方案,包括割接方案及回滚方案;

  • 可以采取双栈部署方式,逐渐过渡到纯IPv6网络,根据业务情况,逐渐淘汰或升级IPv4系统和终端;

  • 组织核心网络设备(如防火墙、负载均衡、路由器、核心交换机等)应支持IPv6协议,从长远考虑来看,组织也可以考虑支持SRv6的设备;

  • 由于IPv6地址资源过于庞大,组织应合理规划地址段,细化安全域,避免后期由于地址太过分散,无法聚合,难以管理;

  • 升级后网络应能支持IPv6组播、IPv6的QosS及DHCPv6等协议;

  • 对于遗留系统,通过评估后再进行升级计划;

  • 针对公司业务主管及运维团队进行IPv6技术培训、割接培训,培养IPv6专业人才。

系统升级(以3A系统为例)

  • 组织的3A(或4A)系统应能够支持IPv6(包括业务支持、对外接口支持以及系统本身支持),主要是Radius报文中的属性字段(可参考RFC3162);

  • 业务上可以区分用户IP类型(v4、v6或双栈),支持IPv6属性,并授权相应的地址;

  • 对外与其他系统交互,应能识别用户类型字段(v4、v6或双栈),如计费系统,能够对不同类别用户的上网时长和流量提供独立记录;

  • 3A系统应能配置IPv6地址,能与其他设备进行IPv6交互;

  • 新采购设备或开发系统(业务),应支持IPv6,优先推荐IPv6-only项目。

网络安全合规

对于IPv6的部署和升级改造目前比较顺利,而且已经解决要求的目标,但随之而来的安全问题也开始显现。由于IPv6涉及的安全问题较多,下文中将主要针对国家重点关注的安全问题和最近几年出现的安全问题。

传统安全问题

尽管升级到IPv6网络,但是一些基于IPv4网络的安全问题依旧存在,组织还应继续予以关注并做好防护措施。

报文监听

IPv6中可使用IPSec对其网络层的数据传输进行加密保护,但RFC6434中不再强制要求实施IPSec,因此在未启用IPSec的情况下,对数据包进行监听依旧是可行的。

应用层攻击

IPv4网络中应用层可实施的攻击在IPv6网络下依然可行,比如SQL注入、缓冲溢出等,IDPS、病毒防护、URL过滤等应用层的防护不受网络层协议变化影响。

泛洪攻击

在IPv4与IPv6中,向目标主机发送大量网络流量依旧有效,泛洪攻击可能会造成严重的资源消耗或导致目标崩溃,DDoS防护依然关键。

分片攻击

在IPv4中,分片可以由发送主机和中间路由器执行,而IPv6分片只能由主机执行。这把IPv6路由器从昂贵的分组任务中解放了出来。

IPv6分片的一个重要方面是对分片的支持是通过IPv6扩展报头(特别是片报头)实现的。前规范的IPv6协议(即在[RFC8200]之前的协议允许一些非正常的分片情况,比如一个包的第一个分片不包含整个IPv6报头链(见[RFC7112])。这种非正常分片情况可能仍然遗留,被IPv6实施所允许,因此可能被用来规避IPv6安全控制。此外,由于分片支持是通过IPv6扩展报头实现的,所以扩展报头的所有通用安全考虑都适用于分片报头。

地址欺骗

IPv6使用NDP协议替代了IPv4中的ARP协议,但由于实现原理基本一致,因此针对ARP协议的ARP欺骗、ARP泛洪等类似攻击方式在IPv6中依旧可行。

网络架构

IPv4网络最常见的架构是内部节点使用私有IPv4地址,通过NAT设备连接到外部网络。作为转换IPv4地址和传输协议端口号的副作用,NAT设备最终强制执行“只允许传出通信”的过滤策略。

虽然这不是一种安全万能方法,但它确实在许多网络场景中减少了攻击面。由于IPv6网络不需要依赖于NAT设备,所以有时会假设IPv6节点造成更多的暴露面——也就是说,每个IPv6节点都可以从公共互联网直接访问。然而,这并不需要,通常也不应该出现这种情况。

例如,当前使用IPv4私有地址空间并通过NAT设备连接到Internet网络。可以通过在IPv4 NAT设备所在的网络拓扑的同一点部署有状态的IPv6防火墙来限制IPv6主机的暴露。IPv6防火墙通常配置为“只允许对外通信”,这样IPv6过滤策略就可以与IPv4相对应。此外,IPv6主机可以使用基于主机的IPv6防火墙,“只允许外部通信”,就像许多IPv4主机对IPv4流量所做的一样。

这种IPv6网络“架构”和包过滤策略是IETF推荐的用于IPv6互联网服务客户的家用默认设置之一。

IPv4网络中的IPv6问题

每当一台双堆栈主机要连接到另一台主机时,它通常会使用DNS来获取目标主机域名的IPv4和IPv6地址。随后,它将尝试与该主机通信,方法是按顺序尝试每个地址,或者并行尝试一些地址对。

通常,IPv4-only网络上的主机不会配置IPv6全局单播地址或IPv6默认路由,因此使用IPv6的通信尝试会失败,只有IPv4才有可能成功。

大多数现代操作系统都支持IPv6,并且在默认情况下不管IPv6是否已经部署到连接节点的网络上都会启用这种支持。这意味着即使缺少全球IPv6连接,其仍然存在于IPv4专用网络中。换句话说,大多数“IPv4专用网络”是由双栈节点组成的,当IPv6可用时,这些节点可以很容易地利用IPv6连接。

因此,攻击者连接到本地子网可能触发IPv6网络配置(例如,通过发送伪造的路由器通告消息),随后执行基于IPv6的攻击,如拒绝服务(DoS)、中间人(MITM)、触发VPN流量泄漏。

因此,即使是纯IPv4的网络,也应该实施IPv6安全控制。这些控制可以从减轻对自动配置和地址解析机制的攻击,到执行IPv6 ACL或在二层完全阻止IPv6流量。

国家关注的安全问题

目前大多数网络还是处于双栈阶段,那么所面临的问题除了以往IPv4网络相关的,还要考虑IPv6所带来的问题。

等保2.0要求仍适用于IPv6网络

IPv6网络中,对于安全的要求,目前还应参照等保2.0执行,对于新协议、新场景引入的问题,可根据实际情况执行防护策略。

IPv4/IPv6双栈网络

IPv6协议栈只是为上层协议提供了一个可选的网络层服务。因此,双栈服务器通常在两个Internet协议上提供相同的网络服务。网络服务对于底层Internet协议不可知。

从安全的角度来看,相同的安全策略在两者的Internet协议强制执行,攻击者可以利用阻碍较少的协议进行攻击:无论是渗透网络服务器,还是执行拒绝服务攻击主机或网络。

一种最简单且普遍的安全控制是通过某种形式的防火墙设备执行包过滤策略。在IPv6信息包过滤策略方面,传统上认为其是弱于IPv4的(可能由于经验有限的IPv6协议和/或支持IPv6的网络安全设备有限),两个协议间的过滤策略不匹配是很常见的,但没有明确的迹象表明哪种协议策略比另一种弱。

对于大多数网络场景,组织针对IPv6实施的安全策略应该与IPv4实施的安全策略相同。

隧道机制问题

隧道机制可实现 IPv6 数据包在 IPv4 网络中传输,其核心在于将IPv6 数据包封装在 IPv4 数据包中,以自动、手动等多种隧道配置方式,保障被 IPv4 网络隔离开的局部 IPv6 网络间相互通信。以 IPv6 to IPv4 和 IPv6 over IPv4 为例。

从IPv6技术要求设想未来合规问题

图4 隧道机制 (来源:信通院《IPv6网络安全白皮书》)

在隧道环境下,部分隧道机制仅要求隧道出入口节点对报文进行简单的封装和解封,缺乏内置认证、加密等安全功能,导致攻击者可能截取隧道报文,伪造用户地址并伪装成合法用户发起攻击。

翻译机制问题

由于IPv6的地址空间足够大,绝大多数IPv6网络将不会采用NAT。在网络使用提供商分配地址空间的情况下,ISP委派的网络前缀的任何更改都将导致整个网络的重新编号。

此外,如果网络中断影响了与上游网络提供商的连接,那么在一段较长时间内,网络可能会无法使用之前提供商委托/租用的所有前缀。如果地址空间多为此类地址,则可能导致内部网络通信中断。

ULAs[RFC4193]相当于IPv6下的IPv4私有地址[RFC1918]。ULA前缀不是由ISP分配或租用的,而是由本地网络管理员选择的,通常不会受到重新编号事件的影响——因此需要对DNS、ACL等进行较少的更新。此外,由于它们不是由ISP租用/委托,即使网络中断影响了与ISP的长期连接,仍然可以使用ULAs与内部节点通信。

对于不应该从外部网络访问的节点,ULA前缀可能特别有效,因为:

  • ULAs的“私有”特性提供了一个额外的隔离层(除了适当的包过滤之外),因为这些地址不太可能从外部网络被访问到

  • 它们可能会具有比上游提供商租用/委托前缀配置更稳定的地址

  • 即使在上游连接中断的情况下,它们也允许网络操作

在大多数场景中,ULAs将与全局单播地址一起配置,其中ULAs用于内部通信,而全局地址将用于与外部节点通信。

安全产品对IP的支持问题

现阶段 IPv6 相关安全产品的研发应用情况来看,目前市场对 IPv6 安全产品发展的驱动效应尚未全面显现,我国 IPv6 安全产品仍处于起步发展阶段。

图5 中国 Ready Logo 设备

从IPv6技术要求设想未来合规问题类型统计(来源:全球IPv6测试中心,2019.10)

新引入安全问题

IPv6包结构问题

IPv6采用固定长度的基础IPv6报头,可选的扩展报头形成一个菊花链包结构。希望哪个系统处理这些选项可以使用不同的选项容器,这样节点就不必解析它们无需处理的选项。然而,当需要处理整个IPv6报头链以访问上层协议值(如传输协议类型、传输协议端口号等)时,IPv6包结构往往与现代路由器体系结构不相匹配。

IPv6扩展报头存在很多安全隐患:

  • 一些安全设备在执行过滤策略时不能处理整个IPv6报头链( [RFC7113])。因此,即使只是简单地添加一个只携带“padding”选项的扩展头,也足以绕过相应的安全控制。

  • 一些网络或安全设备通常可能在硬件上处理流量,但在软件中处理携带选项的包。这种情况下,IPv6扩展头可能被用来执行DoS攻击。

  • 在许多IPv6实施中发现,无法对使用IPv6扩展报头的包执行基本完整性检查。在某些情况下,攻击者可能通过向受害节点发送单个或持续精心设计的数据包流来导致处理节点崩溃、重新启动或无响应。

为了减轻上述的安全影响,应该执行适当的包过滤策略。通常路由器应该更宽松的放行流量(使用列入黑名单的信息包过滤方法),而更接近网络的边缘节点(例如企业边界路由器)通常应该更保守,只允许他们预期想获得的流量(即采用白名单的信息包过滤方法)。

一些网络使用扩展报头来过滤数据包,这影响了IPv6扩展报头在公共互联网上使用的可靠性[RFC7872]。普遍使用的丢弃包含扩展报头的IPv6数据包也会影响IPsec扩展报头。这样做的后果是,为了使IPsec数据包在IPv6互联网上存活,可能需要通过一些传输协议(例如TCP或UDP)来隧道IPsec流量。对于某些用例,可以使用TLS VPN等替代技术。

海量地址“造福”攻击者

批量注册,批量薅羊毛,刷量,刷单,引流等需要操控大量的账号进行自动化攻击。在网络的攻防对抗中,动态切换IP来覆盖Web表单爆破,或者是利用工具进行MySQL,Redis,RDP等协议爆破,以及进行常见Web攻击,如SQL注入,0day/1day/Nday漏洞利用等。

从IPv6技术要求设想未来合规问题

图6 IPv4与IPv6地址资源

对于攻击者而言,他们会想尽一切办法,来不断降低攻击成本,提高攻击效率,自动化攻击便是其中的关键方法之一。对于防守方而言,他们会实施一系列防御方法,比如累积黑/白名单,创建情报库以及部署防御策略等,来提高攻击者的攻击成本,提高防守率。这实际上是资源的对抗,尤其是IP资源的对抗。企业应对秒拨IP技术引起重视,今早做好防护措施。

影子IT更难于管理

IPv6主机通常为每个网络接口配置不同范围和属性的多个地址。这与IPv4形成对比,在IPv4中,主机通常只为每个网络接口配置一个地址。随着地址数量的增加,每个地址都具有不同属性,这为提高安全性、保密性和弹性提供了能力。

然而,由于对可用地址的不当使用,这些潜在的优点通常无法实现。可能在某些场景中,这种对可用地址的不当使用将导致意外。

IPv6主机通常配置不同范围的多个地址,从链路本地到全局。一般来说,主机应该为每个应用程序使用尽可能小范围的地址。这种缩小的范围容易提供隔离,这层隔离是由地址范围本身所产生的(如Vlan)。

例如,一个只能从网络内部访问的文件服务器可能只想使用ULAs——IPv6中相当于IPv4私有地址。通过使用ULAs,有限地址范围本身可以作为与互联网隔离的一种手段。使用有限范围的地址并不排除或阻止使用其他网络防护手段,而是作为一个额外的防护。

使用有限范围的IPv6地址能带来额外的好处。例如,ULA地址块(fc00::/7)足够大,几乎任何大型或复杂网络都可以从ULA地址空间中构建。由于ULAs是本地管理,因此即使上游提供程序出现故障,它们也可以提供可用的地址;也就是说,即使与上游提供程序的连接丢失,且全局地址超,仍然可以使用ULAs进行本地通信。

IoT设备问题

当谈到IPv6和物联网,许多人认为IPv6是物联网释放其全部潜力的必要条件。然而,分析IPv6——特别是全局寻址和any to any连接——在何种程度上与物联网想结合是很重要。

无论使用或不使用全局地址空间,是否需要any to any连接(包括主动入站通信),以及它对物联网设备安全性的影响才是问题的关键。在IPv4中,未经请求的入站通信由于使用NAT会被阻断。随着NAT和网络过滤策略(可能)在IPv6中的消失,全局any to any通信可以提高灵活性——同时以增加攻击风险作为代价。

是否对IPv6和物联网设备实施同样的过滤策略将取决于相关设备的通信模型;是否期望外部实体轮询物联网设备,或是否期望物联网设备通知外部实体。如果是前者,物联网网络将需要接受入站、未经请求的通信。若是后者,传入的通信可能会被阻断,而物联网设备将能够根据需要来连接外部系统。

除了可能的物联网设备通信模式,当从外部网络向物联网网络通信是可行的,这种通信应该直接访问物联网设备,还是应该通过作为物联网和外部网络之间的网关代理来执行?显然,网关方式在安全方面可能会更好,而且在监管脆弱的物联网设备流量方面也可能处于有利地位。

物联网网关具有设备连接、协议转换、数据过滤和处理、安全、更新、管理等重要功能。物联网网关也可以作为应用程序代码平台,处理数据并成为支持边缘系统的智能部分。

IPv6协议漏洞

有关IPv6的安全漏洞在逐渐被爆出,虽然可被利用的漏洞数量还不算多,但组织应该密切关注。截止今年6月,CVE官方统计IPv6漏洞数量以超过400个。企业以后的漏洞扫描工具应支持IPv6漏洞和资产发现功能。

从IPv6技术要求设想未来合规问题

图7 IPv6漏洞情况(来源:CVE,2020.06)

官方建议

“好用”已经成为当前IPv6规模部署工作重点(其实,目前大多数企业的要求是“能有”,还没到“好用”)。“好用”不仅是简单的用IPv6替代IPv4,更要发挥基于IPv6+的下一代互联网创新优势实现业务创新和产业赋能。IPv6+提出的SRv6、VPN+、APN等关键技术,为简化网络结构、优化用户体验和提升网络智能化奠定了良好的基础,与5G、云网融合、工业互联网、车联网等应用对网络承载需求不谋而合,为进一步开展网络和业务创新提供了广阔的空间。因此,加强基于IPv6+的下一代互联网技术创新,发展增强型“IPv6+”网络提升网络能力,从而驱动网络和业务融合创新,是下一步IPv6发展的必然方向。

自两办发布《行动计划》伊始,加强IPv6创新是贯穿整个IPv6规模部署的重点工作。2019年底,中央网信办、工信部等有关部门指导“IPv6规模部署专家委员会”成立了“IPv6+技术创新工作组”,工作组依托我国IPv6规模部署成果,整合IPv6相关产业链力量,从网络路由协议、管理自动化、智能化及安全等方向,积极开展创新研究、标准制定、测试验证和应用示范,针对下一代互联网技术的代际演进开展系列创新,促进提升我国在下一代互联网领域的国际竞争力。

《专项行动》提出了四项保障措施。企业层面,要做到“落实举措、责任主体、完成时限”三个明确,将IPv6相关任务完成情况作为年度考核重要指标,同时配合工信部做好各项部署监测工作。工信部组织有关方面,除了做好持续完善IPv6发展监测平台、开展IPv6改造各环节监测、加强对重点企业的督导等日常工作外,将组织成立IPv6网络改造攻坚专项协同推进工作组,重点针对CDN、云服务、网络质量等IPv6改造关键环节,从基础电信企业、主要互联网企业、研究机构、行业联盟等单位抽调技术骨干,集中优势力量攻坚克难,着力完成IPv6规模部署第二阶段重点任务。

从IPv6技术要求设想未来合规问题

精彩推荐





从IPv6技术要求设想未来合规问题
从IPv6技术要求设想未来合规问题从IPv6技术要求设想未来合规问题

从IPv6技术要求设想未来合规问题从IPv6技术要求设想未来合规问题

从IPv6技术要求设想未来合规问题

从IPv6技术要求设想未来合规问题

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: