Announcement

Collapse
No announcement yet.

Just gotta rant...

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Just gotta rant...

    Ok, we have this customer at Tile-based-game Pizza. He's kind of a know-it-all, arrogant bastard.

    TLDR version: Dude puts out device in a mode where blocking can't be guaranteed, then complains about it not blocking well enough. Working as designed, but somehow, a manager convinces the dev team to change the design and then he still complains it doesn't work well enough.

    Technical Mumbo Jumbo
    You would think then, that since blocking malicious traffic is important, he would deploy our device in bridge mode so that blocking can be 100%. In this mode, the network path to the server passes directly through our device. If the device detects badness, it drops it, no fuss, no muss. The packets never reach the server, instead vanishing forever into the bit bucket.

    Instead he puts the thing in sniffing mode. The device is not deployed directly in line with the server. Instead, a network tap sends us a copy of every packet. In this mode, blocking is accomplished by giving us a connection to the server, so we can send RESET packets to the server, pretending we're the end user trying to close the connection.

    This results in a race condition: will the malicious user's packets reach the server first, or will our reset packets? Due to this, blocking is absolutely not guaranteed in this mode.
    /Technical Mumbo Jumbo

    Begin rant!

    And then he complains about blocking performance being poor. Well gee, ya think? Of course he understands that blocking in sniffing mode is not guaranteed, but recently it's been terrible!

    Um, yeah? Whaddya want me to do about it? We've gone on webex, proved we're doing what we're supposed to do, and you're still crying. Maybe you should've been on one of those webexes yourself, instead of sending your flunky (who totally accepts our explanations, btw) to do it.

    Unfortunately crybaby is buddies with one of our managers (possibly just in his head), and adds her to the email thread and works with her after (my) hours. Fine with me. Hands off. I got the OK from my manager. Even though the case is in my queue, we let the other manager work it, I don't get involved anymore. She basically takes over the case and even escalates it to the devs.

    And they take it. They actually generate a patch for him. We implement a design change for him, because reasons, I guess. We changed our behavior in certain situations, to increase the number of reset packets we generate in our attempt to block. This is not a bug fix, the device was working as designed. We changed it for him.

    And then the bastard whines again, crying boohoo, he applied the patch but it's still not blocking very well. And he has the gall to ask "what are next steps?"

    You want next steps you special snowflake? Try using a mode where blocking is guaranteed!
    Supporting the idiots charged with protecting your personal information.

  • #2
    This results in a race condition: will the malicious user's packets reach the server first, or will our reset packets?
    The malicious packets will get there first - almost guaranteed. After all, they must go past the sniffing point *before* the reset packets can be generated.

    Comment


    • #3
      You'd be surprised, actually. I set up what I thought must be the worst possible situation--blocking port, sniffing port, and web server all on the same hub (ok, not really: ESXi vswitch with promiscuous mode on, behaves like a hub tho)--and blocked more than my fair share of attacks. :O

      ...which is part of why I think this customer is so full of it.
      Supporting the idiots charged with protecting your personal information.

      Comment


      • #4
        I don't understand

        Does sending all the packets thru the blocking device cost more money (data charges) or cause a lot of delays, or limit the number of packets that can be processed in a busy day?

        Because if not, why not just use the solutions that does the best job of blocking bad packets? Ego?

        Comment


        • #5
          Not really. Two main factors: laziness and fear.

          Lazy: It's easy just to plug in a network tap and be done with it. Less so to properly integrate it inline.
          Fear: With the device inline, it's possible for it to cause an outage (and it certainly will for at least a few seconds whenever it's rebooted, which should be done once per quarter when patches are released).
          Supporting the idiots charged with protecting your personal information.

          Comment


          • #6
            Excuses

            Quoth otakuneko View Post
            Not really. Two main factors: laziness and fear.

            Lazy: It's easy just to plug in a network tap and be done with it. Less so to properly integrate it inline.
            Fear: With the device inline, it's possible for it to cause an outage (and it certainly will for at least a few seconds whenever it's rebooted, which should be done once per quarter when patches are released).
            Those are some of the worse excuses I have ever seen to not proper protect a business data stream.

            Comment


            • #7
              Quoth otakuneko View Post
              You'd be surprised, actually. I set up what I thought must be the worst possible situation--blocking port, sniffing port, and web server all on the same hub (ok, not really: ESXi vswitch with promiscuous mode on, behaves like a hub tho)--and blocked more than my fair share of attacks. :O

              ...which is part of why I think this customer is so full of it.
              I know the manner of device of which you speak, and the manner of customer, for I have them too, even though the boxes we sell should be impervaious to that kind of problem. I share your assessment.

              I started finding ways to work in "oh, you're that place that isn't using the box in line, right?" into any given conversation. Most of them get the idea.

              My cynical guess is that while troubleshooting said customer, you/other manager found he has, among other things:
              ****d up his span port settings and is stuffing 2x of traffic down 1x of link,
              fiddled with the rule base,
              turned off anything he doesn't understand,
              amended (ie broken) half the other settings,
              possibly with the side effect of slowing the box's performance so resets come later than they would normally,
              and now wants to know why it doesn't work better.

              How'd I do?


              Maybe your next upgrade should include a "Put it back how you found it" button

              Comment


              • #8
                Quoth bunrotha View Post
                My cynical guess is that while troubleshooting said customer, you/other manager found he has, among other things:
                ****d up his span port settings and is stuffing 2x of traffic down 1x of link,
                fiddled with the rule base,
                turned off anything he doesn't understand,
                amended (ie broken) half the other settings,
                possibly with the side effect of slowing the box's performance so resets come later than they would normally,
                and now wants to know why it doesn't work better.

                How'd I do?
                Using wildcards is cheating.
                I AM the evil bastard!
                A+ Certified IT Technician

                Comment

                Working...
                X