Loading ...
Sorry, an error occurred while loading the content.

Anybody using more than 15 post requests on vim.sf.net within 4h?

Expand Messages
  • Marc Weber
    Reason: See vim-dev: vim.sf.net was scanned by a bot testing for vulnerabilities. Most vulnerabilities require to store JS code in fields, or creating new
    Message 1 of 3 , Apr 30 9:48 PM
    • 0 Attachment
      Reason: See vim-dev: vim.sf.net was scanned by a bot testing for
      vulnerabilities. Most vulnerabilities require to store JS code in
      fields, or creating new users etc.

      For this reason I assumed that a causual user does only update 5 plugins
      in one session + logging in. Thus having a limit of 15 post requestst
      within 4h might make sense.

      Do you feel this is too strong?

      The error message will tell you to wait or write to the mailinglist..

      Marc Weber

      --
      --
      You received this message from the "vim_use" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_use" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Linda W
      ... There a mess of things you *can* do, but I thought such scans were so common place these days as to be *almost* considered normal or part of the background
      Message 2 of 3 , May 17, 2013
      • 0 Attachment
        Marc Weber wrote:
        > Reason: See vim-dev: vim.sf.net was scanned by a bot testing for
        > vulnerabilities. Most vulnerabilities require to store JS code in
        > fields, or creating new users etc.
        >
        > For this reason I assumed that a causual user does only update 5 plugins
        > in one session + logging in. Thus having a limit of 15 post requestst
        > within 4h might make sense.
        >
        > Do you feel this is too strong?
        >
        > The error message will tell you to wait or write to the mailinglist.
        >
        There a mess of things you *can* do, but I thought such scans were
        so common place these days as to be *almost* considered normal or
        part of the background noise.

        maybe limit POSTs to 1 per 2-minutes? Thats sorta slow for a
        vulnerability scan.

        If they really want to target you, a 4h wait is nothing... in internet
        time for
        a automated bot that may run for months looking for targets.

        Seems like the shorter retention period might make keeping track of
        "rates" simpler
        (not as much to store?)...

        How about setup some script generated, hidden dummy links
        that are dynamically generated and don't respond -- (not 404's but
        just keep the connection open and don't respond... force them to timeout).

        The script could generate millions of dummy places to 'post', -- all that
        do nothing. Seems like that would cause them more problems than a 4hr
        wait.







        --
        --
        You received this message from the "vim_use" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_use" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Marc Weber
        Hi Linda W, Thanks for your input we don t want to protect against people who really want to get us - because they always will. And if this happens - we also
        Message 3 of 3 , May 17, 2013
        • 0 Attachment
          Hi Linda W,

          Thanks for your input

          we don't want to protect against people who really want to get us -
          because they always will.
          And if this happens - we also have to start reviewing each code of viml
          at vim.sf.net ..
          Luckily I don't know about trojans or the like yet (which does not mean
          that they don't exist)

          > How about setup some script generated, hidden dummy links
          > that are dynamically generated and don't respond -- (not 404's but
          > just keep the connection open and don't respond... force them to timeout).
          That will not be a problem either if they really want to get vim.sf.net

          Attackers may use stolen hardware - the game is always unfair.

          The idea was to protect against random bots who don't know what they are
          doing - just trying to spam the world.

          Such hidden links indeed could be used
          to detect both:
          - google (which might cause a bader rating, because site loads slowly)
          - attackers

          for google like bots rel="nofollow" could be tried.
          My goal ends at "make attackers have to use their human brain to attack
          vim.sf net" - otherwise keep out and the database clean.

          If Bram or John have additional notes I guess they'll reply, too.

          Marc Weber

          --
          --
          You received this message from the "vim_use" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_use" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        Your message has been successfully submitted and would be delivered to recipients shortly.