Hi SuSErs, What is udp port 3 for? /etc/services names it as compressnet. The reason I'm asking is that I keep getting lots of messages in my log like: Apr 21 15:40:43 fizia kernel: Packet log: output DENY eth0 PROTO=1 x.x.x.x:3 y.y.y.y:3 L=95 S=0xC0 I=0 F=0x4000 T=255 (#3) As I interpret it, some process on my machine tries to send a UDP packet from port 3 to port 3 on some host on ISP network. Firewall rules deny this. I wonder what process may try these connections? My machine connects ver Ethernet to an ADSL modem, if it is relevant. I found some messages about this weird compressnet in German list but can understand nothing from them. Could anyone shed some light? Thanks, -Kastus
On Sat, 21 Apr 2001, Konstantin (Kastus) Shchuka wrote:
Hi SuSErs,
What is udp port 3 for? /etc/services names it as compressnet.
The reason I'm asking is that I keep getting lots of messages in my log like:
Apr 21 15:40:43 fizia kernel: Packet log: output DENY eth0 PROTO=1 x.x.x.x:3 y.y.y.y:3 L=95 S=0xC0 I=0 F=0x4000 T=255 (#3)
As I interpret it, some process on my machine tries to send a UDP packet from port 3 to port 3 on some host on ISP network. Firewall rules deny this.
Well, actually, PROTO=1 is ICMP, not UDP. It doesn't use ports, so the ipchains logging facility uses those places in the format to display the ICMP message type and reason code instead. ICMP code 3, reason 3 means 'destination unreachable; port unreachable'. Another host is trying to connect to a service on your host. Your host is not running that service, so it's attempting to tell the requestor politely to go away. ICMP 3 is the way to do this. However, your ipchains ruleset is preventing the outgoing ICMP 3 message from being sent, and it's writing this message to the log to let you know. So much for the technical side. Why? Many firewall designers choose to block all unnecessary services. They sometimes differ on what's 'necessary', though. ICMP is frequently blocked by designers who prefer the 'stealth' approach - stay absolutely silent, and they'll think you're not even there. Any response, even a 'go away, this door is locked' message might reveal some information about your system that might conceivably be expoited. Now the other side of the coin. Several common, usually necessary services, like SMTP and DNS, for example, routinely and legitimately issue an 'ident' call to identify the requestor for logging purposes, before opening the connection. They seldom refuse to serve, even if the requestor's host isn't running an 'ident' service. Since 'ident' by design gives out information about users on the system, few cautious people choose to run it. However, if you choose to close the 'ident' port, and you ALSO choose to DENY outgoing ICMP 3,3's, then your DNS and SMTP servers will wait for a while expecting an ident response, before they time out, finally assume that you're not running ident, and open the connection anyway. If you allow outgoing ICMP 3,3's, you won't see that initial delay every time you access your DNS or SMTP relay. You didn't publish the destination IP address from your message. I don't need to see it, but you might look yourself to see if it's a known server that you would like more prompt service from... -- Rick Green "I have the heart of a little child, and the brain of a genius. ... and I keep them in a jar under my bed"
On Sun, Apr 22, 2001 at 12:51:04AM -0400, Rick Green wrote:
On Sat, 21 Apr 2001, Konstantin (Kastus) Shchuka wrote:
Hi SuSErs,
What is udp port 3 for? /etc/services names it as compressnet.
The reason I'm asking is that I keep getting lots of messages in my log like:
Apr 21 15:40:43 fizia kernel: Packet log: output DENY eth0 PROTO=1 x.x.x.x:3 y.y.y.y:3 L=95 S=0xC0 I=0 F=0x4000 T=255 (#3)
As I interpret it, some process on my machine tries to send a UDP packet from port 3 to port 3 on some host on ISP network. Firewall rules deny this.
Well, actually, PROTO=1 is ICMP, not UDP. It doesn't use ports, so the ipchains logging facility uses those places in the format to display the ICMP message type and reason code instead. ICMP code 3, reason 3 means 'destination unreachable; port unreachable'.
I looked in the wrong place and then forgot, and then messed with protocols. Of course, it's ICMP.
Another host is trying to connect to a service on your host. Your host is not running that service, so it's attempting to tell the requestor politely to go away. ICMP 3 is the way to do this. However, your ipchains ruleset is preventing the outgoing ICMP 3 message from being sent, and it's writing this message to the log to let you know.
I'm using SuSEfirewall, it generates rule automatically. There is only one place which deals with icmp, it's FW_KERNEL_SECURITY="yes". Is it correct?
So much for the technical side. Why? Many firewall designers choose to block all unnecessary services. They sometimes differ on what's 'necessary', though. ICMP is frequently blocked by designers who prefer the 'stealth' approach - stay absolutely silent, and they'll think you're not even there. Any response, even a 'go away, this door is locked' message might reveal some information about your system that might conceivably be expoited. Now the other side of the coin. Several common, usually necessary services, like SMTP and DNS, for example, routinely and legitimately issue an 'ident' call to identify the requestor for logging purposes, before opening the connection. They seldom refuse to serve, even if the requestor's host isn't running an 'ident' service. Since 'ident' by design gives out information about users on the system, few cautious people choose to run it. However, if you choose to close the 'ident' port, and you ALSO choose to DENY outgoing ICMP 3,3's, then your DNS and SMTP servers will wait for a while expecting an ident response, before they time out, finally assume that you're not running ident, and open the connection anyway. If you allow outgoing ICMP 3,3's, you won't see that initial delay every time you access your DNS or SMTP relay.
That's true, I don't run identd
You didn't publish the destination IP address from your message. I don't need to see it, but you might look yourself to see if it's a known server that you would like more prompt service from...
One of the addresses is the DNS server on ISP side (I don't run named). The other one is DNS server, too. I guess, I need to add ACCEPT rule for ICMP 3,3's to my DNS servers. Is it correct? Thanks Rick for a great explanation! -Kastus
-- Rick Green
"I have the heart of a little child, and the brain of a genius. ... and I keep them in a jar under my bed"
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq and the archives at http://lists.suse.com
On Sun, 22 Apr 2001, Konstantin (Kastus) Shchuka wrote:
Another host is trying to connect to a service on your host. Your host is not running that service, so it's attempting to tell the requestor politely to go away. ICMP 3 is the way to do this. However, your ipchains ruleset is preventing the outgoing ICMP 3 message from being sent, and it's writing this message to the log to let you know.
I'm using SuSEfirewall, it generates rule automatically. There is only one place which deals with icmp, it's FW_KERNEL_SECURITY="yes". Is it correct? A few months ago, I posed this same question on the suse-security list, and marc told me to simply set FW_ALLOW_FW_TRACEROUTE="yes", and SuSEfirewall would handle it.
-- Rick Green "I have the heart of a little child, and the brain of a genius. ... and I keep them in a jar under my bed"
On Sun, Apr 22, 2001 at 10:31:13AM -0400, Rick Green wrote:
On Sun, 22 Apr 2001, Konstantin (Kastus) Shchuka wrote:
Another host is trying to connect to a service on your host. Your host is not running that service, so it's attempting to tell the requestor politely to go away. ICMP 3 is the way to do this. However, your ipchains ruleset is preventing the outgoing ICMP 3 message from being sent, and it's writing this message to the log to let you know.
I'm using SuSEfirewall, it generates rule automatically. There is only one place which deals with icmp, it's FW_KERNEL_SECURITY="yes". Is it correct? A few months ago, I posed this same question on the suse-security list, and marc told me to simply set FW_ALLOW_FW_TRACEROUTE="yes", and SuSEfirewall would handle it.
OK, I managed to fine-tune the rules. First thing, I uncommented the line FW_CUSTOMRULES="/etc/rc.config.d/firewall-custom.rc.config" in /etc/rc.config.d/firewall.rc.config Second, I added the following two lines to the file /etc/rc.config.d/firewall-custom.rc.config in section fw_custom_before_antispoofing() : ipchains -I output -j ACCEPT -p icmp -d 198.144.192.2 3 --icmp-type 3 ipchains -I output -j ACCEPT -p icmp -d 198.144.192.4 3 --icmp-type 3 where 198.144.192.2 and 198.144.192.4 are my DNS servers. Thanks again to Rick for pointing me in the right direction. -Kastus
-- Rick Green
"I have the heart of a little child, and the brain of a genius. ... and I keep them in a jar under my bed"
* Rick Green [Sun, 22 Apr 2001 00:51:04 -0400 (EDT)]:
ICMP is frequently blocked by designers who prefer the 'stealth' approach - stay absolutely silent, and they'll think you're not even there. Any response, even a 'go away, this door is locked' message might reveal some information about your system that might conceivably be expoited.
Yeah, and it also makes some web sites unreachable because they also block ICMP 'need fragmentation' and your connection to the internet uses unusual frame sizes (like when you're connected via a crypted tunnel). IMO actions like that show that the admins that do so don't really understand the issues they're dealing with or fail to explain it properly to their peers. Philipp -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
participants (3)
-
Konstantin (Kastus) Shchuka -
Philipp Thomas -
Rick Green