Most active commenters

    ←back to thread

    253 points akyuu | 11 comments | | HN request time: 0s | source | bottom
    1. qwertox ◴[] No.45945900[source]
    Since I moved my DNS records to Cloudflare (that is: nameserver is now the one from Cloudflare), I get tons of odd connections, most notably SYN packets to eihter 443 or 22, which never respond back after the SYN-ACK. They ping me once a second in average, distributing the IPs over a /24 network.

    I really don't understand why they do this, and it's mostly some shady origins, like vps game server hoster from Brazil and so on.

    I'm at the point where i capture all the traffic and looks for SYN packets, check the RDAP records for them to decide if I then drop the entire subnets of that organization, whitelisting things like Google.

    Digital Ocean is notoriously a source of bad traffic, they just don't care at all.

    replies(3): >>45946146 #>>45946726 #>>45947542 #
    2. kzemek ◴[] No.45946146[source]
    These are spoofed packets for SYNACK reflection attacks. Your response traffic goes to the victim, and since network stacks are usually configured to retry SYNACK a few times, they also get amplification out of it
    replies(1): >>45949976 #
    3. sva_ ◴[] No.45946726[source]
    > like vps game server hoster from Brazil and so on.

    Probably someone DDoSing a Minecraft server or something.

    People in games do this where they DDoS each other. You can get access to a DDoS panel for as little as $5 a month.

    Some providers allow for spoofing the src ip, that's how they do these reflection attacks. So you're not actually dropping the sender of these packets, but the victims.

    Consider turning reverse path filter to strict as a basic anti spoofing method and see if it helps

        net.ipv4.conf.all.rp_filter = 1
        net.ipv4.conf.default.rp_filter = 1
    replies(3): >>45946979 #>>45947027 #>>45955320 #
    4. qwertox ◴[] No.45946979[source]
    Thanks, it never came to my mind.
    5. cute_boi ◴[] No.45947027[source]
    I believe kernel should make this behavior as default.
    6. ranger_danger ◴[] No.45947542[source]
    > Digital Ocean is notoriously a source of bad traffic, they just don't care at all.

    Why should it be an ISP's job to police what their users can and can't do? I really don't think you want service providers to start moderating things.

    Does your electricity company ban the use of red light bulbs? Would everyone be ok with such restrictions?

    replies(2): >>45947720 #>>45948038 #
    7. selectodude ◴[] No.45947720[source]
    No but your electricity company will absolutely rat you out if your electricity usage skyrockets and the police will pop by to see if you’re running a grow op or something.
    replies(2): >>45948826 #>>45949411 #
    8. esseph ◴[] No.45948826{3}[source]
    Not anymore (depending on the state, and not since LED grow lights).
    9. ranger_danger ◴[] No.45949411{3}[source]
    This is why I don't open the door for anyone. If the police really want in, they won't be using the doorbell anyways.
    10. pabs3 ◴[] No.45949976[source]
    There is a solution to that, but it requires these companies to implement source address validation. If your ISP is on the list, maybe complain about it.

    https://spoofer.caida.org/as_stats.php

    11. jcalvinowens ◴[] No.45955320[source]
    How does rp_filter on the server side help at all? For a cloud server with a single interface it literally does nothing. Maybe I'm misunderstanding your suggestion.