ingress filtering что это
ingress and egress filtering
Смотреть что такое «ingress and egress filtering» в других словарях:
Egress filtering — In computer networking, egress filtering is a method of filtering electronic traffic that contributes to the security of a network and therefore makes it less prone to attacks from crackers.This method of filtering prevents crackers from using a… … Wikipedia
Ingress filtering — In computer networking, ingress filtering is a technique used to make sure that incoming packets are actually from the networks that they claim to be from. Contents 1 Problem 2 Solution 3 Networks 4 See also … Wikipedia
Ingress — may refer to:*The act of entering. Antonym of egress. *A type of noise typically encountered when using coaxial cable *Ingress Bell (1834 1913), an English architect *Ingress filtering, a computer network packet filtering technique *Ingress… … Wikipedia
входная и выходная фильтрация — Метод защиты от хакерских атак путем фильтрации фальшивых IP адресов на входе и выходе узла сети. [http://www.morepc.ru/dict/] Тематики информационные технологии в целом EN ingress and egress filtering … Справочник технического переводчика
IP traceback — is a name given to any method for reliably determining the origin of a packet on the Internet. The datagram nature of the Internet makes it difficult to determine the originating host of a packet – the source id supplied in an IP packet can be… … Wikipedia
Synchronous optical networking — (SONET) and Synchronous Digital Hierarchy (SDH), are two closely related multiplexing protocols for transferring multiple digital bit streams using lasers or light emitting diodes (LEDs) over the same optical fiber. The method was developed to… … Wikipedia
IP address spoofing — In computer networking, the term IP (Internet Protocol) address spoofing refers to the creation of IP packets with a forged (spoofed) source IP address with the purpose of concealing the identity of the sender or impersonating another computing… … Wikipedia
Comparison of firewalls — The following tables compare different aspects of a number of firewalls, starting from simple home firewalls up to the most sophisticated Enterprise firewalls. Contents 1 Firewall software 2 Firewall rule set basic filtering features comparison 3 … Wikipedia
Network Monitoring Interface Card — A network monitoring interface card or NMIC is similar to a network card (NIC). However, unlike a standard network card, an NMIC is designed to passively (and silently) listen on a network. At a functional level, an NMIC may differ from a NIC, in … Wikipedia
Radio transmitter design — In plate modulation systems the voltage delivered to the stage is changed. As the power output available is a function of the supply voltage, the output power is modulated. This can be done using a transformer to alter the anode (plate) voltage.… … Wikipedia
Network calculus — is a theoretical framework for analysing performance guarantees in computer networks. As traffic flows through a network it is subject to constraints imposed by the system components, for example: link capacity traffic shapers (leaky buckets)… … Wikipedia
Побег из Vlan. Баг? Хак?! Фича… Или о пользе чтения документации
Доброго времени суток, коллеги.
Снова рискую огрести минусов за капитанство, но все же считаю нижеприведенную инфу полезной. В конце-концов капитанство — не самая низшая ступень. Что бы говорить трюизмы, надо их как минимум знать. И если в быту и в рамках банальной эрудиции это может любой за исключением детей сильно-младшего дошкольного возраста (за летом придет осень), то в сфере профессиональной до этого еще надо дорасти. Так что гуру под кат могут не смотреть. Ну если только повеселиться, это можно…
В ядре (catalyst 35xx)
sh mac address-table | i xxxx.xxxx.xxxx
Но странное дело, mac светится сразу в нескольких Vlan плюсом к тому, в котором как бы должен. Да, на девайсе они действительно подняты (tagged), но порт на свиче доступа (AT-85xx) настроен как untagged. И как tagged он ни в один Vlan не входит. Автор интуитивно (и очень зря, мануалы надо читать!) ожидал от такого «чистого» untagged порта поведения, аналогичного в cisco, когда
switchport mode access
switchport access vlan xxx
Но, как я уже заметил — зря. Дальнейшие изыскания с тестовой машинкой показали, что тэгированный трафик на untagged порт спокойно принимается (при наличии соотв. Vlan-а на свиче, ессно) и форвардится (назад ессно нет).
Занеся на тестовой машине в arp-таблицу статическую запись для некоего IP из управляющего Vlan и подняв его на сетевой как tagged спокойно удалось нафлудить туда чем-то бОльшим, чем arp-запросами. Это плохо.
Ситуацию прояснил мануал. Оказывается, это совершенно нормальное поведение свича, которое может быть отключено командой
set switch infiltering=yes
Правда, в мануале было написано (если я не попутал), что по дефолту команда эта есть и наблюдаемое на практике поведение должно быть отключено. Но не суть. Кстати, через веб-гуи команда недоступна (вот она, причина невежества).
И как оказалось, реальная дефолтовая настройка свича более соответсвует стандарту 802.1Q, чем информация о дефолтовом значении параметра из мануала.
Виртуальные локальные сети (VLAN)
Port VLAN ID
Продвижение кадров VLAN IEEE 802.1Q
Решение о продвижении кадра внутри виртуальной локальной сети принимается на основе трех следующих видов правил.
Классификация кадра по принадлежности VLAN осуществляется следующим образом:
Активизировав функцию проверки формата кадра на входе, администратор сети может указать, кадры каких форматов будут приниматься коммутатором для дальнейшей обработки. Управляемые коммутаторы D-Link позволяют настраивать прием портами либо только маркированных кадров (tagged_only), либо обоих типов кадров — маркированных и немаркированных (admitall).
Правила продвижения между портами осуществляют принятие решения об отбрасывании или передаче кадра на порт назначения на основе его информации о принадлежности конкретной VLAN и МАС-адреса узла-приемника.
Если кадр немаркированный, входная фильтрация не выполняется.
Правила исходящего трафика определяют формат исходящего кадра — маркированный или немаркированный. Если выходной порт является немаркированным (untagged), то он будет извлекать тег 802.1Q из заголовков всех выходящих через него маркированных кадров. Если выходной порт настроен как маркированный (tagged), то он будет сохранять тег 802.1Q в заголовках всех выходящих через него маркированных кадров.
Manual:Bridge VLAN Table
Applies to RouterOS: 6.41+
Contents
Summary
Since RouterOS v6.41 it is possible to use a bridge to filter out VLANs in your network. To achieve this, you should use the Bridge VLAN Filtering feature. This feature should be used instead of many known bad VLAN configurations that are most likely causing you either performance issues or connectivity issues, you can read about one of the most popular misconfiguration in the VLAN in a bridge with a physical interface section. The most important part of the bridge VLAN filtering feature is the bridge VLAN table, which specifies which VLANs are allowed on each port, but configuring it might get quite complex if you are trying to make more advanced setup, for generic setups you should be able to configure your device using the Trunk and Access ports example, but the purpose of this guide is to provide in-depth explanation and point out some of behavior characteristics when using bridge VLAN Filtering.
Background
Before explaining bridge VLAN filtering in-depth, you should understand a few basic concepts that are involved in bridge VLAN filtering.
Trunk/Access port setup
Below you can find a very common diagram for a very typical type of setup that consists of a trunk port and multiple access ports:
This setup is very common since it gives the possibility to divide your network into multiple segments while using a single switch and maybe a single router, such a requirement is very common for companies that want to separate multiple departments. With VLANs you can use different DHCP Servers, which can give out an IP address from a different subnet based on the VLAN ID, which makes creating Firewall rules and QoS a lot easier.
In such a setup you would connect some very generic devices like Desktop PCs to ether2 and ether3, these can be considered as workstations and they generally only use untagged traffic (it is possible to force a VLAN tag for all traffic that is sent out a generic workstation, though it is not very common). To isolate some workstations from other workstations you must add a VLAN tag to all packets that enters ether2 or ether3, but to decide what VLAN ID should the packet get is to use a concept called Port based VLANs. In this concept packets get a VLAN tag with a VLAN ID based on the bridge port to which the device is connected. For example, in this setup the device on ether2 will get a VLAN tag with VLAN20 and the device on ether3 will get a VLAN tag with VLAN30, this concept is very scalable as long as you have enough bridge ports. This should give you the understanding that traffic between the bridge and devices behind ether2/ether3 is untagged (since there is no VLAN tag, hence the name).
When we have determined our untagged ports, we can now determine our tagged ports. Tagged ports are going to be the trunk ports (the port, that carries multiple VLANs) and usually this port is connected to a router or another switch/bridge, you can have multiple trunk ports as well. Tagged ports are always carrying packets with a VLAN tag (hence the name) and you must ALWAYS specify the tagged ports for each VLAN ID you want this port to forward. It is possible that a port is a tagged port for one VLAN ID and the same port is an untagged port for a different VLAN ID, but this is for a different type of setup (Hybrid port setup).
To configure the trunk/access port setup, you need to first create a bridge:
Warning: Don’t enable VLAN filtering yet as you might get locked out from the device because of the lack of the management access, which is configured at the end.
Add the bridge ports and specify PVID for each access port:
Note: PVID has no effect until VLAN filtering is enabled.
Add appropriate entries in the bridge VLAN table:
You might think that you could simplify this entry with a single entry, similar to this:
Do NOT use multiple VLAN IDs on access ports. This will unintentionally allow both VLAN20 and VLAN30 on both access ports. In the example above, ether3 is supposed to set a VLAN tag for all ingress packets to use VLAN30 (since PVID=30 ), but this does not limit the allowed VLANs on this port when VLANs are being sent out through this port. The bridge VLAN table is responsible for deciding whether a VLAN is allowed to be sent through a specific port or not. The entry above specifies that both VLAN20 and VLAN30 is allowed to be sent out through ether2 and ether3 and on top of that the entry specifies that packets should be sent out without a VLAN tag (packets are sent out as untagged packets). As a result you may create a packet leak from VLANs to ports that are not even supposed to receive such traffic, see the image below.
Warning: Don’t use more than one VLAN ID specified in a bridge VLAN table entry for access ports, you should only specify multiple VLAN IDs for trunk ports.
It is not necessary to add a bridge port as an untagged port, because each bridge port is added as an untagged port dynamically with a VLAN ID that is specified in the PVID property. This is because of a feature that automatically will add an appropriate entry in the bridge VLAN table for convenience and performance reasons, this feature does have some caveats that you must be aware of. All ports that have the same PVID will be added to a single entry for the appropriate VLAN ID as untagged ports, but note that the CPU port also has a VLAN ID.
For testing purposes we are going to enable VLAN filtering, but note that it might make you lose access to the device since it does not have a management access configured yet (we will configure it later). It is always recommended to configure VLAN filtering while using a serial console, though you can also configure a device through a port, that is not added to a bridge. Make sure you are using a serial console or connected through a different port (that is not in a bridge) and enable VLAN filtering:
Note: You might not lose access to the device as soon as you enable VLAN filtering, but you might get disconnected since the bridge must reset itself in order for VLAN filtering to take any effect, which will force you to reconnect (this is mostly relevant when using MAC-telnet). There is a chance you might be able to access your device using untagged traffic, this scenario is described below.
If you have enabled VLAN filtering now and printed out the current VLAN table, you would see such a table:
There is a dynamic entry added for VLAN1 since PVID=1 is set by default to all bridge ports (including our trunk port, ether1), but you should also notice that bridge1 interface (the CPU port) is also added dynamically. When ports are added to a single bridge VLAN table entry, the bridge can skip adding a VLAN tag and removing it when packets is being forwarded between these ports (since changing packets is not necessary and decreases the throughput), for this reason all ports with the same PVID are added as untagged ports dynamically.
You should be aware that the CPU port (bridge1) is also a bridge port and therefore might get added to the bridge VLAN table dynamically. There is a chance that you might unintentionally allow access to the device because of this feature. For example, if you have followed this guide and left PVID=1 set for the trunk port (ether1) and did not change the PVID for the CPU port (bridge1) as well, then access through ether1 to the device using untagged traffic is allowed, this is also visible when you print out the bridge VLAN table. This scenario is illustrated in the image below:
Warning: Always check the bridge VLAN table if you have not unintentionally allowed certain VLANs or untagged traffic to specific ports, especially the CPU port (bridge).
There is a simple way to prevent the bridge (CPU port) being added as an untagged port, you can simply set the PVID on the trunk port to be different than the bridge’s PVID (or change the bridge’s PVID ), but there is another option, which is more intuitive and recommended. Since you are expecting that the trunk port is only supposed to receive tagged traffic (in this example, it should only receive VLAN20/VLAN30), but no untagged traffic, then you can use ingress-filtering along with frame-type to filter out unwanted packets, but in order to fully understand the behavior of ingress filtering, we must first understand the details of management access.
Note: You can use the feature that dynamically adds untagged ports with the same PVID value, you can simply change the PVID to match between ether3 and bridge1.
Allowing access to the device using untagged traffic is not considered as a good security practice, a much better way is to allow access to the device using a very specific VLAN sometimes called the management VLAN, in our case this is going to be VLAN99. This adds a significant layer of security since an attacker must guess the VLAN ID that is being used for management purposes and then guess the login credentials, on top of this you can even add another layer of security by allowing access to the device using only a certain IP addresses. The purpose of this guide is to provide in-depth explanation, for that reason we are adding a level of complexity to our setup to understand some possible caveats that you must take into account. We are going to allow access from an access port using tagged traffic (illustrated in the image below). In order to allow access to the device using VLAN99 from ether3, we must add a proper entry in the bridge VLAN table:
Note: If PVID for ether1 and bridge1 matches (by default, it does matches with 1), then access to the device is allowed using untagged traffic from ether1 because of the feature that dynamically adds untagged ports to the bridge VLAN table.
But you might notice that access using VLAN99 does not work at this point, this is because you need a VLAN interface that listens for tagged traffic, you can simply create this interface for the appropriate VLAN ID and you can set an IP address for the interface as well:
Note: Our access port (ether3) at this point expects tagged and untagged traffic at the same time, such a port is called a hybrid port.
Lets say that you forgot to enable ingress-filtering and change the frame-type property on ether1, this would unintentionally add access to the device through ether1 using untagged traffic since PVID matches for bridge1 and ether1, but you are expecting only tagged traffic to be able to access the device. It is possible to drop all untagged packets that are destined to the CPU port:
This does not only drop untagged packets, but this disables the feature that dynamically adds untagged ports to the bridge VLAN table. If you print out the current bridge VLAN table you would notice that bridge1 is not dynamically added as an untagged port:
Warning: Always try to use ingress-filtering wherever it is possible, it adds a significant layer of security.
The ingress-filtering can be used on the CPU port (bridge) as well, this can be used to prevent some possible attack vectors and limit the allowed VLANs that can access the CPU. It is better to drop a packet on an ingress port, rather than on an egress port, this reduces the CPU load, this is quite crucial when you are using hardware offloading with bridge VLAN filtering.
Note: The ingress-filtering property only has effect on ingress traffic, but frame-type has effect on egress and ingress traffic.
Even though you can limit the allowed VLANs and packet types on a port, it is never a good security practice to allow access to a device through access ports since an attacker could sniff packets and extract the management VLAN’s ID, you should only allow access to the device from the trunk port (ether1) since trunk ports usually have better physical security, you should remove the previous entry and allow access to the device through the port that is connected to your router (illustrated in the image below):
VLAN Tunnelling setup
In some cases you might want to forward already tagged traffic through certain switches. This is a quite common setup for backbone infrastructures since it provides a possibility encapsulate traffic from, for example, your edge routers and seamlessly forward it over your backbone to another edge router. Below you can find an example of a VLAN tunnelling topology:
Note: To fully understand how to configure VLAN tunnelling properly, you should first read the Trunk/Access port setup section before proceeding any further.
Note: The bridge checks only the outer tag (closest to the MAC address), any other tag is ignored anywhere in bridge configuration. The bridge is not aware of the packet contents, even though there might be another VLAN tag, only the first VLAN tag is checked.
The ether-type property allows you to select the following EtherTypes for the VLAN tag:
In order to properly configure bridge VLAN filtering, you must understand how does the bridge distinguish tagged and untagged packets. Like mentioned before, the bridge will check if EtherType matches with the outer VLAN tag in the packet. For example, consider the following packet:
Both SW1 and SW2 are using the same configuration:
In this example traffic between SW1 and SW2 is going to be tagged and it will be using the SVID VLAN tag. Here we are assuming that all routers are passing traffic that is using a CVID VLAN tag and such traffic will be considered as untagged traffic based on the principle described above.
Note: All principles that applies to the regular trunk/access port setup using IEEE 802.1Q, they also apply to VLAN tunnelling setups, make sure you are limiting VLANs and packet type properly using the bridge VLAN table and ingress filtering.
In case you want to create management access from, lets say, ether3 to the device and wanted to use VLAN99, then you would use such commands:
Tag Stacking
In the VLAN Tunnelling setup we were adding a new VLAN tag that was different from the VLAN tag, but it is possible to add a new VLAN tag regardless of the packet contents. The difference between the regular VLAN tunnelling setup is that the bridge does not check if the packet is tagged or untagged, it assumes that all packets that are received on a specific port are all untagged packets and will add a new VLAN tag regardless whether a VLAN tag is present or not, this is called Tag Stacking since it «stacks» VLAN tags on top of the previous tag, regardless of the VLAN tag type. This is a very common setup for networks that do not support the IEEE 802.1ad standard, but still want to encapsulate VLAN traffic into a new VLAN.
To explain how VLAN tagging and untagging works with tag stacking, lets use the same network topology as before:
What we want to achieve is that regardless what is being received on ether2 and ether3, a new VLAN tag will be added to encapsulate the traffic that is coming from those ports. What tag-stacking does is forces a new VLAN tag, so we can use this property to achieve our desired setup. We are going to be using the same configuration as in the Trunk/Access port setup, but with tag stacking enabled on the access ports:
Lets assume that the devices behind ether2 and ether3 are sending tagged VLAN40 traffic. With this configuration ALL packets will get encapsulated with a new VLAN tag, but you must make sure that you have added the VLAN ID from the outer tag to the bridge VLAN table. The VLAN40 is not added to the bridge VLAN table since it is the inner tag and it is not checked, we are only concerned about the outer tag, which is either VLAN20 or VLAN30 depending on the port.
Similarly to other setups, the bridge VLAN table is going to be used to determine if the VLAN tag needs to be removed or not. For example, ether1 receives tagged VLAN20 packets, the bridge checks that ether2 is allowed to carry VLAN20 so it is about to send it out through ether2, but it also checks the bridge VLAN table whether the VLAN tag should be removed and since ether2 is marked as an untagged port, then the bridge will forward these packets from ether1 to ether2 without the VLAN20 VLAN tag.
Ingress Filtering¶
Ingress filtering refers to the concept of firewalling traffic entering a network from an external source such as the Internet. In deployments with multi-WAN, the firewall has multiple ingress points. The default ingress policy on pfSenseВ® software is to block all traffic as there are no allow rules on WAN in the default ruleset. Replies to traffic initiated from inside the local network are automatically allowed to return through the firewall by the state table.
Egress Filtering¶
Egress filtering refers to the concept of firewalling traffic initiated inside the local network, destined for a remote network such as the Internet. pfSense, like nearly all similar commercial and open source solutions, comes with a LAN rule allowing everything from the LAN out to the Internet. This isn’t the best way to operate, however. It has become the de facto default in most firewall solutions because it is what most people expect. The common misperception is “Anything on the internal network is вЂtrustworthy’, so why bother filtering”?
Why employ egress filtering?В¶
From our experience in working with countless firewalls from numerous vendors across many different organizations, most small companies and home networks do not employ egress filtering. It can increase the administrative burden as each new application or service may require opening additional ports or protocols in the firewall. In some environments it is difficult because the administrators do not completely know what is happening on the network, and they are hesitant to break things. In other environments it is impossible for reasons of workplace politics. The best practice is for administrators to configure the firewall to allow only the minimum required traffic to leave a network where possible. Tight egress filtering is important for several reasons:
Limit the Impact of a Compromised System¶
Egress filtering limits the impact of a compromised system. Malware commonly uses ports and protocols that are not required on most business networks. Some bots rely on IRC connections to phone home and receive instructions. Some will use more common ports such as TCP port 80 (normally HTTP) to evade egress filtering, but many do not. If access to TCP port 6667, the usual IRC port, is not permitted by the firewall, bots that rely on IRC to function may be crippled by the filtering.
Another example is a case we were involved in where the inside interface of a pfSense installation was seeing 50-60 Mbps of traffic while the WAN had less than 1 Mbps of throughput. There were no other interfaces on the firewall. Some investigation showed the cause as a compromised system on the LAN running a bot participating in a distributed denial of service (DDoS) attack against a Chinese gambling web site. The attack used UDP port 80, and in this network UDP port 80 was not permitted by the egress ruleset so all the DDoS was accomplishing was stressing the inside interface of the firewall with traffic that was being dropped. In this situation, the firewall was happily chugging along with no performance degradation and the network’s administrator did not know it was happening until it was discovered by accident.
The attack described in the above paragraph likely used UDP port 80 for two main reasons:
UDP allows large packets to be sent by the client without completing a TCP handshake. With stateful firewalls being the norm, large TCP packets will not pass until the handshake is successfully completed, and this limits the effectiveness of the DDoS.
Those who do employ egress filtering are commonly too permissive, allowing TCP and UDP where only TCP is required, as in the case of HTTP.
These types of attacks are commonly launched from compromised web servers. With a wide open egress ruleset, the traffic will go out to the Internet, and has the potential to overflow the state table on the firewall, cost money in bandwidth usage, and/or degrade performance for everything on the Internet connection.
Outbound SMTP is another example. Only allow SMTP (TCP port 25) to leave any network from a mail server. Or if a mail server is externally hosted, only allow internal systems to talk to that specific outside system on TCP port 25. This prevents every other system in the local network from being used as a spam bot, since their SMTP traffic will be dropped. Many mail providers have moved to using only authentication submission from clients using TCP port 587, so clients should not need access to port 25. This has the obvious benefit of limiting spam, and also prevents the network from being added to numerous black lists across the Internet that will prevent that site from sending legitimate e-mail to many mail servers. This may also prevent the ISP for that site from shutting off its Internet connection due to abuse.
The ideal solution is to prevent these types of things from happening in the first place, but egress filtering provides another layer that can help limit the impact if other measures fail.
Prevent a Compromise¶
Egress filtering can prevent a compromise in some circumstances. Some exploits and worms require outbound access to succeed. An older but good example of this is the Code Red worm from 2001. The exploit caused affected systems to pull an executable file via TFTP (Trivial File Transfer Protocol) and then execute it. A web server almost certainly does not need to use the TFTP protocol, and blocking TFTP via egress filtering prevented infection with Code Red even on unpatched servers. This is largely only useful for stopping completely automated attacks and worms as a real human attacker will find any holes that exist in egress filtering and use them to their advantage. Again, the correct solution to prevent such a compromise is to fix the network vulnerabilities used as an attack vector, however egress filtering can help.
Limit Unauthorized Application Usage¶
Many applications such as VPN clients, peer-to-peer software, instant messengers, and more rely on atypical ports or protocols to function. While a growing number of peer-to-peer and instant messenger applications will port hop until finding a port which is allowed out of the local network, many will be prevented from functioning by a restrictive egress ruleset, and this is an effective means of limiting many types of VPN connectivity.
Prevent IP Spoofing¶
This is a commonly cited reason for employing egress filtering, but pfSense automatically blocks spoofed traffic via pf’s antispoof functionality, so it isn’t applicable here. Preventing IP Spoofing means that malicious clients cannot send traffic with obviously falsified source addresses.
Prevent Information Leaks¶
Certain protocols should never be allowed to leave a local network. Specific examples of such protocols vary from one environment to another, but a few common examples are:
Microsoft RPC (Remote Procedure Call) on TCP port 135
NetBIOS on TCP and UDP ports 137 through 139
SMB/CIFS (Server Message Block/Common Internet File System) on TCP and UDP port 445.
Stopping these protocols can prevent information about the internal network from leaking onto the Internet, and will prevent local systems from initiating authentication attempts with Internet hosts. These protocols also fall under Limit the Impact of a Compromised System as discussed previously since many worms have relied upon these protocols to function. Other protocols that may be relevant are syslog, SNMP, and SNMP traps. Restricting this traffic will prevent misconfigured network devices from sending logging and other potentially sensitive information out to the Internet. Rather than worry about what protocols can leak information out of a local network and need to be blocked, the best practice is to only allow the traffic that is required.
Approaches for implementing egress filtering¶
On a network that has historically not employed egress filtering, it can be difficult to know what traffic is absolutely necessary. This section describes some approaches for identifying traffic and implementing egress filtering.