Am Thu, 22 Dec 2005 16:18:24 -0500 schrieb Bill & Debbie:
GRC is crap and has always been.
Stealth ports are technical nonsense.
Fine, a closed port remains a closed port and nobody can connect to it, so sit back and relax.
Have you secured the wireless network? Best would be to use WPA since all WEP is insecure. If not, do that, that is much more important than wasting your time by thinking how stealth a port that is *closed*.
ZA is crap.
No reason to do that but a lot of reasons for you to learn something about tcp/ip.
I just looked and my wireless network is NOT secure. I would like to follow your advice and secure it using WPA. I am a novice at best with regards to networks, firewalls and protection/security. My requirements are very simple: I have a laptop that is wireless and connects to the internet using DSL. I have it in my home and only use the wireless network to give me some mobility in the house. I do not have anything else connected to the network.
So, when I set up WPA, should I enter a key? Is it important to use a large key and remember it? Do I need to enter a Group renewal period? If so, what is a good time to enter?
You only have WEP with that Linksys NAT router there is no WPA.
Make sure you use the 11S4 router's logging ability and use Wallwatcher (free) use Google to find it and watch inbound and outbound traffic to/from the router as someone can hack your wireless network and use it to access the Internet and you'll be able to see that traffic in the logs. If you wanted to WPA, then you should have gotten wireless *G* router and has better security measures with the WPA and WEP than a wireless *BE* that only has WEP. They can also hack one of the machines on your LAN too and maybe ZA and stop them and maybe ZA cannot stop them and is why you should be going to the O/S to secure it as much as possible based on the O/S you have such as XP or Win 2K. You got Windows ME or Windows 9'x, then you're out of luck.
Makes plenty of difference to most people I know, including me - IRC and Usenet connect are much slower, as the servers I use both connect back to
113. I don't have an ident service running, but even so connects are quick so long as connections as RST rather than dropped - if you have a "stealthed" 113, you end up having to wait 30 seconds for the connect attempt at the other to timeout.
Leythos wrote in news:DRRqf.223035$ firstname.lastname@example.org:
No problems here with 113 denied. In several years, I've only ever had one FTP server complain, but then it did serve me the file anyway. Most modern FTP servers don't require IDENT anymore. I have all FTP clients set to Passive. I've never had any mail server require IDENT, even thru several ISP changes and free email service providers.
Depends on how the corporate (perimeter) firewall is set. I don't have access to the corporate firewall here, but at home, the last time I bothered to log connection attempts, I don't think I saw it on more than a tiny number (< 1%) of systems I connect to. YMMV.
It's a fairly common complaint for home users.
Those servers that use Ident will send a query to 113/tcp, and wait for a response. The (normal) closed port responds "instantly" with an ICMP Type 3 Code 3. The so-called "stealth" configuration does not respond, and the remote server waits for a TCP timeout (usually 30 seconds) before continuing. This is the all to common cause of the standard complaint - instant connection, 30 second delay to the login prompt - seen for a lot of servers. This also occurs when the perimeter firewall block ICMP packets, or inbound unsolicited TCP.
Those home users who advocate forwarding the port 113 requests to an unused IP address fail to realize that the resulting ICMP Type 3 Code
1 (host unreachable) is returned from the host that claims to be unreachable. They simply fail to understand the concept of port forwarding. They at least recognize that a simple traceroute exposes the futility of "stealth mode".
Ident was originally (RFC0931 - obsoleted by RFC1413) used to identify users on systems with multiple simultaneous users - someone did something bad while connected from 192.0.2.11, and ident allowed the local admin to be able to identify the user and take "corrective" action. To avoid exposing local usernames, RFC1413 merely defines the response to contain a "USERID". Many modern Ident clients can be configured to return a MD5 hashed UserID. The protocol itself is useless as an authentication mechanism (which is what some stupid applications are trying to use it for), and the second paragraph of section 6 (Security Considerations) of RFC1413 specifically warns against trying to use it that way. In fact, the ident server I use at home returns "Rumplestiltskin" as a user, and I've never had a complaint or even a comment.