Re: [suse-security] Winpopups behind SUSEfirewall
First thanks for the answer, but
Close this ports used by Netbios
udp/135 udp/137 - 139 udp/445 tcp/137 - 139 tcp/445
These ports are _not_ open (scanned using nmap...). No ports are open from the outside...
More information in http://www.hispasec.com/unaaldia/1587 (spanish) hmmm...
Could test your configuration with http://www.mynetwatchman.com/winpopuptester.asp
Jup, I had done that already... naturally that doesn't get through. I think the technique must be different, don't know how, but maybe the packets are generated from the inside (by some javascript, trojan or whatever...) -- could not put my finger to it yet... Cheers, Arndt -- Arndt Faulhaber mailto:arndt.faulhaber@diagnosdata.com
Specifically block those ports and test. Saludos. El mar, 26 de 08 de 2003 a las 09:53, Arndt Faulhaber escribió:
First thanks for the answer, but
Close this ports used by Netbios
udp/135 udp/137 - 139 udp/445 tcp/137 - 139 tcp/445
These ports are _not_ open (scanned using nmap...). No ports are open from the outside...
More information in http://www.hispasec.com/unaaldia/1587 (spanish) hmmm...
Could test your configuration with http://www.mynetwatchman.com/winpopuptester.asp
Jup, I had done that already... naturally that doesn't get through. I think the technique must be different, don't know how, but maybe the packets are generated from the inside (by some javascript, trojan or whatever...) -- could not put my finger to it yet...
Cheers, Arndt
Messenger service also listens on port 1026 (http://www.lurhq.com/popup_spam.html). Personally I would disable this service as I've never seen a useful purpose. Make sure you block this port. As its above the 1024 priviledge ports it may be allowed through your firewall. In section 11 of SuSefirewall check the following setting. Mine is set to the following, but you may find this doesn't work. FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS" The spammers are now using this port as a large majority of ISP are now blocking ports 135-137 to stop the various viruses/etc. Adam On Tue, 2003-08-26 at 20:22, Jose Valdez wrote:
Specifically block those ports and test. Saludos.
El mar, 26 de 08 de 2003 a las 09:53, Arndt Faulhaber escribió:
First thanks for the answer, but
Close this ports used by Netbios
udp/135 udp/137 - 139 udp/445 tcp/137 - 139 tcp/445
These ports are _not_ open (scanned using nmap...). No ports are open from the outside...
More information in http://www.hispasec.com/unaaldia/1587 (spanish) hmmm...
Could test your configuration with http://www.mynetwatchman.com/winpopuptester.asp
Jup, I had done that already... naturally that doesn't get through. I think the technique must be different, don't know how, but maybe the packets are generated from the inside (by some javascript, trojan or whatever...) -- could not put my finger to it yet...
Cheers, Arndt
On Tuesday 26. August 2003 21:45, Adam Leach wrote:
Messenger service also listens on port 1026 (http://www.lurhq.com/popup_spam.html). Personally I would disable this service as I've never seen a useful purpose. Actually printer spooler and some antivirus sw use it and anyway the client does not want to turn the service off... and anyway this stuff should just _not come through_ anyways...
Make sure you block this port. As its above the 1024 priviledge ports it may be allowed through your firewall.
In section 11 of SuSefirewall check the following setting. Mine is set to the following, but you may find this doesn't work.
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS" Never had anything else in there... actually this does not mean that it has to be dns, just that the sourceport at the sender is 51, whatever the protocol... might even be this popupstuff.
I just wonder how they get thought the masquerading directly to a machine inside. They cannot see the internal addresses from the outside, they don't even get routed on the Net. So either it must come from the inside or it must use some kind of tunneling... so the Firewall extracts the real packet and sends it to the internal machine - or it's some kind of man in the middle attack, so the firewall thinks there a session active, which actually is not the case. But afaik sessionhijacking only makes sense with tcp, since udp (which is uses by this popupthing) is not session-oriented, though I don't know how stateful inspection handles udp... Cheers, Arndt -- Arndt Faulhaber mailto:arndt.faulhaber@diagnosdata.com
participants (3)
-
Adam Leach -
Arndt Faulhaber -
Jose Valdez