April 21, 2014 at 20:53What gets into deny ip any any?
Most implementations of access lists imply “all that is not allowed is forbidden” behavior. A reasonable approach, taking into account the fact that during the design process we anticipate this or that type of traffic in a certain direction in advance: if we have a subscriber or a peer-to-peer partner connected, then there should be no data from other IPs on this interface, and if we have an Internet connection, where do private addresses come from? Or maybe all this in vain? Maybe there is no spurious traffic and an unconditional ban in the ACL is just a transfer of resources. After all, the operator gives out the addresses to the customers themselves, and peer-to-peer partners and upstream providers are communication brothers, who must understand the complexity and sensitivity of the situation. Unfortunately, this is not the case at all.
DDoS Roundtable at YaC2013very much complained that with all the existing recommendations, no one is trying to deal with the security of their networks. That is, you must start first with yourself (with telecom operators), at least deal with IP spoofing.
From what it protects,
Our network is a provider with subscribers, peering partners and uplinks:
First, the first interface (one of) int1 towards subscribers, and a simple entry access list:
Allowed ICMP, already established connections and traffic only from the connected part of the subscriber network. We look what came across.
In this case, the destination address is part of a block belonging to the UK Department of Defense . It would seem that here is a manifestation of network solidarity - with the world on a thread and do not need any anti-DDoS funds. But in fact, this is just Hamachi getting out of control with its illegal global IP addresses, when traffic does not go through a tunnel, but through a common routed space, that is, the UK still gets it.
Local to our network
Google
Megaphone
Beeline
MTS
Private address
Destinations do not have addresses that belong to our network. But since the servers are real, it can be assumed that in some case the internal structure of the addressing that is currently connected or previously connected to the subscriber’s provider may be revealed.
Interestingly, the source of this traffic is the node, with the exact address specified as the destination.
Here, as in the previous case, the traffic source node has one of the addresses specified as the destination address on the interface. These two cases remained a mystery to me - who, how and why?
Probably the most explainable. Due to the fact that the address is constant, it is either configured second on the main interface, or on another device in the subscriber’s network, or is used by one of the applications.
The above options found in many places are the most widespread, the rest are only isolated cases.
These cases are worth explaining, since all subscribers are behind NAT and have private addressing, the appearance of the provider’s public address on the network, just like the destination address, is not at all usual.
Most of what we managed to investigate and somehow explain is not related to any deliberate or malicious actions, often these are configuration errors, mostly automatic, when connecting a second provider (usually 3G modems), using various tunnel programs (like Hamachi, first case) or P2P clients.
Now let's look at the traffic from the peering partner int2 : BGP interface and only known public addresses. The access list is a bit more complicated, in addition to the previous one, separate rules for private networks were made:
It is worth paying attention to the ratio of the number of matches
There are not many events, but we can assume that this case has something in common with option 5 in the previous section.
The address is globally routable, and there was never a shortage of people who wanted to test the strength of network security. In fairness, it should be noted that similar cases occur on the internal network, but they are cut off by another protection mechanism, so this was not noticeable in the examples above.
It remains to see what we can expect from the Internet int3 . The access list is the same as before, but access is now possible from all addresses, and not just from previously known ones.
Immediately noteworthy is the greater variety of source addresses including 0.0.0.0 and 255.255.255.255. Otherwise, we have almost the same thing as with a peering partner.
This time, SSH and SIP ports.
That's probably all. The fundamental difference between working with external connections is the lack of attempts to access other than our addresses. All packets came where necessary, though not always from the addresses that would be appropriate in this situation. Also, in relative terms, much less nonsense flies from external networks than from its own subscribers. That is, the presence of an administrator on the network solves almost all problems.
Of course, not being a network security specialist, I do not always understand what this or that line is prohibited, but it seems like nothing frankly malicious came across, as I said above, mostly configuration errors. In any case, be vigilant, defend yourself from external, and primarily from internal threats, so that we all can be calmer.
DDoS Roundtable at YaC2013very much complained that with all the existing recommendations, no one is trying to deal with the security of their networks. That is, you must start first with yourself (with telecom operators), at least deal with IP spoofing.
From what it protects,
deny ip any anyyou can see further, just examples from the monitoring logs. Our network is a provider with subscribers, peering partners and uplinks:
First, the first interface (one of) int1 towards subscribers, and a simple entry access list:
10 permit icmp any any (1483430 matches) 20 permit tcp any any established (26903 matches) 30 permit ip 10.100.x.0 0.0.0.255 any (923840 matches) 40 deny ip any any (201 matches)
Allowed ICMP, already established connections and traffic only from the connected part of the subscriber network. We look what came across.
Deny any from subscribers
1. Many public source addresses, and one public destination address. None of the addresses belong to us:
denied tcp 81.200.20.77(64112) -> 25.189.67.187(44335) denied tcp 46.147.230.241(60676) -> 25.189.67.187(44335) denied tcp 95.154.77.187(49623) -> 25.189.67.187(44335) denied udp 95.54.131.126(10000) -> 25.189.67.187(44335) denied udp 95.221.80.35(20743) -> 25.189.67.187(44335) denied tcp 212.92.250.137(52335) -> 25.189.67.187(44335) denied tcp 93.124.112.244(62817) -> 25.189.67.187(44335)
In this case, the destination address is part of a block belonging to the UK Department of Defense . It would seem that here is a manifestation of network solidarity - with the world on a thread and do not need any anti-DDoS funds. But in fact, this is just Hamachi getting out of control with its illegal global IP addresses, when traffic does not go through a tunnel, but through a common routed space, that is, the UK still gets it.
2. Source - name servers, mostly real:
Local to our network
denied udp 10.10.0.2(domain) -> 169.254.32.112(31049) denied udp 10.10.1.2(domain) -> 169.254.37.66(52758) denied udp 10.10.1.2(domain) -> 10.75.144.128(36985)
denied udp 8.8.8.8(domain) -> 172.22.81.195(7116) denied udp 8.8.8.8(domain) -> 169.254.32.112(17726) denied udp 8.8.8.8(domain) -> 169.254.32.112(21974)
Megaphone
denied udp 83.149.22.14(domain) -> 172.22.81.195(32844)
Beeline
denied udp 217.118.66.243(domain) -> 10.193.166.57(31159) denied udp 217.118.66.243(domain) -> 10.205.222.222(42160) denied udp 217.118.66.243(domain) -> 10.204.57.217(53646) denied udp 217.118.66.243(domain) -> 10.198.108.220(2125)
MTS
denied udp 217.74.244.2(domain) -> 10.108.170.22(31425) denied udp 217.74.244.2(domain) -> 10.77.119.212(43896) denied udp 217.74.244.3(domain) -> 10.86.224.44(25234)
Private address
denied udp 192.168.1.1(domain) -> 169.254.48.228(59050)
Destinations do not have addresses that belong to our network. But since the servers are real, it can be assumed that in some case the internal structure of the addressing that is currently connected or previously connected to the subscriber’s provider may be revealed.
3. Many public source addresses (sometimes addresses from a subscriber network) and one destination address in a subscriber network:
denied udp 5.76.188.102(6881) -> 10.100.178.87(49001) denied udp 178.185.77.225(14548) -> 10.100.178.87(16414) denied udp 83.149.44.138(3251) -> 10.100.178.87(64375) denied tcp 10.100.38.30(51167) -> 10.100.178.87(64375) denied udp 178.216.69.13(1375) -> 10.100.172.135(21787)
Interestingly, the source of this traffic is the node, with the exact address specified as the destination.
4. Close in form to the previous version, but the destination address is a private address that does not belong to any of the known nodes in the network:
denied udp 82.238.44.240(42300) -> 172.16.8.83(52987) denied udp 82.255.186.101(20344) -> 172.16.8.83(52987) denied tcp 79.31.185.28(53369) -> 172.16.8.83(52987) denied tcp 10.100.34.79(50984) -> 192.168.137.1(13472) denied tcp 10.100.236.119(54821) -> 192.168.137.1(13472) denied tcp 188.244.185.76(2503) -> 192.168.137.1(13472) denied udp 86.176.51.60(36740) -> 169.254.12.28(29970) denied udp 171.7.208.183(27161) -> 169.254.12.28(29970) denied udp 24.53.252.132(24874) -> 169.254.12.28(29970) denied udp 89.110.5.117(36505) -> 172.20.10.4(14957) denied tcp 80.255.155.125(60134) -> 172.20.10.4(14957) denied tcp 128.70.16.74(51952) -> 172.20.10.4(14957) denied tcp 178.140.142.84(64797) -> 10.0.16.19(61789) denied tcp 88.215.186.103(59343) -> 10.0.16.19(61789) denied tcp 80.77.41.98(54474) -> 10.0.16.19(61789)
Here, as in the previous case, the traffic source node has one of the addresses specified as the destination address on the interface. These two cases remained a mystery to me - who, how and why?
5. One private source address and many public destination addresses (sometimes addresses from a subscriber network):
denied udp 192.168.0.17(45927) -> 93.185.249.103(43213) denied tcp 192.168.0.17(52596) -> 82.208.126.93(58025) denied udp 192.168.0.17(45927) -> 46.72.40.240(19047) denied udp 192.168.0.5(22475) -> 188.18.233.101(42763) denied tcp 192.168.0.5(57165) -> 109.61.147.132(46895) denied udp 192.168.1.3(28199) -> 136.169.166.182(42584) denied udp 192.168.1.3(28199) -> 94.41.133.198(46843) denied udp 192.168.0.101(43137) -> 10.100.44.151(49393) denied udp 192.168.0.101(43137) -> 10.100.26.39(20080) denied udp 192.168.0.101(43137) -> 10.100.72.63(35692)
Probably the most explainable. Due to the fact that the address is constant, it is either configured second on the main interface, or on another device in the subscriber’s network, or is used by one of the applications.
The above options found in many places are the most widespread, the rest are only isolated cases.
6. Source - the public address of the provider's network:
denied udp 203.0.113.18(26585) -> 213.67.20.238(6112)
7. Purpose - the public address of the provider's network:
denied udp 62.148.7.195(17278) -> 203.0.113.65(40178) denied udp 62.148.7.195(19176) -> 203.0.113.65(40180) denied udp 62.148.7.195(16186) -> 203.0.113.65(40182) denied udp 62.148.7.195(19970) -> 203.0.113.65(40184)
These cases are worth explaining, since all subscribers are behind NAT and have private addressing, the appearance of the provider’s public address on the network, just like the destination address, is not at all usual.
8. “Strange” even in this context, addresses and protocols:
denied 154 73.246.67.151() -> 128.106.162.245() denied all 175.223.240.56() -> 64.0.0.0() denied tcp 64.8.0.1(61445) -> 0.0.0.1(128)
Most of what we managed to investigate and somehow explain is not related to any deliberate or malicious actions, often these are configuration errors, mostly automatic, when connecting a second provider (usually 3G modems), using various tunnel programs (like Hamachi, first case) or P2P clients.
Deny any by peer partner
Now let's look at the traffic from the peering partner int2 : BGP interface and only known public addresses. The access list is a bit more complicated, in addition to the previous one, separate rules for private networks were made:
10 permit icmp any any (1360250 matches) 20 permit tcp any any established (199798954 matches) 30 permit bgp host 192.0.2.1 host 192.0.2.2 (11887 matches) 40 permit ip 192.0.2.0 0.0.0.255 203.0.113.0 0.0.0.255 (775443105 matches) 50 deny ip 10.0.0.0 0.255.255.255 any (1280 matches) 60 deny ip 172.16.0.0 0.15.255.255 any (2 matches) 70 deny ip 192.168.0.0 0.0.255.255 any (1335 matches) 80 deny ip 169.254.0.0 0.0.255.255 any 90 deny ip 127.0.0.0 0.255.255.255 any 100 deny ip host 0.0.0.0 any 110 deny ip host 255.255.255.255 any 120 deny ip any any (540 matches)
It is worth paying attention to the ratio of the number of matches
denyand permitrules in relation to the previous ACL. There are fewer incomprehensible things, approximately 1 deny per 200,000 permit, in the previous example this is a ratio of 1 to 5000, which tells us about the presence of a controlled network structure that is present with our partner and which is not present with our subscribers. But in this case, too, something leaks out.1. Rules 50.60.70 - access from private addresses that do not belong to us, nor to a peering partner, to our public addresses:
denied udp 192.168.0.101(6881) -> 203.0.113.251(6881) denied udp 192.168.0.249(47597) -> 203.0.113.147(23392) denied udp 10.112.112.112(63973) -> 203.0.113.249(42873) denied tcp 192.168.0.57(57055) -> 203.0.113.38(37654)
There are not many events, but we can assume that this case has something in common with option 5 in the previous section.
2. But deny ip any any showed suddenly the expected events - attempts to access the interface address 192.0.2.2 from public addresses not belonging to the peering partner:
denied udp 5.255.68.168(7678) -> 192.0.2.2(123) denied udp 84.105.139.67(42440) -> 192.0.2.2(161)
The address is globally routable, and there was never a shortage of people who wanted to test the strength of network security. In fairness, it should be noted that similar cases occur on the internal network, but they are cut off by another protection mechanism, so this was not noticeable in the examples above.
Deny any from the Internet
It remains to see what we can expect from the Internet int3 . The access list is the same as before, but access is now possible from all addresses, and not just from previously known ones.
10 permit icmp any any (142814260 matches) 20 permit tcp any any established (29633491483 matches) 30 permit bgp host 198.51.100.1 host 198.51.100.2 (1727903 matches) 40 permit ip any 203.0.113.0 0.0.0.255 (23122741548 matches) 50 deny ip 10.0.0.0 0.255.255.255 any (447026 matches) 60 deny ip 172.16.0.0 0.15.255.255 any (121911 matches) 70 deny ip 192.168.0.0 0.0.255.255 any (191732 matches) 80 deny ip 169.254.0.0 0.0.255.255 any (1733 matches) 90 deny ip 127.0.0.0 0.255.255.255 any (3415 matches) 100 deny ip host 0.0.0.0 any (46 matches) 110 deny ip host 255.255.255.255 any (9 matches) 120 deny ip any any (1278 matches)
Immediately noteworthy is the greater variety of source addresses including 0.0.0.0 and 255.255.255.255. Otherwise, we have almost the same thing as with a peering partner.
1. Private address from publicly routed space to the public address of the provider:
denied udp 192.168.0.106(61104) -> 203.0.113.84(18636) denied tcp 10.0.3.49(54996) -> 203.0.113.243(21603) denied udp 10.240.77.25(38170) -> 203.0.113.106(25175) denied tcp 172.20.56.135(49995) -> 203.0.113.210(60623) denied tcp 10.60.33.69(49388) -> 203.0.113.206(54312)
2. Same as the first case, but as a source a public address from our network:
denied udp 203.0.113.18(56425) -> 203.0.113.21(6502)
3. Access to the router’s docking address, the same as in the case of a peering partner:
denied udp 116.10.191.170(6000) -> 198.51.100.2(22) denied udp 5.152.192.210(5135) -> 198.51.100.2(5060)
This time, SSH and SIP ports.
That's probably all. The fundamental difference between working with external connections is the lack of attempts to access other than our addresses. All packets came where necessary, though not always from the addresses that would be appropriate in this situation. Also, in relative terms, much less nonsense flies from external networks than from its own subscribers. That is, the presence of an administrator on the network solves almost all problems.
Of course, not being a network security specialist, I do not always understand what this or that line is prohibited, but it seems like nothing frankly malicious came across, as I said above, mostly configuration errors. In any case, be vigilant, defend yourself from external, and primarily from internal threats, so that we all can be calmer.