udp vulnerability (nessus report)
 

one of my security vulnerabilities i got back in my audit report is:

******************
AUDIT:
It is possible to by-pass the rules of the remote firewall
by sending UDP packets with a source port equal to 53.

An attacker may use this flaw to inject UDP packets to the remote
hosts, in spite of the presence of a firewall.

Solution : Review your firewall rules policy
Risk Factor : High
BID : 7436
******************


i have udp rejected under ipchains leaving access to only computers that have certain ip address .... aka a known "safe list" of servers that i know (example: our dns server). since i've "corrected" the problem above by blocking all udp's and accepting only known ip's; then why is my report still showing up under nessus's audit report?.... even though all udp stuff is blocked.

Are you running Nessus from a computer that's on the "Safe List"? Remember that it's not the machine running the Nessus client that actually scans, it's the machine running Nessus daemon.

The other possibility is that it might be a poorly written probe that just assumes that any UDP packet that doesn't generate an ICMP port-unreachable did actually go through. If your firewall is dropping UDP packets rather than rejecting them, it would *appear* that they've been accepted (because no ICMP error) but it was actually dropped.

nope....i'm not running my nessus server from a "friendly". else it would get past my firewall and report loads of stuff that are actually sealed off. that's the first thing we made sure of.

also.....

i don't ever drop in my firewall. i only accept and reject. so i'm still not sure why it keeps reporting this vul. presently, i drop both udp and icmp packets in my ipchains. however, this error was happening on my servers before i rejected the icmp packets. any idea why this vul. is still showing up?

Basically it means if you don't restrict inbound traffic with a source port of UDP/53 to only come from legitimate DNS servers someone could forge access by specifiying source port UDP/53.

Maybe it would clarify things if you posted your firewall rules so we can tell exactly what's going on.

Hmm, based on another recent post, I'm guessing you're running Red Hat with "lokkit". That pathetic excuse for a firewall allows all packets (to any address, /boggle) with a source port of 53/udp. That's supposed to allow DNS lookups, but that is the absolute worst way to attempt letting them through the firewall.

Someone could quiet easily scan and attack all your open UDP ports on the machine, right through your firewall, by simply using port 53/udp as the source for each datagram.

____________________________________
"Basically it means if you don't restrict inbound traffic with a source port of UDP/53 to only come from legitimate DNS servers someone could forge access by specifiying source port UDP/53."
____________________________________


my last three entries in my ipchains is this:

.
.
.
.
# everyone else
-A input -p tcp -j REJECT -l
-A input -p udp -j REJECT -l
-A input -p icmp -j REJECT -l

therefore i have restricted inbound traffic. so as far as my dns server is conserned. it is allowed based on it's ip address. so udp can be blocked for everone else.

second:
____________________________________
"I'm guessing you're running Red Hat with "lokkit"
____________________________________
i don't know if lokkit is what i'm running. after looking for it i found this:

# find . -name "*lokkit*"
./usr/sbin/lokkit
./usr/share/doc/lokkit-0.50


but since i only use command line i don't think that i've used it. i had the above entries directly in my ipchains table. is lokkit still going to allow the vulnerability you were talking about?

Those reject rules are only your default, though. iptables is first match, so whatever comes above that is what's really important. That's why I suggested that you post your entire firewall ruleset.

here is what my ipchains look like. hopefully this will help.




# Firewall configuration written by lokkit
# Manual customization of this file is not recommended.
# Note: ifup-post will punch the current nameservers through the
# firewall; such entries will *not* be listed here.
:input ACCEPT
:forward REJECT
:output ACCEPT

# DNS servers
-A input -p tcp -s xx.xxx.xx.xxx domain -j ACCEPT

# reject for "register.asp" spam
-A input -p tcp -s xx.xxx.xxx.xx -j REJECT

# incoming ssh
#-A input -d 0/0 ssh -p tcp -j ACCEPT

# return from outgoing ssh
#-A input -s 0/0 ssh -p tcp -j ACCEPT

# return from outgoing chatterbox info connection
#-A input -s 0/0 4443 -p tcp -j ACCEPT

# incoming http/https
-A input -d 0/0 http -p tcp -j ACCEPT
-A input -d 0/0 https -p tcp -j ACCEPT

# return from outgoing http/https
-A input -s 0/0 http -p tcp -j ACCEPT
-A input -s 0/0 https -p tcp -j ACCEPT

# return from outgoing smtp
-A input -s 0/0 smtp -p tcp -j ACCEPT

# incoming smtp (temp)
-A input -d 0/0 smtp -p tcp -j ACCEPT

# return from outgoing mysql
-A input -s 0/0 mysql -p tcp -j ACCEPT

# localhost
-A input -i lo -j ACCEPT

# office IP
-A input -s xx.xx.xx.xx -j ACCEPT

# mail server
-A input -s xx.xx.xx.xx -j ACCEPT

# another server
-A input -s xx.xx.xx.xx -j ACCEPT

# somebody's home ip
-A input -s xx.xx.xx.xx -j ACCEPT

# everyone else
-A input -p tcp -j REJECT -l
-A input -p udp -j REJECT -l
-A input -p icmp -j REJECT -l

You firewall looks sound (brief glance, certainly nothing to cause a UDP hole), so I looked at the source of that particular Nessus plugin

Now I'm not familiar with the Nessus plugin syntax, and I'm also not a brilliant TCP/IP programmer, but it appears to me that the plugin is simply looking for an ICMP "unreachable" error (any of the type 3 codes). Since you're using reject rather than drop for your default, it will return an ICMP unreachable error in response to UDP datagrams, thus I believe this to be a false positive. You can easily make that determination by changing
-A input -p udp -j REJECT -l
to
-A input -p udp -j DROP -l

And rerunning that particular Nessus plugin.

.

unfortunately this does not seem to be the problem. after trying your test:

*************************
# everyone else
-A input -p tcp -j REJECT -l
#-A input -p udp -j REJECT -l
-A input -p udp -j DROP -l
-A input -p icmp -j REJECT -l
*************************

[]# /etc/rc.d/init.d/ipchains restart
Flushing all current rules and user defined chains: [ OK ]
Clearing all current rules and user defined chains: [ OK ]
Applying ipchains firewall rules: Auto-creating chain DROP
[ OK ]



changing the REJECT to a DROP, restarted ipchains, i then reran my audit. not only did the same udp error still remain. but new errors (some sunrpc port 111/tcp errors and some unknown erros from port 32768/udp) have not been added to my audit. these last errors were not there when i was REJECTing udp instead of DROPing

Well I'd have to look at those plugins too, but I would assume that they base their errors on the fact that the packets did not get rejected (for ports 111 and 32768).

By the way, on second inspection your firewall is a bit lacking. You're using a stateless packet filter so you are allowing return traffic excplicitly, but not requiring that ACK be set. This means that sneaking packets through would be trivial (by using the correct source port). You should look into using the ESTABLISHED and RELATED keywords in your rules to cover all existing and related connection traffic and not open yourself to attacks originating from specially choosen source ports.

you mean i should change to from ipchains to iptables (iptables is stateful packet filtering right?) you can't do such things with ipchains (which is what i'm using right now).



i just wish that i knew that the error was false. that there is no udp error under port 53. that i've blocked it. that only those ip's that i've allowed will be able to reach it. that is is nessus presumptive code that assumes that there is a vulnerability, and that i knew what this assumption was.....