ipfw reset for UDP

S

suhijo

I've been migrating my firewall from mandriva to FreeBSD and I'm almost done with it. But I'm pretty freaky about security and in my linux I have the next rule:

Code: 
#iptables -A INPUT -i eth1 -p udp -m multiport --dport 1:65535  -j REJECT

which means: if anything comes from 1-65535 ports and upd protocol, reject. and if I do a nmap to any of these ports, it just simply says:

Code: 
PORT     STATE  SERVICE
5050/udp closed mmcc
which I love!

But when I do this in ipfw:

Code: 
#ipfw -q add reset log udp  from any to any keep-state
and I use nmap, the result is:

Code: 
PORT   STATE         SERVICE
53/udp open|filtered domain

So I don't like to tell to the world that I'm filtering packets. I just want to reset it. How can I do this in FreeBSD with ipfw? Or what am I doing wrong?

Thanks
 
suhijo said:
and I use nmap, the result is:

Code: 
PORT   STATE         SERVICE
53/udp open|filtered domain

So I don't like to tell to the world that I'm filtering packets...
Click to expand...

You're not. Filtered means there was no response at all, see the nmap(1) man page.

I just want to reset it. How can I do this in FreeBSD with ipfw? Or what am I doing wrong?
Click to expand...
The correct response would be an ICMP port unreachable, not a RST.
 
I just saw that you are trying to send a RST to UDP communication :r :r

No offense but if you are freaky about security you should first get a better understanding on how tcp/ip works.
 
Code: 
#ipfw -q add reset log udp  from any to any keep-state
UDP does not have states and reset gives you "Filtered". So if you want to mask them as "closed" you should write something like this:
Code: 
ipfw -q add unreach port log udp from any to me
Note this can lead to dns resolving problems.
 
Hi Yes you all are right.

gkontos: I did read that there is no reset on udp. I just want to give closed state as tcp does with reset and for my pleasure see a closed state; makes me feel better, and I did read a lot but I did not express my idea correctly.

Sirdice and alt: thanks, it works!

mister DUTCH DAEMON: Thanks for the advice I will apply it the next time.
 
suhijo said:
Hi Yes you all are rigth....:
gkontos : I did read that there is no reset on udp. I just want to give closed state as tcp does with reset and for my pleasure see a closed state make me feel better, and i did read a lot but i did not express my idea correctly.
Sirdice and alt : THANKS, IT WORK !!
mister DUTCH DAEMON: Thanks for the advice i will apply it the next time.
Click to expand...

A "stealth" firewall simply drops packets that are not supposed to enter, period.

Replying with a reset or an icmp unreachable only serves certain purposes such as speeding sendmail auth requests.

By having the firewall to return reset or icmp messages instead of dropping connections, you only create extra burden on it. You are also tempting an intruder to play with you.
 
gkontos said:
A "stealth" firewall simply drops packets that are not supposed to enter, period.

Replying with a reset or an icmp unreachable only serves certain purposes such as speeding sendmail auth requests.

By having the firewall to return reset or icmp messages instead of dropping connections, you only create extra burden on it. You are also tempting an intruder to play with you.
Click to expand...

Oh, that is interesting, but I have a question. What happens when I do not have a firewall and I try to reach a port? I have been doing this way because I want to get to the same scenario of that no firewall. The machine answers me with unreachable port udp and reset in tcp right?
 
suhijo said:
The machine answers me with unreachable port udp and reset in tcp right?
Click to expand...
That's correct.

The only thing you need to 'worry' about is if you do send back an ICMP or RST an attacker could look at the TTL of the replies. The 'reset' packets coming from the firewall will have a slightly higher TTL compared to a SYN/ACK that's coming from a service behind the firewall. Effectively telling your attacker you have a firewall.

But then again, I see no problems in my attacker knowing I've got a firewall. He's probably going to assume I have one anyway.
 
You must log in or register to reply here.
Back
Top