What gets into deny ip any any?

Most implementations of access lists imply the behavior of “everything that is not allowed is forbidden”. A reasonable approach, taking into account the fact that when designing, we expect in advance one or another type of traffic in a certain direction: if we have a subscriber or a peering partner connected, it means there should not be data from other IP on this interface, and if we have Internet access, where do private addresses come from? And maybe it's all for nothing? Maybe there is no parasitic traffic and an absolute ban in the ACL is only the transfer of resources. After all, the operator itself provides the clients with the addresses, and the peer-to-peer partners and upstream providers are communication service brothers who must understand the complexity and delicacy of the situation. Unfortunately, this is not the case.
The participants of the round table dedicated to DDoS, held at YaC2013, complained very much that with all the existing recommendations no one tries to deal with the security of their networks. That is, one should start first with oneself (with telecom operators), at least fight IP spoofing.
From what deny ip any any protects you can see further, just examples from monitoring logs.

Our network is a provider with subscribers, peering partners and uplinks:

First, the first interface (one of) int1 in the direction of subscribers, and a simple list of access to the input:

 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 that got.
')

Deny any by 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 included in the unit belonging to the Department of Defense of Great Britain . 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 out of control Hamachi with its illegal global IP addresses, when the traffic goes not through a tunnel, but through a common routed space, that is, the UK, however, it gets.

2. Source - name servers, mostly real:

Local 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) 

Google

 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) 

Destination addresses do not have addresses belonging to our network. But since the servers are real, it can be assumed that in some case the internal structure of the addressing system that is currently connected or previously connected to the provider’s subscriber can be revealed.

3. Many public source addresses (sometimes addresses from the subscriber network) and one destination address in the 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 host, with the exact address specified as the destination.

4. Close in form to the previous version, but as a 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 multiple public destination addresses (sometimes addresses from the 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 permanent, 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 are found in many places are the most widespread, the rest are only isolated cases.

6. Source - public address of the provider's network:

 denied udp 203.0.113.18(26585) -> 213.67.20.238(6112) 

7. Appointment - 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 should be clarified, since all subscribers are behind NAT and have private addressing, the appearance of the public address of the provider as the source, exactly 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 has been investigated and somehow explained does not apply to any deliberate or malicious actions, often these are configuration errors, mostly automatic, when a second provider is connected (usually 3G modems), using various tunnel programs (like Hamachi, in first case) or P2P clients.

Deny any from the peering partner

Now let's look at the traffic from the peering partner's partner int2 : BGP junction and only known public addresses. The access list is a bit more complicated; in addition to the previous, 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 deny matches and permit rules in relation to the previous ACL. Incomprehensible things happen less, about 1 deny per 200000 permit, in the previous example this ratio is 1 to 5000, which tells us about the presence of a controlled network structure, which is present in our partner and which is not present in our subscribers. But in this case, too, something is leaking.

1. Rules 50,60,70 - access from private addresses not belonging to us, nor peering to a 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 it can be assumed 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 is never a lack of security for those who want to test the strength of the network. In fairness, it should be noted that similar cases occur in 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 to expect from the Internet int3 . The access list is the same as before, but access is now possible from all addresses, and not only 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 attracts the attention of a greater variety of source addresses including 0.0.0.0 and 255.255.255.255. For the rest, we have almost the same as with the peering partner.

1. Private address from publicly routable 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, the public address from our network:

 denied udp 203.0.113.18(56425) -> 203.0.113.21(6502) 

3. Access to the docking address of the router, the same as in the case of 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 the ports are ssh and sip.

That's probably all. The fundamental difference between working with external connections is the lack of attempts to access not our addresses. All packages came where necessary, though not always from those addresses that would be appropriate in this situation. Also, in relative terms, outwardly nonsense external networks arrive much less than from their 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 don’t always understand what this or that line means that was banned, but I didn’t find anything that was openly malicious, as I said above, basically configuration errors. In any case - be vigilant, protect yourself from external, and first of all from internal threats, so that we all feel calmer.