Hi Can anyone explain how it is possible that a machine can 'respond' to SMTP traffic that it didn't create. " Nov 11 10:58:29 firefly kernel: DROP OUTPUT INET: IN= OUT=eth0 SRC=66.8.45.165 DST=200.207.3.8 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=25 DPT=4284 WINDOW=0 RES=0x00 ACK RST URGP=0 Nov 11 10:59:16 firefly last message repeated 4 times " This is from my logs. This particular machine does not even have an SMTP service/daemon running on it. It is a web server and my iptables rules do not allow incoming SMTP (DPT: 25) to this machine. Anyone have comments/answers? Ray
* Ray Leach wrote on Mon, Nov 11, 2002 at 11:04 +0200:
Can anyone explain how it is possible that a machine can 'respond' to SMTP traffic that it didn't create.
DF PROTO=TCP SPT=25 DPT=4284 WINDOW=0 RES=0x00 ACK RST URGP=0
This is from my logs. This particular machine does not even have an SMTP service/daemon running on it.
The kernel sends an RST packet to inform the "client" that there is no such service. The client should get an "connection refused".
It is a web server and my iptables rules do not allow incoming SMTP (DPT: 25) to this machine.
Are you sure that no SMTP packet at all can reach your server? Then I would wonder why there are RST packets on wire... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Tue, 2002-11-12 at 00:54, Steffen Dettmer wrote:
* Ray Leach wrote on Mon, Nov 11, 2002 at 11:04 +0200:
Can anyone explain how it is possible that a machine can 'respond' to SMTP traffic that it didn't create.
DF PROTO=TCP SPT=25 DPT=4284 WINDOW=0 RES=0x00 ACK RST URGP=0
This is from my logs. This particular machine does not even have an SMTP service/daemon running on it.
The kernel sends an RST packet to inform the "client" that there is no such service. The client should get an "connection refused".
It is a web server and my iptables rules do not allow incoming SMTP (DPT: 25) to this machine.
Are you sure that no SMTP packet at all can reach your server? Then I would wonder why there are RST packets on wire...
Yup, here's the rule for that server: $IPTABLES -A INPUT -i $IFACE_INET -p tcp --dport 25 -d $IP_INET_WEB1 -j REJECT --reject-with tcp-reset
oki,
Steffen
-- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --
* Raymond Leach wrote on Tue, Nov 12, 2002 at 11:09 +0200:
Are you sure that no SMTP packet at all can reach your server? Then I would wonder why there are RST packets on wire...
Yup, here's the rule for that server:
$IPTABLES -A INPUT -i $IFACE_INET -p tcp --dport 25 -d $IP_INET_WEB1 -j REJECT --reject-with tcp-reset
Well, wouldn't it be possible that the "--reject-with tcp-reset" generates the TCP RST packet?! oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Tue, 2002-11-12 at 12:07, Steffen Dettmer wrote:
* Raymond Leach wrote on Tue, Nov 12, 2002 at 11:09 +0200:
Are you sure that no SMTP packet at all can reach your server? Then I would wonder why there are RST packets on wire...
Yup, here's the rule for that server:
$IPTABLES -A INPUT -i $IFACE_INET -p tcp --dport 25 -d $IP_INET_WEB1 -j REJECT --reject-with tcp-reset
Well, wouldn't it be possible that the "--reject-with tcp-reset" generates the TCP RST packet?!
Yes, but then why is it generated as being from the targeted server instead of the firewall? That means that I have to allow the target server to 'repond' to smtp 25 packets with a forwarding rule, or live with the entries in the log and one more packet on the network ...
oki,
Steffen
-- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --
* Raymond Leach wrote on Tue, Nov 12, 2002 at 12:08 +0200:
On Tue, 2002-11-12 at 12:07, Steffen Dettmer wrote:
Well, wouldn't it be possible that the "--reject-with tcp-reset" generates the TCP RST packet?!
Yes, but then why is it generated as being from the targeted server instead of the firewall? That means that I have to allow the target server to 'repond' to smtp 25 packets with a forwarding rule, or live with the entries in the log and one more packet on the network ...
Otherwise, the client would get an RST from a destination it never tried to contact and would discard the packet. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Tue, 2002-11-12 at 12:59, Steffen Dettmer wrote:
* Raymond Leach wrote on Tue, Nov 12, 2002 at 12:08 +0200:
On Tue, 2002-11-12 at 12:07, Steffen Dettmer wrote:
Well, wouldn't it be possible that the "--reject-with tcp-reset" generates the TCP RST packet?!
Yes, but then why is it generated as being from the targeted server instead of the firewall? That means that I have to allow the target server to 'repond' to smtp 25 packets with a forwarding rule, or live with the entries in the log and one more packet on the network ...
Otherwise, the client would get an RST from a destination it never tried to contact and would discard the packet.
OK, but then do I still need to forward the smtp ACK RST packets that are generated, or should I just change the rule to DROP instead of REJECT? --
* Raymond Leach wrote on Tue, Nov 12, 2002 at 13:16 +0200:
On Tue, 2002-11-12 at 12:59, Steffen Dettmer wrote:
Otherwise, the client would get an RST from a destination it never tried to contact and would discard the packet.
OK, but then do I still need to forward the smtp ACK RST packets that are generated, or should I just change the rule to DROP instead of REJECT?
For normal cases (for instance, ports on hosts with visible addresses, such as MX or web servers) I would use REJECT. I think this is the correct way, since I guess the most users are not attackers and should not be punished by not sending correct responses :) OK, a portscan may become somewhat faster, but let them scan the firewall :) So I would allow the RST packets simply, it shouldn't be a risk, it's outgoing direction and tells a port is unreachable (with DROP, the attacker can guess that the port is unreachable if she get no response at all). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (3)
-
Ray Leach -
Raymond Leach
-
Steffen Dettmer