Security → Re: Security Scan. How can this be?

said by Publius:

---

Is the ICS machine behine a NAT router? If you aren't I don't see how the ICS machine could be stealth without some sort of firewall.

---

There is no NAT router other than ICS itself. Is anybody else using ICS without a firewall? What are your port scan results?

I agree that the client can unknowingly have Sub7 or other trojan but an up-to-date virus scanner like Norton with autoprotect and script blocking enabled should be an adequate defense.

I remain unconvinced that I need a firewall in addition to the firewall-like features that seem to be built into ICS.

said by jmorlan:

---

I remain unconvinced that I need a firewall in addition to the firewall-like features that seem to be built into ICS.

---

It is your protection that serves you, not us. My only question to you is, does ICS monitor outbound IP traffic? If not, then you can have serious problems. In that case, ICS is not a firewall, but more like an IDS, if I understand what you are saying about ICS.

Good way to check is temporally disable ICS and rerun the test.

I've never use ICS. When I used Wingate I had to run a firewall to protect the machine directly connected to the Internet.

Check if your ISP is providing and sort of firewall. Can you ping your machine remotely.

Check the value of your IP address. I believe some ISPs run their own NAT or proxy routers to conserve IP addresses.

ICS is MS's implementation of NAT (yes, you can call it that and no it's not an IDS). NAT provides pretty much bullet-proof protection from inbound probes such as those received from a scanner. All incoming packets with no entry in the NAT table (all inbound packets that are not part of an internally initiated "connection") are denied / dropped since ICS wouldn't know where to route the packets to.

Outbound packets create an entry in the NAT table so that ICS knows to let associated traffic (from the destination IP, directed to the correct port) back in. The NAT table entry also lets ICS know which computer "requested" the return traffic and so where to route the replies....

Zhen is correct to express concern about outgoing traffic however, outbound traffic is not filtered at all. A trojan / spyware would be free to make connections to anywhere it pleased. This means that nasties such as DDOS bots, etc. remain a concern despite NAT. A client infected with (standard) Sub7 would not pose a threat since attempts to connect to the server would be denied by NAT. A "push" trojan which initiated the connection from your machine to the attacker would proceed unhindered.

You are protected from "direct attack" behind NAT, however you are NOT completely secure. Norton anti-virus only detects a few of the more common trojans - others could send out private information or make provide access to your network via an internally initiated connection. A dedicated trojan scanner such as TDS-3 would provide more complete protection from this threat.

Personally, I feel more comfortable with control over traffic both to AND from my network...

[text was edited by author 2001-07-26 13:13:46]

Thanks for the helpful information. I judge my system to be at relatively low risk for the types of "push" trojans you mention. I just downloaded TDS-3 and it found nothing notable on my system. Is there an easier way to monitor outgoing traffic without a big firewall? I've tried firewalls in the past and I'd rather not use one unless it's essential. Maybe something that just writes outgoing connections to a log?

said by jmorlan:

---

Is there an easier way to monitor outgoing traffic without a big firewall? I've tried firewalls in the past and I'd rather not use one unless it's essential. Maybe something that just writes outgoing connections to a log?

---

I'm not sure about connection logging software, my firewall does that . You say "big firewall" - have you tried Tiny? Tiny lives up to it's name and offers excellent configurability. After a day of use it can be configured to be almost completely unobtrusive. This will not only log outgoing connections but stop unauthorised ones too.

I run Tiny behind NAT and admit to the fact that it has never "saved me" from anything.... yet. However I do like the "complete" protection that is afforded by the combination, and the knowledge that even if another user downloaded "nastytrojan.exe" it would, almost certainly, be rendered useless....

Considering that Tiny is effectively transparent to users in terms of resource usage, "pop-ups" (or lack thereof), etc. I find it hard to come up with reasons not to use it.....

Actually I tried Tiny when I first set up ICS because I thought I needed a firewall with ICS. Unfortunately I couldn't get ICS to work with Tiny installed. I'm sure there's a way to do it, but I decided to see if I really needed a firewall before fighting with it.

One thing occurs to me if I decide to go this route. I will have to run the firewall on both the host and client machines. If a trojan is active on the client machine, the firewall on the host will see it as coming from the ICS port and let it through. Is that right?

Right now I'm leaning toward running NETSTAT and checking to see if any connections are open that shouldn't be. Or how about

NETSTAT 600 > NETSTAT.TXT

which should keep a log of network activity every ten minutes for browsing later.

said by jmorlan:

---

Unfortunately I couldn't get ICS to work with Tiny installed.

---

Did you check "Is Running on Internet Gateway" under Advanced -> Miscellaneous (I think)?? This tells Tiny to expect to see traffic to / from your clients. ICS would not work without the setting...

said by jmorlan:

---

If a trojan is active on the client machine, the firewall on the host will see it as coming from the ICS port and let it through. Is that right?

---

ICS does not have a specific port... NAT does not work in the same way as a proxy, which is what I think you refer to?? A proxy operates on a single port (commonly 80 for http) and makes connections on behalf of it's clients. With NAT, the connection is direct from client to external host. NAT merely routes packets and slightly alters the header of each (the src/dest address is swapped between private and public on outbound/incoming packets respectively).

said by jmorlan:

---

Right now I'm leaning toward running NETSTAT and checking to see if any connections are open that shouldn't be. Or how about

NETSTAT 600 > NETSTAT.TXT

which should keep a log of network activity every ten minutes for browsing later.

---

This, while a valid method, would only have a small chance of catching certain types of trojan (which transmit data intermittently, or only once). Also the output would be hellish to troll through and inconclusive. It would be preferable to log (and filter) outbound traffic with a firewall, which provides much more detailed, readable information about traffic, including the application involved.

said by mbcx8nlp:

---

said by jmorlan:

---

Unfortunately I couldn't get ICS to work with Tiny installed.

---

Did you check "Is Running on Internet Gateway" under Advanced -> Miscellaneous (I think)?? This tells Tiny to expect to see traffic to / from your clients. ICS would not work without the setting...

---

I tried Tiny again. It has some nice features but I couldn't get the client PC to access the internet even with "running on internet gateway" checked. Disabling or even exiting the firewall didn't help, perhaps because it inserts itself before the TCP/IP stack.

The only way I could get connectivity back on the client machine was to completely uninstall TPF on the host. I searched usenet for information and found contradictory opinions about whether TPF is compatible with ICS.

TPF has a forum on Yahoo
»groups.yahoo.com/group/t ··· firewall
Try to get info there...

said by jmorlan:

---

Disabling or even exiting the firewall didn't help, perhaps because it inserts itself before the TCP/IP stack.

The only way I could get connectivity back on the client machine was to completely uninstall TPF on the host. I searched usenet for information and found contradictory opinions about whether TPF is compatible with ICS.

---

Tiny installs a static driver, which does indeed inspect / filter traffic below the TCP/IP stack. This would explain why an uninstall was necessary to restore connectivity.

In the past I have employed Tiny on a W98 based ICS host without problem, which Windows are you using?

said by mbcx8nlp:

---

In the past I have employed Tiny on a W98 based ICS host without problem, which Windows are you using?

---

Host is Win98SE. Client is Win95 OSR/2. The client is too underpowered to upgrade its OS. I tried installing TPF on the client and managed to get the host and client firewalls to talk to each other but the client still wouldn't connect to the outside.

Is there any "evidence" of Tiny blocking ICS traffic on the host? Check "Log packets addresses to unopened ports" and log any drop rules you have, to see if the ICS traffic is getting dropped by Tiny "intentionally"...

said by mbcx8nlp:

---

Is there any "evidence" of Tiny blocking ICS traffic on the host? Check "Log packets addresses to unopened ports" and log any drop rules you have, to see if the ICS traffic is getting dropped by Tiny "intentionally"...

---

It appears to be blocking DSN queries. Here are some log entries:

1,[27/Jul/2001 08:43:18] Rule 'Packet to unopened port received': : In UDP, 206.13.28.12:53->localhost:2167, Owner: No owner
1,[27/Jul/2001 08:43:46] Rule 'Packet to unopened port received': : In UDP, 63.200.115.40:53->localhost:2173, Owner: No owner
1,[27/Jul/2001 08:43:46] Rule 'Packet to unopened port received': : In UDP, dns1.mtry01.pacbell.net [63.200.115.40:53]->localhost:2175, Owner: No owner
1,[27/Jul/2001 08:45:06] Rule 'Packet to unopened port received': : In UDP, 206.13.28.12:53->localhost:2177, Owner: No owner

Can I just confirm that these are log entries from Tiny on the ICS host resulting from an attempt to surf by a client?

The DNS queries are obviously making it out OK.. AFAIK NAT takes place before Tiny inspects inbound traffic. The NAT table entry for the requests must point return traffic to the appropriate host... I do not understand why these replies are appearing on the "private" interface of the ICS host.

Make sure that your DNS rule permits UDP in "both" directions. Does the same series of events occur with other traffic? Try pinging an external host from a client.

Perhaps an older version of TPF would work - I had success with one of the older versions....

If the problem seems un-solvable, consider some of the alternatives. ICS is by no means the optimum solution for connection sharing....

*nix based router - Free, much more powerful, configurable and secure than ICS. Displaces routing load from host machine to dedicated box. Can be run on old hardware. e.g. the Linux Router Project is a mini-distribution solely for this purpose which runs from a (write-protectable) floppy and requires nothing more than a 486 with no hard drive, monitor, etc.

Winroute Lite/Pro (Tiny software again) - again, much more powerful, configurable and secure than ICS. Many features including a similar (but more comprehensive) stateful packet filter to TPF. Definitely compatible with TPF . Free 30 day trial available.

"Hardware" router - cheap, very easy to configure, excellent security, low power usage. e.g. Netgear, Linksys, ZyXEL, etc.

Personally, I prefer the *nix option. After all it's secure, completely configurable and free! However it involves the most "involved" configuration of available options. Winroute is an excellent product and it's feature list and ease of use are in it's favour. The hardware router option is the easiest to configure. Once installed you will probably never touch it again....

If you want to stick with ICS, give Tiny tech support a try as I'm sure they deal with similar queries frequently.

[text was edited by author 2001-07-27 21:59:44]

said by PapaDos:

---

TPF has a forum on Yahoo
»groups.yahoo.com/group/t ··· firewall
Try to get info there...

---

Thanks for the tip. I looked through the archives and found contradictory information. I believe that the latest version of tiny breaks compatibility with ICS in some situations, but nobody seemed to be able to fix it. The FAQ says it's compatible but more than one user argued convincingly that it's not.

I didn't read this thread very carefully, but it looks as if you've missed one security concern.

Yes, ICS is MS's NAT implementation for Win9x, and yes it protects the machines behind it by allowing them to have private, non-routable addresses, but the machine that is RUNNING ICS will still have a PUBLIC IP address, and THAT machine may be vulnerable to outside influence.

If you dedicate the ICS machine to only that function, and don't use it as a workstation, then fine, you've got NAT.

But I think it's way cheaper to pick up a nice SMC Barricade for $50 or so. And then just put Tiny or ZA on each workstation.

-- B

I tried your suggestion of Winroute Lite. However I made the mistake of installing it over ICS on the host. Winroute reported "buggy ICSHARE driver" on loading and wouldn't configure. I removed ICS and still couldn't get Winroute working. I uninstalled Winroute and loaded up ICS again. On boot I got a "buggy Icshare driver" warning even though Winroute had supposedly been completely uninstalled. The message was from wrdrv.sys which I found in c:\windows\system; so I removed it. Next boot windows reports that wrdrv.sys referenced in the registry or in system.ini cannot be found. I looked in MSCONFIG for startup options... none there. Searched registry and found it way down in another part of the registry. Got rid of the entry and finally I could surf the net again. With wrdrv.sys loaded connectivity was impossible. Personally I think a program that can't uninstall properly has no right to call another driver "buggy." Sure it was my fault to try to install it over ICS, but it should have just refused to install instead of making a mess.

Yesterday, for unknown reasons, ICS stopped working even though neither TPF nor Winroute was installed. I was able to ping from the client outside, but could not resolve names. I tried every DNS configuration I could, with no joy. After tearing my hair out all day, I gave up on ICS and installed AllAboardSE which got my client connected again in about five minutes.

It seems like a solid program except it doesn't stealth NetBios like ICS. I closed NetBios by unbinding TCP/IP and all is well but I still have no firewall. I liked the features of TPF so much that I'm considering trying it again. Do you know if it is compatible with AllAboard?

I use ICS, and have done so since Nov 00, No problems at all, I have tried serval firewalls over that time, ZA, ZAP, TPF, Sygate, McAfee,Atguard, and Look N Stop, I decided on Look N Stop, It works great with ICS, and I get complete stealth on every test I have taken, on both the client and the host. Look N Stop is on my host Atguard is on my client. I never could get TPF nor ZAP to get complete stealth on my client, Both can cover the host completely, but not the client.

said by B:

---

Yes, ICS is MS's NAT implementation for Win9x, and yes it protects the machines behind it by allowing them to have private, non-routable addresses, but the machine that is RUNNING ICS will still have a PUBLIC IP address, and THAT machine may be vulnerable to outside influence.

If you dedicate the ICS machine to only that function, and don't use it as a workstation, then fine, you've got NAT.

---

ICS / NAT seperates two networks on one NIC, the ICS host is effectively behind NAT just like the clients. The machine that is running NAT has two IP addresses, all traffic for the host is routed by NAT before the OS gets it on it's private interface. Tiny works at a very low level and still sees incoming "public traffic" on only the private interface.

said by B:

---

But I think it's way cheaper to pick up a nice SMC Barricade for $50 or so. And then just put Tiny or ZA on each workstation.

---

Maybe not cheaper since ICS is "free", but definitely a better solution.

> NAT has two IP addresses, all traffic for the host is routed by NAT before
> the OS gets it on it's private interface.

Well, yeah, except that the machine IS still reachable at its external address, which is my point. Reachable equals hackable. I'd rather not trust a thin layer of protection like that, especially if only one NIC is involved, and especially in Win9x. It's similar to the objection some people have to a personal firewall, but more pertinent in my opinion.

> Maybe not cheaper since ICS is "free", but definitely a better solution.

I was comparing it to a dedicated Win9x ICS machine.

-- B

Oops, sorry about that. Winroute and NAT do not get along nicely. I think removing and re-installing TCP/IP may have helped clear things up afterward...

Winroute is a very good program and, although unfamiliar with allaboard, I think it has a better feature list. TPF was derived from WR's packet filter, which is excellent.

AllAboard seems to be another simple NAT implementation from first sight. I could not find mention of a packet filter, etc. I don't know if TPF is compatible.

Fair enough

said by Vampirefo:

---

I never could get TPF nor ZAP to get complete stealth on my client, Both can cover the host completely, but not the client.

---

If you're running ICS, I don't think the clients need any inbound protection because they are on a private network. If your firewall is showing stealth on the clients, I think you're probably running something other than ICS.

For outward traffic security you might want to look into zonealarm, www.zonealarm.com. They have a free download that can act as a firewall inbound and also monitor and block outbound traffic.

W98 SE, ICS on Host, W98 FE Client. I have a Netgear hub connecting the two with cat5 cable, I only use ICS, that came with MY HP. If I run any online tests, with my client I get complete stealth, If I run any online scans with my host I get complete stealth.

To get stealth on all machines is quite feasible. At the very least ICS will provide "port closed" responses to all scans, etc. Evidently, at least in Vampirefo's case, ICS's default policy seems to be to drop unrequested traffic. Drop or deny makes little difference, both are secure.

A scan (requested by you or otherwise) can only be directed at your public IP (the ICS interface of the host). The packets all fall on NAT and are discarded since they do not have table entries. This is secure whether a closed port response is sent or not.

I use Tiny from time to time to make sure I have no outbound connections after I install new software, and I must say it works flawlessly running on 2K server serving ICS to another win2k machine and a G4. It takes seconds to set up "running on internet gateway" & "use trustfull addresses". The only thing I did find is after the initial install it may take a couple of reboots (all machines) for the internal DHCP characteristics of ICS to prompt for a filter rule.

I've been running TPF for several days now and it seems pretty good and compatible with All Aboard. Unfortunately it does not stealth my ports, but only shows them as closed. Also I'm running a local web server on port 8 and it shows as open. I'm not happy about that.

Any ideas?

TPF is probably not responsible for the status of your ports. My understanding is that All Aboard is a NAT implementation, very similar to ICS. TPF inspects inbound traffic after NAT has taken place (in the case of ICS at least). It seems that All Aboard sends closed port responses to packets with no table entry. If you were to forward ports past AA and then drop the traffic with Tiny, they would be stealthed. Obviously that would be a silly thing to do.

A closed port is no less secure than a stealthed port. Stealth may slow someone's scanner down once in a while but other than that there is very little difference.

I take it you are scanning yourself from an external site? No ports should show as open presuming you have not forwaded them past NAT. Have you allowed inbound traffic to the server from all addresses in Tiny? If so restrict the allowed remote addresses to your local group so that Tiny does not permit external probes. Does Tiny then detect the probes that are apparently making it past NAT?