Text 10377, 90 rader
Skriven 2013-09-23 09:52:50 av mark lewis (1:3634/12.0)
  Kommentar till text 10372 av Michiel van der Vlist (2:280/5555)
Ärende: Connecting 2:280/5555...
================================
 On Mon, 23 Sep 2013, Michiel van der Vlist wrote to mark lewis:

 MvdV>> Six seconds... don't try to weasel yourself out of this by
 MvdV>> claiming a clock discrepancy.

 ml>  ;) it is funny how the logs carry info that some just don't seem 
 ml> to see ;)

 MvdV> Speaking about clocks, this is an interesting one:

 MvdV> % 01:16:08  (395) BinkP: ZYZ Bart Verhaeghe
 MvdV> % 01:16:08  (395) BinkP: LOC Oostkamp
 MvdV> % 01:16:08  (395) BinkP: PHN bbs.tsoh.be
 MvdV> % 01:16:08  (395) BinkP: NDL 300,CM,MO,IBN,ITN,IFC
 MvdV> % 01:16:08  (395) BinkP: TIME Tue, 17 Sep 2013 23:16:43 +0200 

 MvdV> My local time is CET+DST, which is UTC+2. His binkp server also
 MvdV> reports UTC+2 as his local time, but his clock is actually at
 MvdV> UTC. Two hours off! 

i've seen similar happen on a firewall product i support... they get the
timezone right and then insist on setting the BIOS clock to their local time
which then causes the machine to not adjust the clock backward when it tries to
set it to UTC time... the machines operate on UTC and only display the time as
local time... logging may be either local or UTC depending on the program... i
think i said that correctly... the cause is the machine adjusting the clock to
UTC... if it is already at UTC when the local timezone is set, then the clock
gets moved afield...

 MvdV>> Oh, don't worry, I get the point. And I think others do as
 MvdV>> well...

 ml> sounds like someone either unplugged the cable between their 
 ml> router and their switch/system or they turned it off for a minute 
 ml> or more ;)

 MvdV> Not at my end...

exactly! especially since you didn't know when he was going to try ;)

 ml> of course, one cannot discount the ISP working on the lines or
 ml> equipment and causing the outtage...

 MvdV> It can not be ruled out, but then again if it were at my ISP,
 MvdV> Ward would have gotten some other error than a  DNS resolving
 MvdV> error.

possibly... but that depends on your name service, how long it retains entries
after an update to the entry and how often entry updates have to be made to
keep an entry alive...

 MvdV> In the case of Bart, he would not have gotten a password error. 

that's true :)

 ml> most folks won't ever notice because they use some little 
 ml> black-box device which doesn't log or notify them about the 
 ml> connection ups and downs... that's one of the things i do like 
 ml> about my perimeter firewall/router device... it does log all that 
 ml> and a whole lot more :)

 MvdV> Now that you mention firewalls, my educated guess is that if I 
 MvdV> were to hammer your system with this:

 MvdV> % 01:16:08  (395) BinkP: 2:292/907@fidonet.org
 MvdV> ? 01:16:08  (395) Remote sent incorrect password.

 MvdV>      ... each and every minute for two days, I WOULD have a
 MvdV> problem connecting you for some time to come as my IP would be
 MvdV> blocked by your firewall. Wouldn't it?

yes, i believe so... anyone doing that would have the same problem and it may
not take any more than 5 or 10 minutes... it could take even less time than
that if there were more than one attempt per minute... if you change IPs and
kept doing it, it would simply apply the block to each new IP...

in any case, once the block went into effect, it would appear on your end as if
the system simply didn't exist... the packets would be dropped into the
bitbucket and your end would have to wait for the configured timeout period to
elapse... one of the goals of this is to slow down the 'attack'...

the situation with my firewall is that once blocked, there it a expiration time
given... each additional attempt to connect that raises another alert extends
that expiration time... depending on certain things, the extension could be
linear or exponential... based on the severity of the attack and other
factors...

)\/(ark

 * Origin:  (1:3634/12)