Haven’t used a firewall or a virus checker in about 5 years, been on cable for 4 without a single problem. Just close your ports and don’t open dodgy attachments.
Errrm. That’s what a firewall does.
If memory serves, yes. That would be the one.
The one I am talking about (just in case we’re discussing seperate things) is present in all packages. C’T did a load scan of another magazines http server using this number - by looking at how many numbers were skipped between requests, they could tell how many packets the servers had answered in between.
Since different OSs increment the sequence number differently, you can even tell what OS is running on the machine in question.
It is a shame that C’T doesn’t have that article online. There was a lot of good info in it.
Also, look for info on “passive port scans.”
At a bare minimum any Windows PC workstation directly connected to the Internet should have ZoneAlarm, Adaware, and the Google Toolbar with advanced features turned off.
One of the big problems with broadband is that the connection is so fast and network worms so promiscuous that you can get infected before your own defenses are in place. This is particularly a problem with Windows XP where the base install is vulnerable to certain worms but gets infected before you can install the patch from Windowsupdate - and the worm disables Windowsupdate.
I’ve got a home network. My workstation PCs run a virus-checker and I have Agnitum Outpost on my server/router and there’s a Smoothwall machine between the server (seperate NIC) and the internet. A layered defense, if you will.
When I install XP I disable the connection first to install a firewall. Then, once that’s up, enable the connection and run the updates.
It’s scary how many attacks are made so quickly within the first few minutes of installation.
245189 Intrustions have been blocked since install says ZoneAlarm… and the number goes up while I type this.
I think Mort Furd is talking about the “Pixie” scan.
Most platforms are vulnerable to the probe using uncompleted IP SYN requests (including network hardware like routers, not just computers). As far as I’m aware there’s been no successful scan of this type made using a protocol-asymmetric technique (i.e. probing IP ports by measuring ICMP ECHO responses) since the sequence numbers aren’t uniform across protocols. It’s also, in the real world, a fairly impractical attack since it relies heavily on the targetted node not dealing with much (if any) other traffic.
The main disadvantage of being pingable is that hackers often scan blocks of addresses using ping to determine which ones are active. Those that are can then be singled out for more attention.
Nope. No incomplete packets involved. The trick (when used in a passive scan by a hacker) requires a target and a relatively in active “patsy.”
The hacker uses the patsy’s IP address in the packets he sends to the actual target. At the same time, he sends a continuous stream of pings (or other requests) to the patsy. Since the patsy is presumed inactive (a machine left on and connected to the internet, but otherwise not in use,) any skips in the IP sequence numbers coming back to the attacker indicates that the patsy has received an answer from the target.
It does do the job, though there are (clearly) some difficulties to overcome in determining exactly which port is open on the target. Doing so entirely without out a direct attack will take a good bit of time - which is fine, since the target can’t figure out where the attack is coming from. All it can find is the patsy, and that can be changed very easily.
I understand the way the scan works, Mort Furd. I was pointing out that the packets sent to the patsy (aka the “witness” node) aren’t ICMP ECHO since the packet sequence numbers aren’t related across protocols. Usually the probe packets sent to the witness by the attacker would be asymmetric uncompleted SYN requests (which wouldn’t usually be logged because the negotiation is not completed - the witness node’s admin would have to be running something that logged packets at a lower level than usual to see the activity). In this way it’s hidden both from the target admin and from the witness admin.
The main point though is that all the packets have to be on the same protocol. You could probably do a stealthy ping of a target node using just ICMP, but you couldn’t do a port scan since that’s intrinsically an IP operation and its packet sequence numbers would be unrelated to the ICMP ones.
This is essentially an implementation artefact and there may be hardware/software out there on which a protocol-asymmetric method would work, but none are currently known.
Anyone have any views as to how Norton compares with ZoneAlarm et alia?
Idle can is not theoretical, it is here, now.
http://www.insecure.org/nmap/idlescan.html
http://www.bursztein.net/secu/temoinus.html
You are correct, in as far as a standard imcp ping is not used. Still, unless I’m completely off base (and I may well be,) sending a TCP packet at an open ping port will get a response of some kind - unless your firewall is rigged to drop packets instead of rejecting them.
Well, ICMP is a portless protocol, so you can’t “ping” a specific port, just an address. By default all IP devices should respond to ICMP ECHO packets, but firewalls are often set to drop them as a first line of defence against address block scanning.
The pixie scan is certainly a real side-channel artefact, but it remains a difficult one to implement. Its main weakness lies in finding a reliably idle witness node. If the witness node isn’t idle, or drops in and out of an idle state unpredictably, then this kind of scan becomes very difficult.
Statistical tabulation of the results helps alleviate these problems, but you can never say with 100% certainty that a given port scan produced real results since it relies on an assumption about undiscoverable information.
I note from those links that Linux 2.4.x isn’t useful as a zombie in that attack, and since that’s what I’m running, and many routers run a kernel based on that, I think leaving the ability to ping in is an okay thing. 