[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 319
  • Last Modified:

Linux iptables firewall - UDP questions

I'm  securing my linux machine and have properly restriced TCP and ICMP.  Only incoming requests from specific machines are accepted, the machine looks like it doesn't exist to everyone else.  I have a question regarding UDP though.  Can UDP give you away?  I currently have it setup to ACCEPT all incoming and outgoing UDP packets b/c I don't understand them well enough to restrict them.  I know they're used for DNS, Time, Etc, but if I'm not running a DNS or Time server, what could a remote machine learn about me by sending me UDP packets?

From what I've read, it appears that UDP requests are just dropped unless they're sent to a running service that's setup to respond.  If this is true, no services = no responses making UDP filtering unnecessary.  Is that right? or am I missing something?
0
philjones85
Asked:
philjones85
  • 5
  • 3
1 Solution
 
rafael_accCommented:
As long as the service implementing that UDP port number is not working, it is the same as the port being closed.
However, using iptables you could set it up to accept only UDP from machines you trust ...

Cheers
0
 
prueconsultingCommented:
As well UDP can be a dead giveaway for alot of "firewall" products. Alot of the personal firewalls simply accept UDP packets and do not respond properly therefore showing to a scanner as all UDP ports open.. Dead giveaway about a machine

However I would simply just throw in a rule such as rafael mentioned

ie Assuming trusted lan is 192.168.0.x

Iptables -A blah -p udp -s 192.168.0.0/24 -j Accept
Iptables -A blah -p udp -j DROP
0
 
philjones85Author Commented:
i'm not running a pre-made "personal firewall" software app, i'm coding this by hand in vi using iptables, its a very basic 60-70 line firewall.  

"Alot of the personal firewalls simply accept UDP packets and do not respond properly therefore showing to a scanner as all UDP ports open"
what do you mean "do not respond properly"?  i didn't think UDP packets were responded to at all?  how would a non-response indicate anything?  this is what i'm confused about


0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
rafael_accCommented:
When there is an app listening on a specific UDP port, according to how that port is protected by your firewall, that app might respond or not to the "client" (attacker's, scanner's) request. As long a there is no app making use of specific udp ports, you dont really have much to worry about.

A very good site to check how open you are to attackers is www.grc.com (shield up) section.

Cheers
0
 
philjones85Author Commented:
i don't see how to check UDP through grc.com

"When there is an app listening on a specific UDP port, according to how that port is protected by your firewall, that app might respond or not to the "client" (attacker's, scanner's) request."
so the OS (linux) doesn't respond to random UDP requests like it does to TCP requests?  they're just dropped?
0
 
rafael_accCommented:
Ok ... let's clarify this ...

What do you actually mean by random responses? Can you give a specific example?

As far as I understand you are concened about security when it comes to port scanning. Both Linux and Windows, or any other OS (that works with the tcp/ip stack), reacts based on the same principle which is the one I explained above and I will explain again:

When your computer is configured as a server, it will listen on a specific port. It is just the way TCP/IP Stack works. Now, say a port scanning utility/application scans *randomly* or a list of specific ports, your server will not respond to that scanner unless there is an application "listening" on that port. Further more, once the scanner application gets a response on a port, that port will be declared "open" and therefore a potential attack destination.

Example: Say you have a server with App1 listening on port 10, app2 listening on port 50. Let's suppose I'm an attacker ... So I will lunch a port scan on your IP address and decide to scan ports 0 to 6500. Since you have two your server listenting on ports 10 and 50, my scanner will detect that (because what the scanner does is an attempt to connect to that port and your server would accept the request since it doesn't know this is a port scanner request - it will assume it is  legitimate request) and assume the port is open and therefore I could try and connect to it ....

Now, the attack wouldn't be that simple though!!!! It would depend on the application used on the server. For example, to attack a dns server, different means are used when comparing to attacking a web server.


Let me know if something is left unclear!

0
 
rafael_accCommented:
In my attempt to give you a more thorough understanding, I found the link below which I recommend you to check.
http://www.auditmypc.com/freescan/readingroom/port_scanning.asp

It explains port scanning (for both tcp and udp), and some additional useful information.

cheers
0
 
philjones85Author Commented:
first, i never said "random responses", i said "random requests".  what i mean by that is, a hacker would send "some carefully construed UDP datagram" to "some port that he/she specifies".  for conciseness i referred to that as a "random request"

that article explains it perfectly:

Port scanning usually means scanning for TCP ports, which are connection-oriented and therefore give good feedback to the attacker. UDP responds in a different manner. In order to find UDP ports, the attacker generally sends empty UDP datagrams. If the port is listening, the service should send back an error message or ignore the incoming datagram. If the port is closed, then most operating systems send back an "ICMP Port Unreachable" message. Thus, you can find out if a port is NOT open, and by exclusion determine which ports are open. Neither UDP packets, nor the ICMP errors are guaranteed to arrive, so UDP scanners of this sort must also implement retransmission of packets that appear to be lost (or you will get a bunch of false positives). Also, this scanning technique is slow because of compensation for machines that implement the suggestions of RFC 1812 and limit ICMP error message rate. For example, a kernal may limit destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded.

the most important part "If the port is closed, then most operating systems send back an ICMP Port Unreachable message", this would be a dead giveaway if i wasn't blocking ICMP requests.  since i am, i have nothing to worry about.

thank you sir, you answered my question perfectly.
0
 
rafael_accCommented:
I am happy then and you are welcome.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now