Text 26626, 151 rader
Skriven 2015-05-02 07:54:40 av mark lewis (1:3634/12.0)
  Kommentar till text 26597 av NANCY BACKUS (1:123/140)
Ärende: IDS/IPS rules
=====================
 On Fri, 01 May 2015, NANCY BACKUS wrote to MARK LEWIS:

 ML> yes it could... especially if a BBS is employing similar 
 ML> protections like those used over here... the key factor is to not 
 ML> make X connection attempts within Y time period...

 NB> I was specifically asking about your bbs...  And, I still don't
 NB> really know why your bbs thought I was making repeated attempts,
 NB> since all I could see from my end was just the one attempt that
 NB> failed by timing out... 

your software is/was apparently making multiple attempts even though it didn't
appear that way on your end of the terminal... that's the only thing i can
see... i think this is also the same problem we had before which lead me to
doing the white list thing... it is almost like a dialup terminal program but
doesn't set the redial attempts in the same way because they are handled in the
tcp stack (aka networking drivers)...

 ML> hackers and skiddies trying to brute force their way in just run
 ML> scripts and try to test as many names and password combinations as
 ML> possible... 

 NB> Which still leaves me wondering, since I didn't even get to the
 NB> point of being able to enter name and password when I was being
 NB> blocked. 

the blocking reaction time when an alert is raised is pretty quick... less than
one second... TCP/IP connections are made like this...

1. client sends SYN packet to server's destination port w/ segment
   sequence number set to random number A.

2. server responds with SYN-ACK packet to client source port with
   segment acknowledgement number A+1 and segment sequence number set
   to random number B.

3. client responds with ACK packet to server's destination port with
   segment sequence number A+1 and segment acknowledgement number B+1.

that's known as the 3-way handshake...

the IDS/IPS rules are looking for the SYN packet in step one to be sent more
than X times in Y time period... a connection needs only one 3-way handshake so
there should not be another SYN packet sent until after the TCP timeout
elapses... timeout value determination varies from poor to good... a client may
assume that 5 seconds is an adequate timeout period in which case it will
retransmit the initial SYN packet every 5 seconds... that value may be a poor
value as shown next...

if an IDS/IPS rule looks for 5 SYNs within 60 seconds, that's one SYN every 12
seconds, it will fire when the 5th SYN arrives if the timer is less than 60...
a client with a timeout value of 5 seconds will violate this rule in 25 seconds
(5 SYNs every 5 seconds)...

the defaults for the four major operating systems are

      OS    : SYN secs
    ===================
    os/2    :  30
    windows :  72
    mac osx :  75
    linux   : 180

they will not try sending another initial SYN packet until after the SYN secs
timeout... that value has several different names in the various OSes... i've
used SYN secs here for ease...

IIRC, you are using DOS and the watcom tcp stack... the settings for it are in
the wattcp.cfg file?? if so, please check the optional values for SOCKDELAY,
INACTIVE and DATATIMEOUT... according to the open-watcom project on github,
they should be 30, 0 and 120 by default respectively... i think SOCKDELAY is
the initial SYN timeout which is 30 seconds... if these items are not set in
your wattcp.cfg file, they should be using the mentioned defaults if they are
the same as the newer stuff used today... i can look deeper by digging into the
captured network packets which the IDS/IPS pulls every time it raises an
alert...

 ML> [...] the hard thing there, that many don't reallize, is that the
 ML> actual network traffic still has to travel through via one core...
 ML> anyway, it gets real deep real quickly...

 NB> I almost follow... but yes, real deep real quick...  

hopefully the above 3-way handshake isn't too hard to follow... 

 NB> Fwiw, I had a scare night before last, when I had another timed out
 NB> attempt... fortunately, when I tried later that night I got a quick
 NB> connect...  I was afraid that you were blocking me again, but when
 NB> I checked it was still the IP that you supposedly had white-listed.
 NB> I guess there must be other reasons for a slow connection that gets
 NB> me timed out besides your end thinking I'm trying to do a brute
 NB> force attack...  ;0

yeah, if there's a lot of traffic flowing in my pipe line or there's a lot of
traffic clogging a router between us, it is possible that there may be a
timeout... you might have also caught one of the server's random reboots... it
does one every few days to try to clear out the cruft...

 NB> And, another fwiw... I had been having lots of the timed-outs back
 NB> before you got the new line in... and apparently it wasn't because
 NB> of the blocking, even though I think we went through a few IP
 NB> changes during that time...

right... those timeouts were due to noisy lines... like trying to talk on a
telephone land line that's full of static and popping...

 NB> Is this "protection" something that got laid aside when you were 
 NB> having other issues...?

no... the IDS/IPS stuff has been in place for a long time... i don't recall
when the telnet brute force rule was last tweaked to catch more of those
skiddies but it was well over a year back...

 NB> And, just after the new line went in, I was doing just fine for a 
 NB> few days before I got zapped...  I'm still just scratching my head 
 NB> trying to make sense of it all...  ;) 

yeah, i don't know what happened... i'll have to go back and see if i can
correlate my notes and try to find a time line for this... i wasn't aware that
you had been able to connect with the new lines in place... i changed the news
about 30 minutes after they had gone live but don't recall when i played my
first (next??) move in scrabble after that... i do recall there were several
days that passed and i figured you were on another little trip somewhere...

recipe? hummm... 9:38 so let's see what recipe 938 is...

MMMMM----- Recipe via UNREGISTERED Meal-Master (tm) v8.02
 
      Title: PERFECT APPLE BUTTER
 Categories: F, R, U, I, T
      Yield: 1 servings
 
      6 c  Sweet apples, peeled, sliced
      1 tb Ground cinnamon (optional)
      1 c  Apple cider
 
  Place apples and cider in heavy saucepan over medium heat. Cook,
  stirring frequently, until mixture comes to a boil.  Lower heat and
  simmer, stirring frequently, for about 1 hour, or until apple slices
  have disintegrated and butter is thick.  Remove from heat. Stir in
  cinnamon, if desired. Pour into hot sterilized jars, leaving 1/4 in.
  headspace.  Cap and process in 10-minute boiling water bath.  Makes 4
  1/2 pint jars.
 
MMMMM

dang... an you don't/can't do apples... sorry :( 

)\/(ark

 * Origin:  (1:3634/12)