Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Something (Someone) is sending out UDP packets sent from our whole ip range. This seems to be multicast DNS.

Our server host provided this (Our IP Address is masked with XX):

Jun 3 11:02:13 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53
Jun 3 11:02:23 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53
Jun 3 11:02:32 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53
Jun 3 11:02:35 webserver kernel: Firewall: *UDP_IN Blocked* IN=eth0 OUT=
MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX
DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353
DPT=5353 LEN=53

I checked my /var/log/auth.log file and found out that someone from China (Using ip-locator) was trying to get in to the server using ssh.

...
Jun  3 11:32:00 server2 sshd[28511]: Failed password for root from 202.100.108.25 port 39047 ssh2
Jun  3 11:32:08 server2 sshd[28514]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.100.108.25  user=root
Jun  3 11:32:09 server2 sshd[28514]: Failed password for root from 202.100.108.25 port 39756 ssh2
Jun  3 11:32:16 server2 sshd[28516]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.100.108.25  user=root
...

I have blocked that IP address using this command: sudo iptables -A INPUT -s 202.100.108.25 -j DROP

However, I have no clue about the UDP multicasting, what is doing this? who is doing it? and how I can stop it?

Anyone know?

share|improve this question
    
You'll have to give us more context, such as where the "webserver kernel: Firewall" system is in relation to your server, and on which side it is receiving the multicast, from your system or the Internet? If it is a firewall between your system and the Net, and the UDB MC is coming from the Net, it is doing its job and you can forget about it. –  kmarsh Jun 3 '10 at 15:21
    
<killer tomato theme>ATTACK OF THE KILLER UBUNTUS</killer tomato theme> –  Jordan Eunson Jun 3 '10 at 15:28
    
The UDP packets are originating from our server multicasted to the same network. The firewall log is of the 'victim' and my server host provider just emailed that their client is receiving this: Jun 3 11:02:13 webserver kernel: Firewall: UDP_IN Blocked IN=eth0 OUT=MAC=01:00:5e:00:00:fb:00:30:48:94:46:c4:08:00 SRC=193.23X.21X.XX –  saky Jun 3 '10 at 15:49
1  
If you installed the desktop version of Ubuntu the 5353 stuff is almost certainly avahi. You can permit the traffic or remove avahi and the messages will go away. Aside from cluttering the logs it isn't that harmful. –  Zoredache Jun 3 '10 at 16:16

3 Answers 3

Frankly, why bother? Most servers get hundreds of scans and login attempts per day. It's simply impossible to manually block them all.

Your firewall seems to be doing it's job. After all it's blocking the unwanted traffic.

Make sure you don't run any unneeded services. The fewer there is available, the fewer there is to break into.

To secure SSH: Make sure you configure SSH to deny login by root. Verify that the passwords of all SSH accounts are strong. Denyhosts will automatically block IP's after a few failed login attempts (very useful), but make sure you whitelist your own IP range or you'll risk being locked out yourself. Also very effective is to run SSH on a different port, since most attacks only try port 22.

I would only take action when it's affecting your services or bandwidth. Check whois for the owner of the netblock from which the traffic is coming, and provide a clear and friendly complaint to the owner's Abuse address. If they don't reply in a reasonable time, go to their ISP, etc.

share|improve this answer
    
The UDP packets are originating from our server multicasted to the same network. The firewall log is of the 'victim' and my server host provider just told us that. –  saky Jun 3 '10 at 15:47
    
The Denyhost solution sounds good. Thanks. –  saky Jun 3 '10 at 15:49

There's not much you can do about stopping a 3rd party spoofing your IP address - its like spam with your From address. All that can be done may already be done with your ISP's filewall in front of your machine.

You can more easily block ssh-login attempts though. Denyhosts (which I use on all my servers), or the similar fail2ban (not just SSH) both scan logfile(s) and after 'too many' attempts to login, will block the IP address (I usually just do as DenyHosts does, and add IP addresses to /etc/hosts.deny)

share|improve this answer
    
If thats the case that some one is spoofing the IP address, then its much of a relief. Although, its the Server Host Provider who sent us an email with the above message that one of their client's firewall caught those message. If its not our server, then the culprit seems to be on the same network. Denyhosts sounds good. Thanks –  saky Jun 3 '10 at 15:56

UDP is easy to spoof source address on, packets could be coming from anywhere. Someone could be forging a packet to your broadcast address. Filter port 5353 incoming and outgoing, multicast DNS should be local. Filter the broadcast address on your firewall. Filter outgoing traffic to the the target address to ensure you aren't the one sending the traffic.

This looks suspiciously like the amplification attacks which where run on DNS last year. Those were done by forging the source address. If this is the case you are the real target.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.