[fw-wiz] RE: Problem with TCP 1433, conduits and ACLs...

From: Wes Noonan (mailinglists_at_wjnconsulting.com)
Date: 11/26/03

  • Next message: Christopher Hicks: "Re: [fw-wiz] Linux Bridge/Firewall"
    To: <mailinglists@wjnconsulting.com>, <firewall-wizards@nfr.net>
    Date: Wed, 26 Nov 2003 15:59:45 -0600
    
    

    Yes, I had an access group. I had 15 other ACLs on that interface, including
    others for that server, that worked great.

    Thanks.

    Wes Noonan
    281-208-8993
    wnoonan@houston.rr.com
    http://www.wjnconsulting.com

    > -----Original Message-----
    > From: Wes Noonan [mailto:mailinglists@wjnconsulting.com]
    > Sent: Wednesday, November 26, 2003 13:22
    > To: 'firewall-wizards@nfr.net'
    > Subject: Problem with TCP 1433, conduits and ACLs...
    >
    > Had a strange problem last night doing a PIX upgrade. Here is the
    > scenario:
    >
    > 2 PIX515E in failover configuration. Upgraded the PIXOS to 6.3(3) from
    > 6.1(4). Installed new activation key for 3DES (they have UR license). The
    > next step was to convert a bunch of conduits and statics to ACLs.
    >
    > The original statics were "open". IP x to IP y kind of stuff. We converted
    > them to port specific statics. The conduits were also converted to ACLs.
    > Seemed pretty straight forward. When we applied the changes, everything
    > seemed to be working except for one webserver. The server build the web
    > pages from a SQL database running on the internal network. The server
    > would not load any pages and displayed a custom error message that
    > essentially stated "I can't access the database". Every other system
    > worked fine however, and for the real kicker I could telnet from the
    > webserver to TCP 1433 on the SQL server and get the SQL session to come
    > up.
    >
    > The original conduit/static was as follows:
    > static (inside,dmz) 172.16.11.134 172.16.4.134 netmask 255.255.255.255 0 0
    > conduit permit tcp host 172.16.11.134 eq 1433 host 172.16.8.101
    >
    > The new ACL/static was as follows:
    > static (inside,dmz) tcp 172.16.11.134 1433 172.16.4.134 1433 netmask
    > 255.255.255.255 0 0
    > access-list dmz_ingress_01 permit tcp host 172.16.8.101 host 172.16.11.134
    > eq 1433
    >
    > In looking at the logs, I could see the hit count on the ACL increasing. I
    > could also see the sessions being created, but I never saw any data
    > passing. I added the "log" option to the ACL as well as putting an
    > explicit "deny ip any any log" entry and never saw anything that indicated
    > why the system wouldn't work. I was not running the sqlnet fixup on that
    > port number.
    >
    > I am pretty much at a loss for what the problem was. In the end we decided
    > to roll back the ACLs for the DMZ and put the old conduits back in place
    > with the new static statements. As soon as we did that, it started working
    > fine. Clearly there seems to be an issue with how the PIX is handling the
    > ACL traffic as opposed to the conduit traffic, but I can't see what that
    > might be. TIA.
    >
    > Wes Noonan
    > 281-208-8993
    > wnoonan@houston.rr.com
    > http://www.wjnconsulting.com

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


  • Next message: Christopher Hicks: "Re: [fw-wiz] Linux Bridge/Firewall"

    Relevant Pages

    • Re: users, "private" groups, and The Unix Way (was, Re: Is it me or is it sudo?)
      ... server so any process running in one of your sandboxes can start ... I'm no X expert but historically the X server needed root privileges ... Which would be nice if I trusted ACLs. ... basic administration to troubleshooting and advanced policy development: ...
      (Debian-User)
    • Re: ASP_WP - driving me mad!!!
      ... It *is* easy -- your customer seems to have futzed with ACLs on their web ... server to make your life difficult. ... I have ensured that my permissions are set correctly. ...
      (microsoft.public.inetserver.iis)
    • POSIX ACLs, NFSv4 and umask discrepancy
      ... NFSv4 Server. ... question is more related to POSIX ACLs and NFS that any FreeIPA special ... FreeIPA uses a default configuration for user creation than plain Fedora ... the server and on the NFS client with umask 022 and the same user I get ...
      (Fedora)
    • Re: Enabling telnet, ftp, pop3 for root...
      ... Many users do not have a functional knowledge of ACLs, of those that do, they find them very confusing, because the repercussions of them leaves something else entirely open for analysis. ... If you want to argue Windows 2k/2k3 Server verses Windows NT Server 3.51, you can argue until you're blue in the face about reasons to upgrade to Windows 2000 Server or 2003 Server over NT 3.51, but I know of at least one place that is still running NT 3.51 as a server. ... This is a bit of an exaggeration, as I don't expect someone wanting help with that system will be on Usenet; however, with UNIX systems, the capability to deal with sudo is more common then the capability to deal with ACLs. ... And there could be performance reasons in the choice of a filesystem, depending on the content of the filesystem. ...
      (alt.os.linux)
    • problems with DHCP & Server Baseline Checklist for Windows NT 4.0 Server -
      ... WinNT 4.0 Server and after doing: ... Apply appropriate registry ACLs ... A number of registry keys need changes to their default ...
      (microsoft.public.security)