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?
LVL 6
philjones85Asked:
Who is Participating?
 
rafael_accConnect With a Mentor Commented:
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
 
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
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

 
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
 
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
 
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.