Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


DDoS Attack - What would you do?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

DDoS Attack - What would you do?

randvegetarandvegeta Member, Host Rep

For the past 30 hours, we've been getting DDoS. The affected subnet has been re-routed through our mitigation service and so remain 100% online. The only issue is, the mitigation is increasing latency for the affected subnet.

Our primary upstreams in HK do not propogate our null-routes so we see the traffic hitting our routers all the time, so a null-route of the IP is not a solution. The server being attacked has already been shut down (over 18 hours ago), and yet the attack persists.

It's not the end of the world, since we are still up and running, but some people are not too happy with the higher latency.

At the moment, seems we must wait out the attack before reverting back to normal network config. But perhaps someone else has a better suggestion?

From what I can see, the attack is not continuous and seems to be relatively predictable as to how long the attacks last and how often. Since activating the mitigation service, the attacks have started to grow in size. The attack traffic has doubled in the last 12 hours.

I suspect the attacker is renting a botnet and increased the attack size after realizing his attack had no affect on our network any more. But since the target IP has already been shut down, I am curious why the attack is persisting at all. Perhaps it was a randomly selected IP, and the client may be completely innocent in this case?

Anyone know of this kind of tactic?

«1

Comments

  • desperanddesperand Member
    edited October 2017

    Welcome in da club bro of super lucky guys :3

  • Try giving the client a new ip, and have him update his dns records. If the attack shifts to the new ip, you know that it's the client that's being targetted.

    If the attack persists on the old ip, it's just someone that hates you and your network.

  • NeoonNeoon Community Contributor, Veteran

    @teamacc said:
    Try giving the client a new ip, and have him update his dns records. If the attack shifts to the new ip, you know that it's the client that's being targetted.

    If the attack persists on the old ip, it's just someone that hates you and your network.

    Well, usually if they hate you, really hate you, they just look up your IP space and boot everything what you announced.

  • Let's just not hope your client has angered the wrong person at HF. Perhaps they purchased a booter/botnet and are now playing allmighty :/

  • randvegetarandvegeta Member, Host Rep

    @Ympker said:
    Let's just not hope your client has angered the wrong person at HF. Perhaps they purchased a booter/botnet and are now playing allmighty :/

    HF?

    Whatever, I'll just keep the protection enabled until they stop .

  • @randvegeta said:

    @Ympker said:
    Let's just not hope your client has angered the wrong person at HF. Perhaps they purchased a booter/botnet and are now playing allmighty :/

    HF?

    Whatever, I'll just keep the protection enabled until they stop .

    HackForums

  • You need upstreams, that provide nullrouting and, preferably, flowspec. We use FastNetMon Advanced to analyze traffic and announce BGP flowspec rules to our upstreams. If that fails - nullroute always remains as a failover option.

  • randvegetarandvegeta Member, Host Rep

    @mkamolins said:
    You need upstreams, that provide nullrouting and, preferably, flowspec. We use FastNetMon Advanced to analyze traffic and announce BGP flowspec rules to our upstreams. If that fails - nullroute always remains as a failover option.

    Hk upstream providers just don't seem to offer it. At least not the ones that actually have good Bandwidth. You can with Cogent and hurricane electric, but both of those are crap for China routing. Can't do it with PCCW, HGC, Pacnet or HKBN.

  • @randvegeta said:
    Hk upstream providers just don't seem to offer it. At least not the ones that actually have good Bandwidth. You can with Cogent and hurricane electric, but both of those are crap for China routing. Can't do it with PCCW, HGC, Pacnet or HKBN.

    Ability to block a single IP address is just critical to any hosting-related business, either with announcing this IP with blackhole community via BGP, having enough bandwidth to block it on your own border routers or just call your upstream and ask them to block the address.
    You just can't sustain without it.

  • WilliamWilliam Member
    edited October 2017

    randvegeta said: I suspect the attacker is renting a botnet and increased the attack size after realizing his attack had no affect on our network any more. But since the target IP has already been shut down, I am curious why the attack is persisting at all.

    You pay for attacks by duration, if down you still pay and the attack continues - this is the case on most booters.

    mkamolins said: You need upstreams, that provide nullrouting and, preferably, flowspec

    That sounds easy in EU or US, but not in Asia or Africa. South America is special as for efficiency you only need to get your shit nulled at Telmex/Claro and few other major players.

    randvegeta said: Whatever, I'll just keep the protection enabled until they stop .

    randvegeta said: At least not the ones that actually have good Bandwidth. You can with Cogent and hurricane electric, but both of those are crap for China routing. Can't do it with PCCW, HGC, Pacnet or HKBN.

    PCCW has communities - send to [email protected] to enable, someone sent me these at one point:

    Local Preference    BGP Community
    70  3491:7
    80  3491:8
    90  3491:9
    100 (Default)   3491:10
    110 3491:11
    
    
    US   
    Region  BGP Community
    North America (East Coast)  3491:100 (Customer)
    North America (East Coast)  3491:1000 (Peer)
    
    
    Location    Region  PoP Code
    Ashburn (ASH01) 3491:1000   3491:1001
    Vienna (VNA01)  3491:1000   3491:1002
    Washington DC (WDC01)   3491:1000   3491:1003
    Baltimore (BLT01)   3491:1000   3491:1004
    Philadelphia (PHL02)    3491:1000   3491:1005
    New York (NYC01)    3491:1000   3491:1006
    Miami (MIA02)   3491:1000   3491:1007
    Atlanta (ATL01) 3491:1000   3491:1008
    Miami (MIA01)   3491:1000   3491:1009
    New York (NYC02)    3491:1000   3491:1010
    Washington DC (WDC02)   3491:1000   3491:1011
    
    
    Region  BGP Community
    North America (West Coast)  B3491:200 (Customer)
    North America (West Coast)  B3491:2000 (Peer)
    
    
    Location    Region  PoP Code
    Dallas (DAL01)  3491:2000   3491:2001
    Chicago (CHC01) 3491:2000   3491:2002
    Seattle (SEA01) 3491:2000   3491:2003
    SanJose (SJO01) 3491:2000   3491:2004
    Los Angeles (LAX01) 3491:2000   3491:2005
    Los Angeles (LAX03) 3491:2000   3491:2006
    Los Angeles (LAX04) 3491:2000   3491:2007
    Los Angeles (LAX05) 3491:2000   3491:2009
    Denver (DEN01)  3491:2000   3491:2008
    
    
    Europe   
    Region  BGP Community
    Europe  3491:300 (Customer)
    Europe  3491:3000 (Peer)
    
    
    Location    Region  PoP Code
    London (LDN01)  3491:3000   3491:3001
    FrankFurt (FRF02)   3491:3000   3491:3002
    Milan (MIL01)   3491:3000   3491:3003
    Amsterdam (AMS01)   3491:3000   3491:3004
    Stockholm (STK01)   3491:3000   3491:3005
    Paris (PAR01)   3491:3000   3491:3006
    Paris (PAR02)   3491:3000   3491:3007
    Paris (PAR03)   3491:3000   3491:3008
    
    
    Asia     
    Region  BGP Community
    Asia    3491:400 (Customer)
    Asia    3491:4000 (Peer)
    
    
    Location    Region  PoP Code
    Hong Kong (HKG04)   3491:4000   3491:4001
    Hong Kong (HKG02)   3491:4000   3491:4002
    Shenzen (SZN01) 3491:4000   3491:4003
    Shanghai (SHG01)    3491:4000   3491:4004
    Taipei (TAP01)  3491:4000   3491:4005
    Dungguan (DGN01)    3491:4000   3491:4006
    Hong Kong (HKG05)   3491:4000   3491:4007
    Tokyo (TOK01)   3491:4000   3491:4008
    
    
    Region  BGP Community
    North America (East Coast)  3491:100 (Customer)
    North America (East Coast)  3491:1000 (Peer)
    North America (West Coast)  3491:200 (Customer)
    North America (West Coast)  3491:2000 (Peer)
    Europe  3491:300 (Customer)
    Europe  3491:3000 (Peer)
    Asia    3491:400 (Customer)
    Asia    3491:4000 (Peer)
    
    
    Public Peers    Region  BGP Community
    Equinix Ashburn 3491:1000   3491:1001
    MAE-East    3491:1000   3491:1002
    NOTA    3491:1000   3491:1007
    Atlanta-IX  3491:1000   3491:1008
    Equinix Dallas  3491:2000   3491:2001
    Equinix Chicago 3491:2000   3491:2002
    AADS Chicago    3491:2000   3491:2002
    SIX 3491:2000   3491:2003
    Equinix SanJose 3491:2000   3491:2004
    MAE-West SanJose    3491:2000   3491:2004
    Equinix LA  3491:2000   3491:2007
    Any2 Exchange LA    3491:2000   3491:2009
    LINX    3491:3000   3491:3001
    XPE 3491:3000   3491:3001
    DE-CIX  3491:3000   3491:3002
    AMSIX   3491:3000   3491:3004
    PARIX   3491:3000   3491:3006
    HKIX    3491:4000   3491:4001
    
    
    Cogent (AS 174)  
    3491:60040  Surpress Announcement
    3491:60041  prepend ASN (one time)
    3491:60042  prepend ASN (two times)
    3491:60043  prepend ASN (three times)
    AT&T (AS 7018)   
    3491:60130  Surpress Announcement
    3491:60131  prepend ASN (one time)
    3491:60132  prepend ASN (two times)
    3491:60133  prepend ASN (three times)
    Qwest (AS 209)   
    3491:60060  Surpress Announcement
    3491:60061  prepend ASN (one time)
    3491:60062  prepend ASN (two times)
    3491:60063  prepend ASN (three times)
    Verizon (AS 19262)   
    3491:60090  Surpress Announcement
    3491:60091  prepend ASN (one time)
    3491:60092  prepend ASN (two times)
    3491:60093  prepend ASN (three times)
    
  • jackbjackb Member, Host Rep

    @randvegeta said:

    @mkamolins said:
    You need upstreams, that provide nullrouting and, preferably, flowspec. We use FastNetMon Advanced to analyze traffic and announce BGP flowspec rules to our upstreams. If that fails - nullroute always remains as a failover option.

    Hk upstream providers just don't seem to offer it. At least not the ones that actually have good Bandwidth. You can with Cogent and hurricane electric, but both of those are crap for China routing. Can't do it with PCCW, HGC, Pacnet or HKBN.

    If you're still stuck after checking out @william's post, perhaps you could temporarily announce the impacted /24 over only upstreams that support nullrouting & flowspec?

  • jackb said: perhaps you could temporarily announce the impacted /24 over only upstreams that support nullrouting & flowspec?

    He has BGP for filtering, so it is filtered anyway at likely better quality than pure HE/HGC.

    The other way to only get CN traffic on them would be to prepend to the protected a few times and announce in addition via PCCW/other peer to China, this route should be shorter in distance.

  • randvegetarandvegeta Member, Host Rep

    @William said:

    randvegeta said: I suspect the attacker is renting a botnet and increased the attack size after realizing his attack had no affect on our network any more. But since the target IP has already been shut down, I am curious why the attack is persisting at all.

    You pay for attacks by duration, if down you still pay and the attack continues - this is the case on most booters.

    mkamolins said: You need upstreams, that provide nullrouting and, preferably, flowspec

    That sounds easy in EU or US, but not in Asia or Africa. South America is special as for efficiency you only need to get your shit nulled at Telmex/Claro and few other major players.

    randvegeta said: Whatever, I'll just keep the protection enabled until they stop .

    randvegeta said: At least not the ones that actually have good Bandwidth. You can with Cogent and hurricane electric, but both of those are crap for China routing. Can't do it with PCCW, HGC, Pacnet or HKBN.

    PCCW has communities - send to [email protected] to enable, someone sent me these at one point:

    > Local Preference  BGP Community
    > 70    3491:7
    > 80    3491:8
    > 90    3491:9
    > 100 (Default) 3491:10
    > 110   3491:11
    > 
    > 
    > US     
    > Region    BGP Community
    > North America (East Coast)    3491:100 (Customer)
    > North America (East Coast)    3491:1000 (Peer)
    > 
    > 
    > Location  Region  PoP Code
    > Ashburn (ASH01)   3491:1000   3491:1001
    > Vienna (VNA01)    3491:1000   3491:1002
    > Washington DC (WDC01) 3491:1000   3491:1003
    > Baltimore (BLT01) 3491:1000   3491:1004
    > Philadelphia (PHL02)  3491:1000   3491:1005
    > New York (NYC01)  3491:1000   3491:1006
    > Miami (MIA02) 3491:1000   3491:1007
    > Atlanta (ATL01)   3491:1000   3491:1008
    > Miami (MIA01) 3491:1000   3491:1009
    > New York (NYC02)  3491:1000   3491:1010
    > Washington DC (WDC02) 3491:1000   3491:1011
    > 
    > 
    > Region    BGP Community
    > North America (West Coast)    B3491:200 (Customer)
    > North America (West Coast)    B3491:2000 (Peer)
    > 
    > 
    > Location  Region  PoP Code
    > Dallas (DAL01)    3491:2000   3491:2001
    > Chicago (CHC01)   3491:2000   3491:2002
    > Seattle (SEA01)   3491:2000   3491:2003
    > SanJose (SJO01)   3491:2000   3491:2004
    > Los Angeles (LAX01)   3491:2000   3491:2005
    > Los Angeles (LAX03)   3491:2000   3491:2006
    > Los Angeles (LAX04)   3491:2000   3491:2007
    > Los Angeles (LAX05)   3491:2000   3491:2009
    > Denver (DEN01)    3491:2000   3491:2008
    > 
    > 
    > Europe     
    > Region    BGP Community
    > Europe    3491:300 (Customer)
    > Europe    3491:3000 (Peer)
    > 
    > 
    > Location  Region  PoP Code
    > London (LDN01)    3491:3000   3491:3001
    > FrankFurt (FRF02) 3491:3000   3491:3002
    > Milan (MIL01) 3491:3000   3491:3003
    > Amsterdam (AMS01) 3491:3000   3491:3004
    > Stockholm (STK01) 3491:3000   3491:3005
    > Paris (PAR01) 3491:3000   3491:3006
    > Paris (PAR02) 3491:3000   3491:3007
    > Paris (PAR03) 3491:3000   3491:3008
    > 
    > 
    > Asia   
    > Region    BGP Community
    > Asia  3491:400 (Customer)
    > Asia  3491:4000 (Peer)
    > 
    > 
    > Location  Region  PoP Code
    > Hong Kong (HKG04) 3491:4000   3491:4001
    > Hong Kong (HKG02) 3491:4000   3491:4002
    > Shenzen (SZN01)   3491:4000   3491:4003
    > Shanghai (SHG01)  3491:4000   3491:4004
    > Taipei (TAP01)    3491:4000   3491:4005
    > Dungguan (DGN01)  3491:4000   3491:4006
    > Hong Kong (HKG05) 3491:4000   3491:4007
    > Tokyo (TOK01) 3491:4000   3491:4008
    > 
    > 
    > Region    BGP Community
    > North America (East Coast)    3491:100 (Customer)
    > North America (East Coast)    3491:1000 (Peer)
    > North America (West Coast)    3491:200 (Customer)
    > North America (West Coast)    3491:2000 (Peer)
    > Europe    3491:300 (Customer)
    > Europe    3491:3000 (Peer)
    > Asia  3491:400 (Customer)
    > Asia  3491:4000 (Peer)
    > 
    > 
    > Public Peers  Region  BGP Community
    > Equinix Ashburn   3491:1000   3491:1001
    > MAE-East  3491:1000   3491:1002
    > NOTA  3491:1000   3491:1007
    > Atlanta-IX    3491:1000   3491:1008
    > Equinix Dallas    3491:2000   3491:2001
    > Equinix Chicago   3491:2000   3491:2002
    > AADS Chicago  3491:2000   3491:2002
    > SIX   3491:2000   3491:2003
    > Equinix SanJose   3491:2000   3491:2004
    > MAE-West SanJose  3491:2000   3491:2004
    > Equinix LA    3491:2000   3491:2007
    > Any2 Exchange LA  3491:2000   3491:2009
    > LINX  3491:3000   3491:3001
    > XPE   3491:3000   3491:3001
    > DE-CIX    3491:3000   3491:3002
    > AMSIX 3491:3000   3491:3004
    > PARIX 3491:3000   3491:3006
    > HKIX  3491:4000   3491:4001
    > 
    > 
    > Cogent (AS 174)    
    > 3491:60040    Surpress Announcement
    > 3491:60041    prepend ASN (one time)
    > 3491:60042    prepend ASN (two times)
    > 3491:60043    prepend ASN (three times)
    > AT&T (AS 7018)     
    > 3491:60130    Surpress Announcement
    > 3491:60131    prepend ASN (one time)
    > 3491:60132    prepend ASN (two times)
    > 3491:60133    prepend ASN (three times)
    > Qwest (AS 209)     
    > 3491:60060    Surpress Announcement
    > 3491:60061    prepend ASN (one time)
    > 3491:60062    prepend ASN (two times)
    > 3491:60063    prepend ASN (three times)
    > Verizon (AS 19262)     
    > 3491:60090    Surpress Announcement
    > 3491:60091    prepend ASN (one time)
    > 3491:60092    prepend ASN (two times)
    > 3491:60093    prepend ASN (three times)
    > 

    Interesting if they do it now. Last time I asked they did not have communities.

    In any case, we don't have PCCW. And HGC definitely does not support.

    @jackb said:

    @randvegeta said:

    @mkamolins said:
    You need upstreams, that provide nullrouting and, preferably, flowspec. We use FastNetMon Advanced to analyze traffic and announce BGP flowspec rules to our upstreams. If that fails - nullroute always remains as a failover option.

    Hk upstream providers just don't seem to offer it. At least not the ones that actually have good Bandwidth. You can with Cogent and hurricane electric, but both of those are crap for China routing. Can't do it with PCCW, HGC, Pacnet or HKBN.

    If you're still stuck after checking out @william's post, perhaps you could temporarily announce the impacted /24 over only upstreams that support nullrouting & flowspec?

    Already possible through he.net, but they have terrible routing for China so there is no point.

  • randvegetarandvegeta Member, Host Rep

    @mkamolins said:

    @randvegeta said:
    Hk upstream providers just don't seem to offer it. At least not the ones that actually have good Bandwidth. You can with Cogent and hurricane electric, but both of those are crap for China routing. Can't do it with PCCW, HGC, Pacnet or HKBN.

    Ability to block a single IP address is just critical to any hosting-related business, either with announcing this IP with blackhole community via BGP, having enough bandwidth to block it on your own border routers or just call your upstream and ask them to block the address.
    You just can't sustain without it.

    Welcome to Asia! Response time from upstreams can be hours or even days! They are completely unreliable for support.

    And buying many gbits of bandwidth to make sure we can handle the traffic at our edges is just too expensive in HK. Especially if you consider China traffic.

    Thanked by 1hostdare
  • randvegeta said: Welcome to Asia! Response time from upstreams can be hours or even days! They are completely unreliable for support.

    If at all and in a language you speak... Telstra/Optus/Singtel is a pleasure to work with, and if you know them that already tells you how horrible all others are.

    Not much easy choice than to wait, pretty much.

  • randvegetarandvegeta Member, Host Rep

    William said: Not much easy choice than to wait, pretty much.

    Then that's what I'll be doing. Annoying but at least I can sleep well.

  • joerijoeri Member, Host Rep, LIR

    How large is the attack?

    What for attack is it?

  • PwnerPwner Member
    edited October 2017

    Usually this:

    Thanked by 2quick randvegeta
  • randvegetarandvegeta Member, Host Rep

    @joeri said:
    How large is the attack?

    What for attack is it?

    UDP flood. Few gigabit. Every hour it grows a bit. The protection can handle 1tbit of attack traffic so I'm not concerned with the size of attack right now.

  • @randvegeta said:
    UDP flood. Few gigabit. Every hour it grows a bit. The protection can handle 1tbit of attack traffic so I'm not concerned with the size of attack right now.

    The best way to solve your problem is to report those DDoS attacks to the owners of the source IPs. Please make the victims aware that they are part of a botnet, so that they can take steps to clean their computers. The botnet is going to shrink in size, losing its ability to attack your networks.

  • randvegetarandvegeta Member, Host Rep

    chihcherng said: The best way to solve your problem is to report those DDoS attacks to the owners of the source IPs. Please make the victims aware that they are part of a botnet, so that they can take steps to clean their computers. The botnet is going to shrink in size, losing its ability to attack your networks.

    That's a lot of IPs to report.

  • @chihcherng said:

    @randvegeta said:
    UDP flood. Few gigabit. Every hour it grows a bit. The protection can handle 1tbit of attack traffic so I'm not concerned with the size of attack right now.

    The best way to solve your problem is to report those DDoS attacks to the owners of the source IPs. Please make the victims aware that they are part of a botnet, so that they can take steps to clean their computers. The botnet is going to shrink in size, losing its ability to attack your networks.

    Usually source IP isn't reliable since it can be spoofed.

  • RhysRhys Member, Host Rep

    chihcherng said: The best way to solve your problem is to report those DDoS attacks to the owners of the source IPs

    That is absolutely the worst possible advice you could give to someone receiving any form of UDP flood.

    Thanked by 1Clouvider
  • @Rhys said:
    That is absolutely the worst possible advice you could give to someone receiving any form of UDP flood.

    But it sounded prem, no?

    Thanked by 2Rhys vimalware
  • winnervpswinnervps Member, Host Rep

    Impossible to report any source of attackers IP. I experienced once, captured around 2.3M IP, but my router dead. No routers can handle such traffics nor "capture" them. Only enterprise grade that is design specific for that kind of situation (mostly Juniper series).

  • @jooja said:
    Usually source IP isn't reliable since it can be spoofed.

    This. Only exception would be reflection attacks and even then i'd question the sense in mailing hundreds of providers about their costumers crappy upnp devices or similar stuff.

  • ClouviderClouvider Member, Patron Provider

    @winnervps said:
    Impossible to report any source of attackers IP. I experienced once, captured around 2.3M IP, but my router dead. No routers can handle such traffics nor "capture" them. Only enterprise grade that is design specific for that kind of situation (mostly Juniper series).

    It doesn't matter. They just generate random source address on non-filtered links. It can be 1 server attacking you from millions of random IPs from the entire /0.

  • I mildly object. Lousy isps who don't scrub their network are a major culprit and should be hunted down and, in fact, even be treated as fair game.

    The reason udp ips are worth plain nothing is that them shitty isps don't do their job, particularly as they are the ones who can do it cheaply. After all they fucking know their ip ranges and could easily and cheaply filter out almost all of the crap. Similarly, my hoster/provider knows his ip ranges and could filter out crap easily.

    I spare you the question, though, how many of you do and how many don't. I guess we all have an idea about the state of things in our segment...

  • I got asked recently about what I would do if attacked by DDoS from open DNS resolvers. I know the source IP of UDP packets can be spoofed, but in this particular case, we could check whether they accept external DNS queries with a simple nslookup command. We could report only those verified open resolvers.

    I don't know if randvegeta was attacked by open resolvers or not. He didn't tell us. But to cope with DDoS or botnets, you have to report them as you find them. The only reason botnets and DDoS become big is because the victims don't know their computers are infected by malware or abused by hackers. Making them aware is not easy, a lot of work, but necessary.

  • winnervps said: Impossible to report any source of attackers IP. I experienced once, captured around 2.3M IP, but my router dead. No routers can handle such traffics nor "capture" them. Only enterprise grade that is design specific for that kind of situation (mostly Juniper series).

    No, you tried to configure a L3 mirror based on routing. Dumb idea. Configure a L2 port mirror of the uplink on another 10/40G interface, then depending on hardware either only redirect packets with DST=attack-dst or the entire flow and analyze on connected system.

    Or, you buy a reasonable router, that actually does flow analysis and output internally.

Sign In or Register to comment.