Problem with Win XP SP2 Firewall
Page 1 of 4 123 ... LastLast
Results 1 to 10 of 40

Thread: Problem with Win XP SP2 Firewall

  1. #1
    Member
    Join Date
    Jun 2004
    Posts
    37

    Problem with Win XP SP2 Firewall

    I was playing around with this before I ditched SP2... uninstalled it 'successfully'.. though upon rebooting all my apps were "not responding" so I had to format but that's another story. Anyhow, time to get on topic.

    I noticed that the SPI firewall isn't really so 'Stateful'. I made a list of a few "exceptions" as they're called.... being programs that are allowed to recieve inbound traffic on their listening ports. One of these "allowed" apps was the newest version of Yahoo! Messenger [ver. 6.0 Build 1671]. Anyhow, I specified this particular program as an exception and then changed it's "scope..." to only allow ip's and subnets that I CHOSE to to communicate with the program on my end. So, basically, I restricted the access to the program from the outside WAN to only allow the ip's that were required to connect to the service (the msg servers) and a few other ip's that were required to retrieve roomlisting info from the Yahoo! webservers and such.

    When this program is launched, it opens a socket and listens on TCP :5101 by default which is the application's P2P port for PM's -- allowing for potential 'direct connections' only to the people contained on your buddy list. This port was listening, and the rules were applied that nobody but those certain ip's could communicate to me through Messenger. I had a friend that was on my buddylist pm me to test whether or not his ip (being a class A 24.* ip) would be stopped from making a direct connection to me on :5101. As his ip wasn't on the allow list I figured that it would be rejected or I would be prompted that his ip address was trying to make a direct connection to me on TCP :5101.

    Conclusion: It didn't happen and the connection was allowed through, regardless of my "scope..." settings. If this firewall was truly 'stateful' it wouldn't have allowed a full 3-way handshake to be performed with a machine that WASN'T on the allow-list for accepting inbound traffic (let alone full connections) regardless of the application's listening socket for the application. The problem here is the application is 'trusted' so much as an "exception" that it appears that no further stateful inspection is done (if so very little) once the exception status is granted for the app. Too bad I didn't file-a-bug on this one. It's a pretty big one. I guess if I cared enough to have them fix it I would have but I won't ever be using it again. Anybody hoping to rely on this for future security... I wouldn't hold your breath.

  2. #2
    Senior Member
    Join Date
    Jun 2004
    Posts
    460
    everytime i have used the firewall there is an option for "local subnet" or "all IP's"... i just wish there was not a default selection and it forced you to make one (default is local subnet)
    [gloworange]find / -name \"*your_base*\" -exec chown us:us {} \\;[/gloworange] [glowpurple]Trust No One[/glowpurple][shadow] Use Hardened Gentoo [/shadow]
    CATAPULTAM HABEO. NISI PECUNIAM OMNEM MIHI DABIS, AD CAPUT TUUM SAXUM IMMANE MITTAM

  3. #3
    We talked about this on a similar thread the other day and came to the same conclusion. I think it was Negative who said, if memory serves correct, that it blocks inbound but not outbound communication, making it only half effective at best. It also really doesn't like Zone Alarm.

    But we really shouldn't have had our hopes up about this anyway. After all, it is MS...

  4. #4
    Member
    Join Date
    Jun 2004
    Posts
    37
    everytime i have used the firewall there is an option for "local subnet" or "all IP's"... i just wish there was not a default selection and it forced you to make one (default is local subnet)
    Yeah, I agree there too. Weird though as my "default" was different than yours. The default for my SP2 RC2 Firewall (not RC1, I've never even used it) here was "Allow All IP's". Scary thought. I restricted to the local subnet and now that I think about it I believe that that might've actually worked. Can't really remember for sure. If allowing only specific ip's and subnets as inbound traffic to the exception-listed applications actually worked then I might actually think it was alright. It would still be pretty bare-bones but would be something that I could cope with.

  5. #5
    Member
    Join Date
    Jun 2004
    Posts
    37
    We talked about this on a similar thread the other day and came to the same conclusion. I think it was Negative who said, if memory serves correct, that it blocks inbound but not outbound communication, making it only half effective at best. It also really doesn't like Zone Alarm.
    It'll actually block or 'attempt' to block outbound traffic but only if the application ISN'T already on the "exceptions" list. Once it's on there full outbound as well as inbound traffic is allowed to traverse to the application unless set differently... half of which I know doesn't even work. SPI FireWalls are supposed to compile tables for all of the connections that they monitor with connection-based info pertaining to each individual connection... monitor these for changes within the actual stream it's self with the ability to validate the actual packet's payloads unlike Static Packet Filtering... compare the packets to ones previously passed before them... and only allow connections if there's a corresponding entry in their tables that matches the connection attributes to the connection that you initiated first and not the other end. If all of that was taken into account to rate this supposed SPI Firewall... it would for sure get an "F". This might as well be labeled only a Static Packet Filter cuz that's all I've seen it as for the most part.

  6. #6
    So what were they thinking anyway? The XP "firewall" already sucked, so why did they only take a half-butt attempt at improving it? Just to have the appearance of "Hey, look! See, we have a firewall now! We're really good, really!"

  7. #7
    Member
    Join Date
    Jun 2004
    Posts
    37
    Yeah, MS's claim to fame for this supposed "Supercessor" dubbed 'ICF 2' was that it will now monitor BOTH traffic directions.. unlike the original ICF that only monitored inbound and not any outbound. What they won't/don't tell you is that the outbound and inbound monitoring is only good until the exceptions are made... then apparently anything can go as I've found out. I'll stick to Sygate Pro or OutPost Pro for my application-layer firewall and my router w/ NAT + SPI firewall for my network-layer. Both layers are covered, work seemlessly together and they'll actually alert me of, and/or disallow, unsolicited connection attempts!

  8. #8
    Nice. Yeah, I'm probably going to get reacquainted with Sygate when I get home tonight.

  9. #9
    Whoa, calm down -all- of you. Microsoft takes steps towards security and improving the stability of the operating system by giving you more fine tuned controls over the outbound checking... and you bash them for it?

    You sit there and joke about Microsoft and it's lack of security with your friends, and now they do something about it... and you continue to joke about them?

    The entire SP2 package is going to break a -ton- of 3rd party programs because it is now enforcing a ton of OS level security. Shared memory for example, is now under strict OS control rather than being open to applications. The firewall may not block outbound, but it sure as hell does a good job of blocking inbound. Could it be better? It sure could be. But there is a level of balance they have to find so that they won't have a few billion people screaming about how they can not connect to the internet when sp2 is released.

    Seriously guys, reread your posts. Be happy they are taking steps to improve security, and understand that steps towards security happen one step at a time for the sake of stability, and thus to fine tune things it will take them time (just as it did Linux). But don't continue to bash Microsoft on a "damned if you do damned if you don't" just because it's an old habit.


    edit: And if you really want to know, instead of gossip, the facts behind ICF 2, I suggest reading the whitepaper about the deployment of ICF along with it's settings:

    http://www.microsoft.com/downloads/d...displaylang=en

  10. #10
    Oh, thanks a lot pooh, you just completely ruined my posts! Geez! Ruin all my fun... I guess I can see that point, at least it's a step forward. But as a lame attempt to argue with the master here, my point is that it's Microsoft -- Surely they can whip up something far superior, you'd think? Why aren't they? Sure, it's an improvement, but we all know they're capable of doing more, so what's holding them back?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides