Home Explore Help
Register Sign In
EPuters_Mirrors
/
almanack_mirror
Watch 2
Star 0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Branch: main
Branches Tags
almanack_mir...
/
wiki.d
/
Openbsd.Ddos

Openbsd.Ddos 45 KB
Permalink History Raw

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111 
  1. version=pmwiki-2.2.130 ordered=1 urlencoded=1
    2. 

  2. agent=Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
    3. 

  3. author=mkf
    4. 

  4. charset=UTF-8
    5. 

  5. csum=a bit clean up.
    6. 

  6. ctime=1597226351
    7. 

  7. host=80.191.34.206
    8. 

  8. name=Openbsd.Ddos
    9. 

  9. rev=32
    10. 

  10. targets=Openbsd.SSDP,Openbsd.ACKFlood,Openbsd.Tcpresetflood,Openbsd.Cu,Openbsd.Vmmuser,Openbsd.Buyvm,Openbsd.Tcpdump,Openbsd.Scp,Openbsd.Sftp,Openbsd.SYNFlood,Openbsd.HTTPFlood,Openbsd.NTPAmplification,Openbsd.UDPFlood,Openbsd.RSTFlood,Openbsd.Police
    11. 

  11. text=(:title DDoS Defense Guide:)%0a%0a!! How to Detect an Attack%0a%0aIf suddenly you see many users disconnect from a server...%0a%0a[@%0a[12:31:23] *** Quits: Lucifer_|des (JohnReb@AEJva.DesireNET.Org) (Ping timeout)%0a[12:31:51] *** Quits: depeche|nat (depeche@depeche.users.nationchat.org) (Ping timeout)%0a[12:32:36] *** Quits: iulian7502|des (iulian@ADx0-.DesireNET.Org) (Ping timeout)%0a[12:34:07] *** Quits: Counter|under (CPT@CPT.fig.ircnow.org) (Ping timeout)%0a[12:34:12] *** Quits: katrok|quake (katrok@katrok.bnc1.ircnow.org) (Ping timeout)%0a[12:34:19] *** Quits: Lucifer|des (Lucifer@ACXJz.DesireNET.Org) (Ping timeout)%0a[12:35:29] *** Quits: depeche|quake (depeche@depeche.users.quakenet.org) (Ping timeout)%0a[12:35:38] *** Quits: Elafi|under (Elafi@Elafi.fig.ircnow.org) (Ping timeout)%0a[12:35:52] *** Quits: edu|dal (ed@fig.ircnow.org) (Ping timeout)%0a[12:36:45] *** Quits: Soportes (Soportes@Soportes.fig.ircnow.org) ("IRCNow and Forever!")%0a@]%0a%0a...your server may be under attack!%0a%0a!! Different Attack Types%0a%0aIf you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/SSDP|SSDP attack]] or a [[openbsd/ACKFlood|TCP ack flood]]. Logging and analyzing incoming packets is how we identify the attack type.%0a%0aIf you see many @@EOF from client@@, @@Read error: Input/output error@@, or @@Client closed connection@@ quit messages, this may be due to a [[openbsd/tcpresetflood|TCP reset flood]]:%0a%0a[@%0a[02:02:42] *** Quits: jrmu|dal (jrmu@jrmu.plum.ircnow.org) (Read error: Input/output error)%0a[02:02:42] *** Quits: semut_|dal (semut@semut.lu2.ircnow.org) (Client closed connection)%0a[02:02:42] *** Quits: starr|dal (starr@starr.lu2.ircnow.org) (Read error: Input/output error)%0a[02:02:42] *** Quits: Gisa|dal (thekingofb@thekingofbandit.lu2.ircnow.org) (Read error: Input/output error)%0a[02:02:42] *** Quits: Gisa|quake (thekingofb@lu2.ircnow.org) (EOF from client)%0a[02:02:42] *** Quits: Freak|quake (Freak@Freak.lu2.ircnow.org) (EOF from client)%0a[02:02:42] *** Quits: IRCuser|quake (unknwon@IRCuser.users.quakenet.org) (EOF from client)%0a[02:02:42] *** Quits: ramadi|quake (ramadi@ramadi.lu2.ircnow.org) (EOF from client)%0a[02:02:43] *** Quits: Fat1 (Fatfem@Fatfem.lu2.ircnow.org) (Client closed connection)%0a[02:02:43] *** Quits: Freak (Freak@Freak.lu2.ircnow.org) (Client closed connection)%0a@]%0a%0a!! Confirming an Attack%0a%0aTo see if there is a ddos attack, first run:%0a%0a[@%0a$ ping fruit.ircnow.org%0a@]%0a%0aReplace fruit.ircnow.org with your actual server's hostname. If you get more than 30%25 packet loss, this could be a sign you are being flooded with fake packets. During a DDoS, an attacker is flooding your internet pipe with junk packets so that your server is unable to respond to any real network traffic.%0a%0aCheck the serial console (using [[openbsd/cu|cu]] if on [[openbsd/vmmuser|VMM]], VNC if on [[openbsd/buyvm|BuyVM]]). Try to log in and see if the system is still responsive. If the server is offline or has errors, it may be due to hardware/software issues rather than a DDoS attack.%0a%0aDuring a DDoS attack, your system should feel slightly sluggish. This is due to the massive number of packets that OpenBSD must process. Run @@top@@. If you see the system/interrupt CPU usage at 50%25 or more, then you either have a process using too much CPU or you may be under an attack. If the CPU usage is low, under 5%25, it might not be a DDoS attack. It could be a networking or hardware issue, or an attack of another nature.%0a%0aIf you suspect an attack, you should log the packets that are coming in:%0a%0a[@%0a$ doas tcpdump -w YYYYMMDDSS.pcap%0a@]%0a%0aThis will log the packets onto the file @@YYYYMMDDSS.pcap@@, where YYYY is the year, MM is the month, DD is the day, and SS is the serial number.%0a%0aYou can fine-tune this:%0a%0a[@%0a$ doas tcpdump -i vio0 -s 1500 -A -v -n -w YYYYMMDDSS.pcap%0a@]%0a%0aIn the above command, the argument -i specifies the interface @@vio0@@, -s 1500 analyzes the first 1500 bytes, -A prints each packet in ASCII, -v provides more verbose output, and -n avoids address conversion. Make sure to read up on [[openbsd/tcpdump|tcpdump]].%0a%0aTo stop collection, type [ctrl]+c, @@^C@@. If you log for a few seconds and only receive a few hundred packets, perhaps you are '''not''' under attack. If, however, you see millions of packets arriving within a few seconds, you are certainly under attack. Save the pcap file because it is very useful for forensics. We will use it for reporting the attacker and for blocking his attacks.%0a%0aTo read the pcap, you can transfer the pcap to your desktop using [[openbsd/scp|scp]] or [[openbsd/sftp|sftp]]. Or, more quickly, you can analyze it on the server itself using tcpdump. Use the same options but replace -w with -r:%0a%0a[@%0a$ doas tcpdump -r YYYYMMDDSS.pcap%0a@]%0a%0aor%0a%0a[@%0a$ doas tcpdump -i vio0 -s 1500 -A -v -n -r YYYYMMDDSS.pcap%0a@]%0a%0a!! Identifying Attack Type%0a%0a|| border=1 width=100%25 class="sortable simpletable"%0a||! Common DDoS Attacks !||%0a||! Name ||! Packet Type ||! Description ||%0a|| [[openbsd/SYNFlood|SYN Flood]] || SYN packets || Your server sends ACK packets and wastes resources on useless TCP connections ||%0a|| [[openbsd/HTTPFlood|HTTP Flood]] || HTTP packets || Your server wastes resources responding to fake HTTP requests ||%0a|| [[openbsd/NTPAmplification|NTP Amplification]] || NTP packets || Your server is flooded with fake NTP packets ||%0a|| [[openbsd/UDPFlood|UDP Flood]] || UDP packets || Your server receives lots of fake UDP packets at random ports ||%0a|| [[openbsd/SSDP|SSDP Attacks]] || SSDP packets || Your server is flooded with packets from Universal Plug and Play (UPnP) devices ||%0a|| [[openbsd/ACKFlood|TCP ACK Flood]] || ACK packets || Your server is flooded with useless ACK packets ||%0a|| [[openbsd/RSTFlood|TCP RST Flood]] || RST packets || Your system daemons are tricked into disconnecting by fake RST (reset) packets ||%0a%0a!! Reporting Criminals%0a%0aTo stop abuse, it is necessary to report attackers. Often, a DDoSer can be quickly identified because an attack took place during an argument. A DDoSer may also be a competitor or have some other financial motive. If the pcap shows a specific IPv6 address was targeted, contact the user with that unique IPv6 address and ask him for clues. Attackers sometimes will show up on your channel to insult or mock you during an attack. This type of evidence, although not 100%25 certain, can provide clues as to who is behind an attack.%0a%0aHints provide a very useful starting point, but you will still need to do the necessary investigation in order to get enough evidence to report. Please see the [[openbsd/police|police guide]].%0a%0aKeep in mind that criminals often spoof IP addresses (lie about the source IP address) or use proxies (other insecure machines) to amplify their attacks. Logs of packets alone often do not provide enough evidence to report a criminal. Attackers often amplify their attacks using IoT devices, universities, and large corporations to mask their true origin. The attacking IP might be the stolen server, home computer, or electronic device of some innocent bystander.%0a%0a!! DDoS Filtering%0a%0aIf you are hosting a public service, sooner or later you will get hit with DDoS attacks. The Internet is full of criminals, and the anonymity of IRC makes it hard to catch them. Strong and determined attackers can sustain DDoS attacks of more than 500Gbps.%0a%0aA software firewall on a single server alone cannot stop all DDoS attacks because of physical limitations. Once the maximum bandwidth of your server is reached, it is unable to accept any further traffic. If you get attacked but you are not using a filtered IP, your provider will null route your IP (take it offline). So long as the attack continues, your service will be completely offline, and your users will blame you.%0a%0aAs a result, we are forced to purchase DDoS filtering or acquire more bandwidth. Both solutions cost money, which is why it is necessary to work as a team to purchase more bandwidth at a cheaper rate. The larger our network, the more money we can afford to spend on DDoS defenses. It is wise to avoid depending entirely upon one single internet provider like Cloudflare or Voxility. Using diverse providers decreases the risk of failure.%0a%0a!! Troubleshooting%0a%0aCloudflare/Voxility's DDoS protection can mangle SSL certs when you make requests from some servers. For example, I noticed HTTPS requests to Let's Encrypt's servers were being mangled: %0a%0a[@%0a$ openssl s_client -connect 172.65.32.248:443%0a@]%0a%0aIt just hung there with no certificate being issued. If this happens, you will need to report this to the Internet Provider ([[https://buyvm.net|BuyVM]]).%0a%0aDDoS filtered IPs have been known to mangle SMTP, NTP, and DNS packets. So if networking fails for some inexplicable reason, check using openssl to see if SSL certs are being mangled.
    12. 

  12. time=1622270163
    13. 

  13. title=DDoS Defense Guide
    14. 

  14. author:1622270163=mkf
    15. 

  15. csum:1622270163=a bit clean up.
    16. 

  16. diff:1622270163:1608201041:=10a11%0a> [12:33:04] *** Quits: Guest72019|dal (~comptech@2605:6400:30:f8de:f77b:2f96:6b1a:413e) (Quit: be right back... later... see yah...)%0a17c18%0a%3c [12:36:45] *** Quits: Soportes (Soportes@Soportes.fig.ircnow.org) ("IRCNow and Forever!")%0a---%0a> [12:36:45] *** Quits: Soportes (Soportes@Soportes.fig.ircnow.org) ("IRCNow and Forever!"%0a24c25%0a%3c If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/SSDP|SSDP attack]] or a [[openbsd/ACKFlood|TCP ack flood]]. Logging and analyzing incoming packets is how we identify the attack type.%0a---%0a> If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/SSDP|SSDP attack]] or a [[openbsd/tcpackflood|TCP ack flood]]. Logging and analyzing incoming packets is how we identify the attack type.%0a
    17. 

  17. host:1622270163=80.191.34.206
    18. 

  18. author:1608201041=jrmu
    19. 

  19. diff:1608201041:1608200964:=
    20. 

  20. host:1608201041=198.251.81.119
    21. 

  21. author:1608200964=jrmu
    22. 

  22. diff:1608200964:1608200824:=96,97d95%0a%3c || [[openbsd/ACKFlood|TCP ACK Flood]] || ACK packets || Your server is flooded with useless ACK packets ||%0a%3c || [[openbsd/RSTFlood|TCP RST Flood]] || RST packets || Your system daemons are tricked into disconnecting by fake RST (reset) packets ||%0a
    23. 

  23. host:1608200964=198.251.81.119
    24. 

  24. author:1608200824=jrmu
    25. 

  25. diff:1608200824:1608084217:=25c25%0a%3c If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/SSDP|SSDP attack]] or a [[openbsd/tcpackflood|TCP ack flood]]. Logging and analyzing incoming packets is how we identify the attack type.%0a---%0a> If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/ssdp|SSDP attack]] or a [[openbsd/tcpackflood|TCP ack flood]]. Logging and analyzing incoming packets is how we identify the attack type.%0a
    26. 

  26. host:1608200824=198.251.81.119
    27. 

  27. author:1608084217=jrmu
    28. 

  28. diff:1608084217:1608084131:=1,2d0%0a%3c (:title DDoS Defense Guide:)%0a%3c %0a
    29. 

  29. host:1608084217=198.251.81.119
    30. 

  30. author:1608084131=jrmu
    31. 

  31. diff:1608084131:1608083666:=84a85%0a> %0a
    32. 

  32. host:1608084131=198.251.81.119
    33. 

  33. author:1608083666=jrmu
    34. 

  34. diff:1608083666:1608083620:=92c92%0a%3c || [[openbsd/NTPAmplification|NTP Amplification]] || NTP packets || Your server is flooded with fake NTP packets ||%0a---%0a> || [[openbsd/NTPAmplification|NTP Amplification]] || NTP packets || || Your server is flooded with fake NTP packets ||%0a
    35. 

  35. host:1608083666=198.251.81.119
    36. 

  36. author:1608083620=jrmu
    37. 

  37. diff:1608083620:1608083519:=89c89%0a%3c ||! Name ||! Packet Type ||! Description ||%0a---%0a> ||! Name ||! Signs ||! Description ||%0a92c92%0a%3c || [[openbsd/NTPAmplification|NTP Amplification]] || NTP packets || || Your server is flooded with fake NTP packets ||%0a---%0a> || [[openbsd/NTPAmplification|NTP Amplification]] || Your server is flooded with fake NTP packets ||%0a94c94%0a%3c || [[openbsd/SSDP|SSDP Attacks]] || SSDP packets || Your server is flooded with packets from Universal Plug and Play (UPnP) devices ||%0a---%0a> || [[openbsd/SSDP|SSDP Attacks]] || || Your server is flooded with packets from Universal Plug and Play (UPnP) devices ||%0a
    38. 

  38. host:1608083620=198.251.81.119
    39. 

  39. author:1608083519=jrmu
    40. 

  40. diff:1608083519:1608036959:=91c91%0a%3c || [[openbsd/HTTPFlood|HTTP Flood]] || HTTP packets || Your server wastes resources responding to fake HTTP requests ||%0a---%0a> || [[openbsd/HTTPFlood|HTTP Flood|HTTP Flood]] || HTTP packets || Your server wastes resources responding to fake HTTP requests ||%0a
    41. 

  41. host:1608083519=198.251.81.119
    42. 

  42. author:1608036959=jrmu
    43. 

  43. diff:1608036959:1608034247:=94c94,96%0a%3c || [[openbsd/SSDP|SSDP Attacks]] || || Your server is flooded with packets from Universal Plug and Play (UPnP) devices ||%0a---%0a> || [[openbsd/SSDP|SSDP Attacks]] || || || ||%0a> %0a> An SSDP Attack%0a
    44. 

  44. host:1608036959=198.251.81.119
    45. 

  45. author:1608034247=jrmu
    46. 

  46. diff:1608034247:1608033164:=90,93c90,92%0a%3c || [[openbsd/SYNFlood|SYN Flood]] || SYN packets || Your server sends ACK packets and wastes resources on useless TCP connections ||%0a%3c || [[openbsd/HTTPFlood|HTTP Flood|HTTP Flood]] || HTTP packets || Your server wastes resources responding to fake HTTP requests ||%0a%3c || [[openbsd/NTPAmplification|NTP Amplification]] || Your server is flooded with fake NTP packets ||%0a%3c || [[openbsd/UDPFlood|UDP Flood]] || UDP packets || Your server receives lots of fake UDP packets at random ports ||%0a---%0a> || [[openbsd/SYNFlood|SYN Flood]] || SYN packets || This causes the server to send acknowledgment (ACK) packets and create TCP connections, tying up resources ||%0a> || [[openbsd/HTTPFlood|HTTP Flood|HTTP Flood]] || || ||%0a> || [[openbsd/NTPAmplification|NTP Amplification]] || || ||%0a94a94,111%0a> %0a> !!! SYN Flood%0a> %0a> A [[openbsd/SYNFlood|SYN Flood]] floods the server with %0a> %0a> !!! UDP Flood%0a> %0a> A [[openbsd/UDPFlood||UDP Flood]] sends lots of trash UDP packets at random ports on the servers.%0a> %0a> !!! HTTP Flood%0a> %0a> An [[openbsd/HTTPFlood|HTTP Flood]] sends HTTP requests to a server to waste as many resources as possible to cause the server to crash or freeze.%0a> %0a> !!! NTP Amplification%0a> %0a> In an [[openbsd/NTP Amplification]], the attacker spoofs your IP as the sending IP so that NTP servers flood you with packets%0a> %0a> !! SSDP Flood%0a
    47. 

  47. host:1608034247=198.251.81.119
    48. 

  48. author:1608033164=jrmu
    49. 

  49. diff:1608033164:1608031966:=86,113c86%0a%3c %0a%3c || border=1 width=100%25 class="sortable simpletable"%0a%3c ||! Common DDoS Attacks !||%0a%3c ||! Name ||! Signs ||! Description ||%0a%3c || [[openbsd/SYNFlood|SYN Flood]] || SYN packets || This causes the server to send acknowledgment (ACK) packets and create TCP connections, tying up resources ||%0a%3c || [[openbsd/HTTPFlood|HTTP Flood|HTTP Flood]] || || ||%0a%3c || [[openbsd/NTPAmplification|NTP Amplification]] || || ||%0a%3c || [[openbsd/SSDP|SSDP Attacks]] || || || ||%0a%3c %0a%3c !!! SYN Flood%0a%3c %0a%3c A [[openbsd/SYNFlood|SYN Flood]] floods the server with %0a%3c %0a%3c !!! UDP Flood%0a%3c %0a%3c A [[openbsd/UDPFlood||UDP Flood]] sends lots of trash UDP packets at random ports on the servers.%0a%3c %0a%3c !!! HTTP Flood%0a%3c %0a%3c An [[openbsd/HTTPFlood|HTTP Flood]] sends HTTP requests to a server to waste as many resources as possible to cause the server to crash or freeze.%0a%3c %0a%3c !!! NTP Amplification%0a%3c %0a%3c In an [[openbsd/NTP Amplification]], the attacker spoofs your IP as the sending IP so that NTP servers flood you with packets%0a%3c %0a%3c !! SSDP Flood%0a%3c %0a%3c An SSDP Attack%0a---%0a> SSDP packets are.%0a
    50. 

  50. host:1608033164=198.251.81.119
    51. 

  51. author:1608031966=jrmu
    52. 

  52. diff:1608031966:1608031325:=94,95c94,95%0a%3c Keep in mind that criminals often spoof IP addresses (lie about the source IP address) or use proxies (other insecure machines) to amplify their attacks. Logs of packets alone often do not provide enough evidence to report a criminal. Attackers often amplify their attacks using IoT devices, universities, and large corporations to mask their true origin. The attacking IP might be the stolen server, home computer, or electronic device of some innocent bystander.%0a%3c %0a---%0a> Keep in mind that criminals often spoof IP addresses (lie about the source IP address) or use proxies (other insecure machines) to amplify their attacks. Logs of packets alone often do not provide enough evidence to report a criminal. Attackers often amplify their attacks using IoT devices, universities, and large corporations to mask their true origin.%0a> %0a97,103c97,110%0a%3c %0a%3c If you are hosting a public service, sooner or later you will get hit with DDoS attacks. The Internet is full of criminals, and the anonymity of IRC makes it hard to catch them. Strong and determined attackers can sustain DDoS attacks of more than 500Gbps.%0a%3c %0a%3c A software firewall on a single server alone cannot stop all DDoS attacks because of physical limitations. Once the maximum bandwidth of your server is reached, it is unable to accept any further traffic. If you get attacked but you are not using a filtered IP, your provider will null route your IP (take it offline). So long as the attack continues, your service will be completely offline, and your users will blame you.%0a%3c %0a%3c As a result, we are forced to purchase DDoS filtering or acquire more bandwidth. Both solutions cost money, which is why it is necessary to work as a team to purchase more bandwidth at a cheaper rate. The larger our network, the more money we can afford to spend on DDoS defenses. It is wise to avoid depending entirely upon one single internet provider like Cloudflare or Voxility. Using diverse providers decreases the risk of failure.%0a%3c %0a---%0a> You will get hit with DDoS attacks. The Internet is full of criminals, and the free software world in particular because of the anonymity it affords attackers. DDoS attacks from script kiddies can easily reach 100Gbps, and strong and determined attackers can sustain attacks of more than 500Gbps.%0a> %0a> Firewalls cannot deal with DDoS attacks because of physical limitations. Imagine trying to squeeze 10 tons of water through a garden hose%0a> Changing IP addresses or ports does not help.%0a> You must get ddos filtering, which costs money. This is why it is necessary to unite.%0a> %0a> The attacker will steal zombie servers%0a> %0a> So, to resist, our network must grow large. The larger our network, the more money we can afford to get for ddos defenses.%0a> %0a> If you get ddosed but you are not using a filtered IP, your provider will null route your IP.%0a> %0a> It is wise to avoid depending entirely upon one vendor. Like many things in life, it is wise to diversify.%0a> %0a112c119%0a%3c It just hung there with no certificate being issued. If this happens, you will need to report this to the Internet Provider ([[https://buyvm.net|BuyVM]]).%0a---%0a> It just hunt there with no certificate being issued. If this happens, you will need to report this to the Internet Provider ([[https://buyvm.net|BuyVM]]).%0a
    53. 

  53. host:1608031966=198.251.81.119
    54. 

  54. author:1608031325=jrmu
    55. 

  55. diff:1608031325:1608031027:=90,94c90,94%0a%3c To stop abuse, it is necessary to report attackers. Often, a DDoSer can be quickly identified because an attack took place during an argument. A DDoSer may also be a competitor or have some other financial motive. If the pcap shows a specific IPv6 address was targeted, contact the user with that unique IPv6 address and ask him for clues. Attackers sometimes will show up on your channel to insult or mock you during an attack. This type of evidence, although not 100%25 certain, can provide clues as to who is behind an attack.%0a%3c %0a%3c Hints provide a very useful starting point, but you will still need to do the necessary investigation in order to get enough evidence to report. Please see the [[openbsd/police|police guide]].%0a%3c %0a%3c Keep in mind that criminals often spoof IP addresses (lie about the source IP address) or use proxies (other insecure machines) to amplify their attacks. Logs of packets alone often do not provide enough evidence to report a criminal. Attackers often amplify their attacks using IoT devices, universities, and large corporations to mask their true origin.%0a---%0a> To stop abuse, it is necessary to report attackers. Often, a DDoSer can be quickly identified because an attack took place during an argument. If the pcap shows a specific IPv6 address was targeted, look up the user with that unique IPv6 address and ask him for clues. Attackers sometimes will show up on your channel to insult or mock you during an attack. This type of evidence, although not 100%25 certain, can provide clues as to who is behind an attack.%0a> %0a> circums is not diff If you are unsure of who caused the  the criminals by providing conclusive evidence.%0a> %0a> Logging the packets, however, usually does not provide this evidence. That is because these skiddies rely on amplification attacks through universities and large corporations to mask their true origin.%0a
    56. 

  56. host:1608031325=198.251.81.119
    57. 

  57. author:1608031027=jrmu
    58. 

  58. diff:1608031027:1607931425:=86c86%0a%3c SSDP packets are.%0a---%0a> If you see hundreds of trash packets, like reflected dns packets or reflected http packets, you know it's a ddos attack%0a
    59. 

  59. host:1608031027=198.251.81.119
    60. 

  60. author:1607931425=jrmu
    61. 

  61. diff:1607931425:1607875463:=57c57%0a%3c $ doas tcpdump -w YYYYMMDDSS.pcap%0a---%0a> $ doas tcpdump -w flood.pcap%0a60,61c60,61%0a%3c This will log the packets onto the file @@YYYYMMDDSS.pcap@@, where YYYY is the year, MM is the month, DD is the day, and SS is the serial number.%0a%3c %0a---%0a> This will log the packets onto the file @@flood.pcap@@.%0a> %0a65c65%0a%3c $ doas tcpdump -i vio0 -s 1500 -A -v -n -w YYYYMMDDSS.pcap%0a---%0a> $ doas tcpdump -i vio0 -s 1500 -A -v -n -w flood.pcap%0a75c75%0a%3c $ doas tcpdump -r YYYYMMDDSS.pcap%0a---%0a> $ doas tcpdump -r flood.pcap%0a81c81%0a%3c $ doas tcpdump -i vio0 -s 1500 -A -v -n -r YYYYMMDDSS.pcap%0a---%0a> $ doas tcpdump -i vio0 -s 1500 -A -v -n -r flood.pcap%0a
    62. 

  62. host:1607931425=198.251.81.119
    63. 

  63. author:1607875463=jrmu
    64. 

  64. diff:1607875463:1607864786:=90,92c90%0a%3c To stop abuse, it is necessary to report attackers. Often, a DDoSer can be quickly identified because an attack took place during an argument. If the pcap shows a specific IPv6 address was targeted, look up the user with that unique IPv6 address and ask him for clues. Attackers sometimes will show up on your channel to insult or mock you during an attack. This type of evidence, although not 100%25 certain, can provide clues as to who is behind an attack.%0a%3c %0a%3c circums is not diff If you are unsure of who caused the  the criminals by providing conclusive evidence.%0a---%0a> One way to go after ddos attackers is to identify the criminals by providing conclusive evidence.%0a
    65. 

  65. host:1607875463=198.251.81.119
    66. 

  66. author:1607864786=jrmu
    67. 

  67. diff:1607864786:1607864687:=88,89c88,92%0a%3c !! Reporting Criminals%0a%3c %0a---%0a> %0a> You will get hit with DDoS attacks. The Internet is full of criminals, and the free software world in particular because of the anonymity it affords attackers. DDoS attacks from script kiddies can easily reach 100Gbps, and strong and determined attackers can sustain attacks of more than 500Gbps.%0a> %0a> Firewalls cannot deal with DDoS attacks because of physical limitations. Imagine trying to squeeze 10 tons of water through a garden hose%0a> %0a91a95%0a> %0a94,97c98%0a%3c !! DDoS Filtering%0a%3c You will get hit with DDoS attacks. The Internet is full of criminals, and the free software world in particular because of the anonymity it affords attackers. DDoS attacks from script kiddies can easily reach 100Gbps, and strong and determined attackers can sustain attacks of more than 500Gbps.%0a%3c %0a%3c Firewalls cannot deal with DDoS attacks because of physical limitations. Imagine trying to squeeze 10 tons of water through a garden hose%0a---%0a> %0a103a105,106%0a> %0a> %0a
    68. 

  68. host:1607864786=198.251.81.119
    69. 

  69. author:1607864687=jrmu
    70. 

  70. diff:1607864687:1607864508:=110a111,129%0a> %0a> %0a> %0a> The way you see if there is a ddos attack%0a> 18:11 %3c~jrmu> to be 100%25 sure, you run tcpdump%0a> 18:12 %3c~jrmu> $ doas tcpdump -s 1500 -A -v -w flood.pcap%0a> 18:12 %3c~jrmu> then ctrl+c to cancel%0a> 18:12 %3c~jrmu> err, type $ doas tcpdump -s 1500 -A -v -n -w flood.pcap%0a> 18:12 %3c~jrmu> then $ doas tcpdump -s 1500 -A -v -n -r flood.pcap%0a> 18:12 %3c~jrmu> that will let you read the pcap file%0a> 18:12 %3c~jrmu> and if you see hundreds of trash packets, like reflected dns packets or re:%0a> flected http packets, you know it's a ddos attack%0a> 18:16 %3c~jrmu> there are some ways to block the ddos attack%0a> 18:16 %3c~jrmu> for example yesterday we got hit on port 22%0a> 18:16 %3c~jrmu> so i blocked port 22%0a> 18:17 %3c~jrmu> you should study Packet Filter (PF)%0a> 18:17 %3c~jrmu> however, PF is not full proof%0a> 18:17 %3c~jrmu> it can only block attacks when the attacker is not using more sophisticated methods%0a> 18:17 %3c~jrmu> if he really hammered us hard, i would not have been able to block it in 20 mins%0a
    71. 

  71. host:1607864687=198.251.81.119
    72. 

  72. author:1607864508=jrmu
    73. 

  73. diff:1607864508:1607863865:=70,71c70,71%0a%3c To stop collection, type [ctrl]+c, @@^C@@. If you log for a few seconds and only receive a few hundred packets, perhaps you are '''not''' under attack. If, however, you see millions of packets arriving within a few seconds, you are certainly under attack. Save the pcap file because it is very useful for forensics. We will use it for reporting the attacker and for blocking his attacks.%0a%3c %0a---%0a> To stop collection, type [ctrl]+c, @@^C@@. Save the pcap file because it is very useful for forensics. We will use it for reporting the attacker and for blocking his attacks.%0a> %0a114a115,130%0a> %0a> $ ping on the ip address, you get 80-90%25 packet loss%0a> 18:10 %3c~jrmu> but some packets still go through%0a> 18:10 %3c~jrmu> then when you use the VNC web console, you can still see it, but it's slug%0a> gish%0a> 18:10 %3c~jrmu> when you run top, you see that system/interrupt CPU usage is through the r%0a> oof at 50%25 each%0a> 18:11 %3c~jrmu> then you can do this%0a> 18:11 %3c~jrmu> $ doas pfctl -f /etc/pf.conf%0a> 18:11 %3c~jrmu> that will empty the existing state tables for pf%0a> 18:11 %3c~jrmu> then, $ doas pfctl -sr -v%0a> 18:11 %3c~jrmu> that will show you how many packets are arriving%0a> 18:11 %3c~jrmu> since you emptied the state tables, if you now see 10000s of packets comin%0a> g in, those packets came in that second%0a> 18:11 %3c~jrmu> almost certainly due to an attack if you are getting 10,000s of packets in%0a>  a few seconds%0a
    74. 

  74. host:1607864508=198.251.81.119
    75. 

  75. author:1607863865=jrmu
    76. 

  76. diff:1607863865:1607863677:=88a89,99%0a> %0a> Cloudflare/Voxility's DDoS protection can mangle SSL certs from specific domains (I noticed them doing this for let's encrypt):%0a> %0a> %3ccode>%0a> $ openssl s_client -connect 172.65.32.248:443%0a> %3c/code>%0a> %0a> It just hangs there with no certificate being issued.%0a> %0a> Also DDoS has been known to mangle SMTP, NTP, and DNS packets. Watch out!%0a> %0a145,157c156%0a%3c 18:17 %3c~jrmu> if he really hammered us hard, i would not have been able to block it in 20 mins%0a%3c %0a%3c !! Troubleshooting%0a%3c %0a%3c Cloudflare/Voxility's DDoS protection can mangle SSL certs when you make requests from some servers. For example, I noticed HTTPS requests to Let's Encrypt's servers were being mangled: %0a%3c %0a%3c [@%0a%3c $ openssl s_client -connect 172.65.32.248:443%0a%3c @]%0a%3c %0a%3c It just hunt there with no certificate being issued. If this happens, you will need to report this to the Internet Provider ([[https://buyvm.net|BuyVM]]).%0a%3c %0a%3c DDoS filtered IPs have been known to mangle SMTP, NTP, and DNS packets. So if networking fails for some inexplicable reason, check using openssl to see if SSL certs are being mangled.%0a\ No newline at end of file%0a---%0a> 18:17 %3c~jrmu> if he really hammered us hard, i would not have been able to block it in 20 mins%0a\ No newline at end of file%0a
    77. 

  77. host:1607863865=198.251.81.119
    78. 

  78. author:1607863677=jrmu
    79. 

  79. diff:1607863677:1607863428:=21,22c21,22%0a%3c !! Different Attack Types%0a%3c %0a---%0a> !! Identifying the Attack Type%0a> %0a40,41d39%0a%3c !! Confirming an Attack%0a%3c %0a84,85d81%0a%3c !! Identifying Attack Type%0a%3c %0a88a85,86%0a> %0a> ----%0a
    80. 

  80. host:1607863677=198.251.81.119
    81. 

  81. author:1607863428=jrmu
    82. 

  82. diff:1607863428:1607862971:=
    83. 

  83. host:1607863428=198.251.81.119
    84. 

  84. author:1607862971=jrmu
    85. 

  85. diff:1607862971:1607862628:=23,25c23,25%0a%3c If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/ssdp|SSDP attack]] or a [[openbsd/tcpackflood|TCP ack flood]]. Logging and analyzing incoming packets is how we identify the attack type.%0a%3c %0a%3c If you see many @@EOF from client@@, @@Read error: Input/output error@@, or @@Client closed connection@@ quit messages, this may be due to a [[openbsd/tcpresetflood|TCP reset flood]]:%0a---%0a> If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/ssdp|SSDP attack]] or a [[openbsd/tcpackflood|TCP ack flood]].%0a> %0a> A [[openbsd/tcpresetflood|TCP reset flood]].%0a
    86. 

  86. host:1607862971=198.251.81.119
    87. 

  87. author:1607862628=jrmu
    88. 

  88. diff:1607862628:1607862540:=23,25c23%0a%3c If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a [[openbsd/ssdp|SSDP attack]] or a [[openbsd/tcpackflood|TCP ack flood]].%0a%3c %0a%3c A [[openbsd/tcpresetflood|TCP reset flood]].%0a---%0a> If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a SSDP%0a
    89. 

  89. host:1607862628=198.251.81.119
    90. 

  90. author:1607862540=jrmu
    91. 

  91. diff:1607862540:1607862368:=21,24c21,22%0a%3c !! Identifying the Attack Type%0a%3c %0a%3c If you see ping timeouts like above, your server's bandwidth is clogged with so many junk packets that it cannot respond to real traffic. This could be the result of a SSDP%0a%3c %0a---%0a> To see if there is a ddos attack, first run:%0a> %0a26,35c24%0a%3c [02:02:42] *** Quits: jrmu|dal (jrmu@jrmu.plum.ircnow.org) (Read error: Input/output error)%0a%3c [02:02:42] *** Quits: semut_|dal (semut@semut.lu2.ircnow.org) (Client closed connection)%0a%3c [02:02:42] *** Quits: starr|dal (starr@starr.lu2.ircnow.org) (Read error: Input/output error)%0a%3c [02:02:42] *** Quits: Gisa|dal (thekingofb@thekingofbandit.lu2.ircnow.org) (Read error: Input/output error)%0a%3c [02:02:42] *** Quits: Gisa|quake (thekingofb@lu2.ircnow.org) (EOF from client)%0a%3c [02:02:42] *** Quits: Freak|quake (Freak@Freak.lu2.ircnow.org) (EOF from client)%0a%3c [02:02:42] *** Quits: IRCuser|quake (unknwon@IRCuser.users.quakenet.org) (EOF from client)%0a%3c [02:02:42] *** Quits: ramadi|quake (ramadi@ramadi.lu2.ircnow.org) (EOF from client)%0a%3c [02:02:43] *** Quits: Fat1 (Fatfem@Fatfem.lu2.ircnow.org) (Client closed connection)%0a%3c [02:02:43] *** Quits: Freak (Freak@Freak.lu2.ircnow.org) (Client closed connection)%0a---%0a> $ ping fruit.ircnow.org%0a38,43d26%0a%3c To see if there is a ddos attack, first run:%0a%3c %0a%3c [@%0a%3c $ ping fruit.ircnow.org%0a%3c @]%0a%3c %0a82,83d64%0a%3c %0a%3c %0a118a100,111%0a> [@%0a> [02:02:42] *** Quits: jrmu|dal (jrmu@jrmu.plum.ircnow.org) (Read error: Input/output error)%0a> [02:02:42] *** Quits: semut_|dal (semut@semut.lu2.ircnow.org) (Client closed connection)%0a> [02:02:42] *** Quits: starr|dal (starr@starr.lu2.ircnow.org) (Read error: Input/output error)%0a> [02:02:42] *** Quits: Gisa|dal (thekingofb@thekingofbandit.lu2.ircnow.org) (Read error: Input/output error)%0a> [02:02:42] *** Quits: Gisa|quake (thekingofb@lu2.ircnow.org) (EOF from client)%0a> [02:02:42] *** Quits: Freak|quake (Freak@Freak.lu2.ircnow.org) (EOF from client)%0a> [02:02:42] *** Quits: IRCuser|quake (unknwon@IRCuser.users.quakenet.org) (EOF from client)%0a> [02:02:42] *** Quits: ramadi|quake (ramadi@ramadi.lu2.ircnow.org) (EOF from client)%0a> [02:02:43] *** Quits: Fat1 (Fatfem@Fatfem.lu2.ircnow.org) (Client closed connection)%0a> [02:02:43] *** Quits: Freak (Freak@Freak.lu2.ircnow.org) (Client closed connection)%0a> @]%0a
    92. 

  92. host:1607862540=198.251.81.119
    93. 

  93. author:1607862368=jrmu
    94. 

  94. diff:1607862368:1607862248:=51,52c51,52%0a%3c To read the pcap, you can transfer the pcap to your desktop using [[openbsd/scp|scp]] or [[openbsd/sftp|sftp]]. Or, more quickly, you can analyze it on the server itself using tcpdump. Use the same options but replace -w with -r:%0a%3c %0a---%0a> To read the pcap, you can transfer the pcap to your desktop using [[openbsd/scp|scp]] or [[openbsd/sftp|sftp]]. Or, more quickly, you can analyze it on the server itself using tcpdump:%0a> %0a54,60c54%0a%3c $ doas tcpdump -r flood.pcap%0a%3c @]%0a%3c %0a%3c or%0a%3c %0a%3c [@%0a%3c $ doas tcpdump -i vio0 -s 1500 -A -v -n -r flood.pcap%0a---%0a> $ doas tcpdump -s 1500 -A -v -n -r flood.pcap%0a
    95. 

  95. host:1607862368=198.251.81.119
    96. 

  96. author:1607862248=jrmu
    97. 

  97. diff:1607862248:1607862098:=51c51%0a%3c To read the pcap, you can transfer the pcap to your desktop using [[openbsd/scp|scp]] or [[openbsd/sftp|sftp]]. Or, more quickly, you can analyze it on the server itself using tcpdump:%0a---%0a> To read the pcap:%0a
    98. 

  98. host:1607862248=198.251.81.119
    99. 

  99. author:1607862098=jrmu
    100. 

  100. diff:1607862098:1607860911:=33,53c33,55%0a%3c If you suspect an attack, you should log the packets that are coming in:%0a%3c %0a%3c [@%0a%3c $ doas tcpdump -w flood.pcap%0a%3c @]%0a%3c %0a%3c This will log the packets onto the file @@flood.pcap@@.%0a%3c %0a%3c You can fine-tune this:%0a%3c %0a%3c [@%0a%3c $ doas tcpdump -i vio0 -s 1500 -A -v -n -w flood.pcap%0a%3c @]%0a%3c %0a%3c In the above command, the argument -i specifies the interface @@vio0@@, -s 1500 analyzes the first 1500 bytes, -A prints each packet in ASCII, -v provides more verbose output, and -n avoids address conversion. Make sure to read up on [[openbsd/tcpdump|tcpdump]].%0a%3c %0a%3c To stop collection, type [ctrl]+c, @@^C@@. Save the pcap file because it is very useful for forensics. We will use it for reporting the attacker and for blocking his attacks.%0a%3c %0a%3c To read the pcap:%0a%3c %0a%3c [@%0a---%0a> Next, run this command:%0a> %0a> %3ccode>%0a> $ doas pfctl -f /etc/pf.conf%0a> %3c/code>%0a> %0a> This will empty the existing state tables for pf. Then, run%0a> %0a> %3ccode>%0a> $ doas pfctl -sr -v%0a> %3c/code>%0a> %0a> This will show you how many packets are arriving. Since you emptied the state tables, if you now see 1000s of packets coming in, those packets came in the last few seconds, indicating that you are certainly under attack.%0a> %0a> To analyze the types of packets, use tcpdump:%0a> %0a> %3ccode>%0a> $ doas tcpdump -s 1500 -A -v -n -w flood.pcap%0a> %3c/code>%0a> %0a> To stop collection, type ctrl+c. Make sure to save the pcap file because it is very useful for forensics and for learning how to block attacks. Then, to read the pcap:%0a> %0a> %3ccode>%0a55c57%0a%3c @]%0a---%0a> %3c/code>%0a
    101. 

  101. host:1607862098=198.251.81.119
    102. 

  102. author:1607860911=jrmu
    103. 

  103. diff:1607860911:1607858492:=21,31c21,29%0a%3c To see if there is a ddos attack, first run:%0a%3c %0a%3c [@%0a%3c $ ping fruit.ircnow.org%0a%3c @]%0a%3c %0a%3c Replace fruit.ircnow.org with your actual server's hostname. If you get more than 30%25 packet loss, this could be a sign you are being flooded with fake packets. During a DDoS, an attacker is flooding your internet pipe with junk packets so that your server is unable to respond to any real network traffic.%0a%3c %0a%3c Check the serial console (using [[openbsd/cu|cu]] if on [[openbsd/vmmuser|VMM]], VNC if on [[openbsd/buyvm|BuyVM]]). Try to log in and see if the system is still responsive. If the server is offline or has errors, it may be due to hardware/software issues rather than a DDoS attack.%0a%3c %0a%3c During a DDoS attack, your system should feel slightly sluggish. This is due to the massive number of packets that OpenBSD must process. Run @@top@@. If you see the system/interrupt CPU usage at 50%25 or more, then you either have a process using too much CPU or you may be under an attack. If the CPU usage is low, under 5%25, it might not be a DDoS attack. It could be a networking or hardware issue, or an attack of another nature.%0a---%0a> To see if there is a ddos attack, first run%0a> %0a> %3ccode>%0a> $ ping example.com%0a> %3c/code>%0a> %0a> on your hostname. If you get 80-90%25 packet loss, but some packets still go through, you may have a DDoS attack. The packets in this case are mostly flooding your internet pipe but some are able to pass through. However, if you get 100%25 packet loss, it could simply be a networking mistake.%0a> %0a> Check your VNC web console if it can still load. If it feels sluggish, run top. If you see the system/interrupt CPU usage shoot up to 50%25 each, for a total of almost 100%25 cpu usage, then either you have a runaway process or you are being DDoSed. If your CPU usage is low, under 5%25, it does not look like a DDoS attack.%0a
    104. 

  104. host:1607860911=198.251.81.119
    105. 

  105. author:1607858492=jrmu
    106. 

  106. diff:1607858492:1597226351:=1,20c1,4%0a%3c !! How to Detect an Attack%0a%3c %0a%3c If suddenly you see many users disconnect from a server...%0a%3c %0a%3c [@%0a%3c [12:31:23] *** Quits: Lucifer_|des (JohnReb@AEJva.DesireNET.Org) (Ping timeout)%0a%3c [12:31:51] *** Quits: depeche|nat (depeche@depeche.users.nationchat.org) (Ping timeout)%0a%3c [12:32:36] *** Quits: iulian7502|des (iulian@ADx0-.DesireNET.Org) (Ping timeout)%0a%3c [12:33:04] *** Quits: Guest72019|dal (~comptech@2605:6400:30:f8de:f77b:2f96:6b1a:413e) (Quit: be right back... later... see yah...)%0a%3c [12:34:07] *** Quits: Counter|under (CPT@CPT.fig.ircnow.org) (Ping timeout)%0a%3c [12:34:12] *** Quits: katrok|quake (katrok@katrok.bnc1.ircnow.org) (Ping timeout)%0a%3c [12:34:19] *** Quits: Lucifer|des (Lucifer@ACXJz.DesireNET.Org) (Ping timeout)%0a%3c [12:35:29] *** Quits: depeche|quake (depeche@depeche.users.quakenet.org) (Ping timeout)%0a%3c [12:35:38] *** Quits: Elafi|under (Elafi@Elafi.fig.ircnow.org) (Ping timeout)%0a%3c [12:35:52] *** Quits: edu|dal (ed@fig.ircnow.org) (Ping timeout)%0a%3c [12:36:45] *** Quits: Soportes (Soportes@Soportes.fig.ircnow.org) ("IRCNow and Forever!"%0a%3c @]%0a%3c %0a%3c ...your server may be under attack!%0a%3c %0a---%0a> %0a> ====== Under Attack? ======%0a> %0a> %0a93,105d76%0a%3c %0a%3c [@%0a%3c [02:02:42] *** Quits: jrmu|dal (jrmu@jrmu.plum.ircnow.org) (Read error: Input/output error)%0a%3c [02:02:42] *** Quits: semut_|dal (semut@semut.lu2.ircnow.org) (Client closed connection)%0a%3c [02:02:42] *** Quits: starr|dal (starr@starr.lu2.ircnow.org) (Read error: Input/output error)%0a%3c [02:02:42] *** Quits: Gisa|dal (thekingofb@thekingofbandit.lu2.ircnow.org) (Read error: Input/output error)%0a%3c [02:02:42] *** Quits: Gisa|quake (thekingofb@lu2.ircnow.org) (EOF from client)%0a%3c [02:02:42] *** Quits: Freak|quake (Freak@Freak.lu2.ircnow.org) (EOF from client)%0a%3c [02:02:42] *** Quits: IRCuser|quake (unknwon@IRCuser.users.quakenet.org) (EOF from client)%0a%3c [02:02:42] *** Quits: ramadi|quake (ramadi@ramadi.lu2.ircnow.org) (EOF from client)%0a%3c [02:02:43] *** Quits: Fat1 (Fatfem@Fatfem.lu2.ircnow.org) (Client closed connection)%0a%3c [02:02:43] *** Quits: Freak (Freak@Freak.lu2.ircnow.org) (Client closed connection)%0a%3c @]%0a
    107. 

  107. host:1607858492=198.251.81.119
    108. 

  108. author:1597226351=jrmu
    109. 

  109. diff:1597226351:1597226351:=1,110d0%0a%3c %0a%3c ====== Under Attack? ======%0a%3c %0a%3c %0a%3c To see if there is a ddos attack, first run%0a%3c %0a%3c %3ccode>%0a%3c $ ping example.com%0a%3c %3c/code>%0a%3c %0a%3c on your hostname. If you get 80-90%25 packet loss, but some packets still go through, you may have a DDoS attack. The packets in this case are mostly flooding your internet pipe but some are able to pass through. However, if you get 100%25 packet loss, it could simply be a networking mistake.%0a%3c %0a%3c Check your VNC web console if it can still load. If it feels sluggish, run top. If you see the system/interrupt CPU usage shoot up to 50%25 each, for a total of almost 100%25 cpu usage, then either you have a runaway process or you are being DDoSed. If your CPU usage is low, under 5%25, it does not look like a DDoS attack.%0a%3c %0a%3c Next, run this command:%0a%3c %0a%3c %3ccode>%0a%3c $ doas pfctl -f /etc/pf.conf%0a%3c %3c/code>%0a%3c %0a%3c This will empty the existing state tables for pf. Then, run%0a%3c %0a%3c %3ccode>%0a%3c $ doas pfctl -sr -v%0a%3c %3c/code>%0a%3c %0a%3c This will show you how many packets are arriving. Since you emptied the state tables, if you now see 1000s of packets coming in, those packets came in the last few seconds, indicating that you are certainly under attack.%0a%3c %0a%3c To analyze the types of packets, use tcpdump:%0a%3c %0a%3c %3ccode>%0a%3c $ doas tcpdump -s 1500 -A -v -n -w flood.pcap%0a%3c %3c/code>%0a%3c %0a%3c To stop collection, type ctrl+c. Make sure to save the pcap file because it is very useful for forensics and for learning how to block attacks. Then, to read the pcap:%0a%3c %0a%3c %3ccode>%0a%3c $ doas tcpdump -s 1500 -A -v -n -r flood.pcap%0a%3c %3c/code>%0a%3c %0a%3c If you see hundreds of trash packets, like reflected dns packets or reflected http packets, you know it's a ddos attack%0a%3c %0a%3c ----%0a%3c %0a%3c Cloudflare/Voxility's DDoS protection can mangle SSL certs from specific domains (I noticed them doing this for let's encrypt):%0a%3c %0a%3c %3ccode>%0a%3c $ openssl s_client -connect 172.65.32.248:443%0a%3c %3c/code>%0a%3c %0a%3c It just hangs there with no certificate being issued.%0a%3c %0a%3c Also DDoS has been known to mangle SMTP, NTP, and DNS packets. Watch out!%0a%3c %0a%3c You will get hit with DDoS attacks. The Internet is full of criminals, and the free software world in particular because of the anonymity it affords attackers. DDoS attacks from script kiddies can easily reach 100Gbps, and strong and determined attackers can sustain attacks of more than 500Gbps.%0a%3c %0a%3c Firewalls cannot deal with DDoS attacks because of physical limitations. Imagine trying to squeeze 10 tons of water through a garden hose%0a%3c %0a%3c One way to go after ddos attackers is to identify the criminals by providing conclusive evidence.%0a%3c %0a%3c %0a%3c Logging the packets, however, usually does not provide this evidence. That is because these skiddies rely on amplification attacks through universities and large corporations to mask their true origin.%0a%3c %0a%3c %0a%3c Changing IP addresses or ports does not help.%0a%3c You must get ddos filtering, which costs money. This is why it is necessary to unite.%0a%3c %0a%3c The attacker will steal zombie servers%0a%3c %0a%3c So, to resist, our network must grow large. The larger our network, the more money we can afford to get for ddos defenses.%0a%3c %0a%3c %0a%3c %0a%3c If you get ddosed but you are not using a filtered IP, your provider will null route your IP.%0a%3c %0a%3c It is wise to avoid depending entirely upon one vendor. Like many things in life, it is wise to diversify.%0a%3c %0a%3c %0a%3c The way you see if there is a ddos attack%0a%3c %0a%3c $ ping on the ip address, you get 80-90%25 packet loss%0a%3c 18:10 %3c~jrmu> but some packets still go through%0a%3c 18:10 %3c~jrmu> then when you use the VNC web console, you can still see it, but it's slug%0a%3c gish%0a%3c 18:10 %3c~jrmu> when you run top, you see that system/interrupt CPU usage is through the r%0a%3c oof at 50%25 each%0a%3c 18:11 %3c~jrmu> then you can do this%0a%3c 18:11 %3c~jrmu> $ doas pfctl -f /etc/pf.conf%0a%3c 18:11 %3c~jrmu> that will empty the existing state tables for pf%0a%3c 18:11 %3c~jrmu> then, $ doas pfctl -sr -v%0a%3c 18:11 %3c~jrmu> that will show you how many packets are arriving%0a%3c 18:11 %3c~jrmu> since you emptied the state tables, if you now see 10000s of packets comin%0a%3c g in, those packets came in that second%0a%3c 18:11 %3c~jrmu> almost certainly due to an attack if you are getting 10,000s of packets in%0a%3c  a few seconds%0a%3c 18:11 %3c~jrmu> to be 100%25 sure, you run tcpdump%0a%3c 18:12 %3c~jrmu> $ doas tcpdump -s 1500 -A -v -w flood.pcap%0a%3c 18:12 %3c~jrmu> then ctrl+c to cancel%0a%3c 18:12 %3c~jrmu> err, type $ doas tcpdump -s 1500 -A -v -n -w flood.pcap%0a%3c 18:12 %3c~jrmu> then $ doas tcpdump -s 1500 -A -v -n -r flood.pcap%0a%3c 18:12 %3c~jrmu> that will let you read the pcap file%0a%3c 18:12 %3c~jrmu> and if you see hundreds of trash packets, like reflected dns packets or re:%0a%3c flected http packets, you know it's a ddos attack%0a%3c 18:16 %3c~jrmu> there are some ways to block the ddos attack%0a%3c 18:16 %3c~jrmu> for example yesterday we got hit on port 22%0a%3c 18:16 %3c~jrmu> so i blocked port 22%0a%3c 18:17 %3c~jrmu> you should study Packet Filter (PF)%0a%3c 18:17 %3c~jrmu> however, PF is not full proof%0a%3c 18:17 %3c~jrmu> it can only block attacks when the attacker is not using more sophisticated methods%0a%3c 18:17 %3c~jrmu> if he really hammered us hard, i would not have been able to block it in 20 mins%0a\ No newline at end of file%0a
    110. 

  110. host:1597226351=38.81.163.143
    111. 

  111.