0

I am working on a UDP honeypot, and currently it is for DNS Amplification. The end goal is to detect the new URL's attackers are using to query to report to the appropriate entities to have handled to prevent major attacks (I chose DNS currently because it is the most sustainable high-bandwidth attack currently around. It has been here for a long time, and can produce upwards of 450x the bandwidth used from an attackers server). I am having an issue though... My server which is hosting this is receiving lots of packets from source ip 127.0.0.1. This isn't an issue in terms of it harming my server, but it is filling my logs with useless data. Here is my code:

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <pthread.h>

#include <arpa/inet.h>

#include <netinet/ip.h>
#include <netinet/udp.h>
#include <netinet/ether.h>

int main() {
    FILE *log;
    log = fopen("/var/www/html/37810/index.html", "a+");
        int listener_socket = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
        if(listener_socket < 0) {
                printf("Could not open raw socket\n");
                exit(0);
        }
        unsigned char *receive_buffer = (unsigned char *)malloc(65536);
        while(1) {
        socklen_t data_size;
        data_size = recvfrom(listener_socket, receive_buffer, 65536, 0, NULL, NULL);
                if(data_size < 0) {
                        printf("Receive error\n");
                        exit(0);
                }
        struct iphdr *iph = (struct iphdr*)(receive_buffer + 14);
                if(iph->protocol == 17) {
                        u_int16_t iphdrlen = iph->ihl*4;
                        struct udphdr *udph = (struct udphdr*)(receive_buffer + 14 + iphdrlen);
            struct in_addr addr;
            addr.s_addr = iph->saddr;
            int hours, minutes, seconds, day, month, year;
            time_t now;
            time(&now);
            struct tm *local = localtime(&now);
            hours = local->tm_hour;
            minutes = local->tm_min;
                seconds = local->tm_sec;
                day = local->tm_mday;
                month = local->tm_mon + 1;
                year = local->tm_year + 1900;
 if(iph->saddr == "127.0.0.1") {
 }else{
   if(ntohs(udph->dest) == 37810) {
            fprintf(log, "UDP Probe Received: %02d/%02d/%d", month, day, year);
            fprintf(log, " %02d:%02d:%02d | ", hours, minutes, seconds);
                        fprintf(log, "Source IP: %s | Destination Port: %u | Payload Length: %i | UDP Payload: ", inet_ntoa(addr), ntohs(udph->dest), (data_size - 14) - iphdrlen - 8);
                            for(int i = 14 + iphdrlen + 8; i < data_size; i++) {
                                        fprintf(log, "\%02hhX", receive_buffer[i]);
                          }
                        fprintf(log, "<br>\n");
            fflush(log);
                }
        }
   }
 }
    return 0;
}

I have tried changing the if statement to all combinations of the following:

iph->saddr/inet_ntoa(addr)/addr.s_addr 

!= "127.0.0.1"/ == "127.0.0.1") {
}else{

I am not sure what I have done incorrectly, but source ip 127.0.0.1 is still flooding my honeypot. Thank you for any help!

Edit: So after updating my code to use strcmp rather than comparing a string to a number, it works BUT it now uses 50% of my VPS's cpu. I am not sure if I did something wrong, but it is currently OK, until I decide to run it for more ports as well. Thank you!

Note: the code is not mine, I have tweaked some things of it, the original code is found here: https://github.com/shishohf/udp-honeypot

Curious Cat 777
  • 1
  • 1
  • You are comparing a numerical address to a text string representing an address. That's not going to work. For one thing, "127.0.0.1" contains the dot character in it. And `saddr` doesn't since it's a number. – David Schwartz Jul 19 '21 at 00:11
  • @kaylum yes that does! that appears to have solved the issue. I had not realized that my comparing was comparing a string to a number. I thought Saddr and addr = a string, not a number. Thank you! – Curious Cat 777 Jul 19 '21 at 00:20
  • @DavidSchwartz Also, thank you for pointing that out. The post recommended before explained that, but did not point it out so plainly. – Curious Cat 777 Jul 19 '21 at 00:20

0 Answers0