headers
roger shannon | 1 Jun 2005 01:21

Re: COZA: FAIL: Nameserver information (FQDN/IP) mismatch


On Tue, 31 May 2005, Charles Leaver wrote:

> Haha. I've heard it being discussed as ISPA meetings for a while now.

perhaps when you stop smugly haha'ing, you'll realise that not everyone
who runs DNS servers or registers domains is an ISP or part of the ISPA.

your comment is therefore as senseless and irritating as PGP signing posts
to an email list.

haha

-rgs

=====================< IOZ >======================
 To unsubscribe, mail <majordomo@...>
with "unsubscribe ioz" in the body of your message
==================================================
Permalink | Reply | 0 comments |
headers
Gregory Massel | 1 Jun 2005 01:18
Picon

Re: COZA: FAIL: Nameserver information (FQDN/IP) mismatch

>>I've heard it being discussed at ISPA meetings for a while now.
>>
> I stand corrected - Durban is a separate planet from the ZA internet, we 
> do not enjoy the benefits of taking part in such meetings. Looking at all 
> of this I think we should apply for our own SLD too and run it properly.

ISPA currently does not have access to facilities that provide a 3-way 
videoconference, however, if you know of anyone who can provide meeting room 
facilities with 3-way videoconferencing in three cities at an affordable 
rate, please drop me a mail privately with the contact details and I will 
definitely investigate this further.

There may also be a way to at least teleconference Durban attendees if not 
videoconference. We have done this in the past with smaller meetings (eg. 
management and regulatory committees). There are some technical limitations 
that make this trickier with too many teleconferenced parties, however, on a 
small scale it may be possible. Relevent members should contact the ISPA 
secreteriat sufficiently in advance of the meeting they wish to attend 
remotely to allow time for special arrangements to be made.

ISPA is also planning a roadshow for its members in Durban in the next month 
or two and I would certainly encourage our Durban members to attend and 
discuss suggestions at the roadshow.

--Greg 

=====================< IOZ >======================
 To unsubscribe, mail <majordomo@...>
with "unsubscribe ioz" in the body of your message
==================================================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory Massel | 1 Jun 2005 01:27
Picon

Re: Brute Force attempts

> Does anyone on the list have any recommendations on addressing brute force
> attempts to ssh into a server, there is not much one can do except block 
> IP
> address ranges from International sites or IP address ranges, however in
> this case the attempt was from a local network which was very easy to 
> trace
> and I really wish to take the issue further.

Barry's suggestion of implementing key based auth will help render a brute 
force attack useless, but not prevent it, and Rob's suggestion of 
implementing IP filters is extremely tricky for people who travel and/or are 
forced to use dynamic IP's on large shared pools (eg. ADSL users).

I would really like to see some suggestions based along the lines of 
back-off timers eg. SSH server sleeps for an increasing duration between 
each failed login before responding "invalid password" and/or limits the 
number of simultaneous connections from a single IP address unless the other 
connections are already authenticated.

The best suggestion I can offer in this regard is to look at 
http://sourceforge.net/projects/sentrytools/

"The Sentry tools provide host-level security services for the Unix 
platform. PortSentry, Logcheck/LogSentry, and HostSentry protect against 
portscans, automate log file auditing, and detect suspicious login activity 
on a continuous basis."

Maybe someone who is more familiar with these (I've never used them) can 
provide some input.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Andrews | 1 Jun 2005 04:58
Picon

Re: Brute Force attempts

On Tue, May 31, 2005 at 10:30:09AM +0200, Horace Oliver wrote:

> Does anyone on the list have any recommendations on addressing brute force
> attempts to ssh into a server, there is not much one can do except block IP
> address ranges from International sites or IP address ranges, however in
> this case the attempt was from a local network which was very easy to trace
> and I really wish to take the issue further. 

knockd is great for this. It allows you to use eg uptables to block ssh
completely, and only open the ssh port (temporarily) when it sees the
appropriate signature from the knockd client.

=====================< IOZ >======================
 To unsubscribe, mail <majordomo@...>
with "unsubscribe ioz" in the body of your message
==================================================
Permalink | Reply | 0 comments |
headers
Michael L Griffin | 1 Jun 2005 05:48
Picon
Gravatar

Re: COZA: FAIL: Nameserver information (FQDN/IP) mismatch

Greetings

  Ensuring that the destination IP of an any FQDN used in a registration has 
a valid forward and reverse is perfect but insisting that the FQDN be the 
same as the reverse is not.

  So instead of unilaterally deciding for the rest of South Africa (on whose 
behalf they handle CO.ZA registrations if you come down to it and do not own 
it) and creating havoc, why not simply ensure that all destination IP's have 
a valid forward and reverse and that the FQDN is an A record?  It should be 
a simple process to repair the checks if they are broken.

  My suggestion, go back to the previous way of doing things but simply 
correct the short comings. Easy enough?

Regards
Michael
----- Original Message ----- 
From: "Alan Levin" <alan@...>
To: <iforbes@...>
Cc: "'IOZ List'" <ioz@...>
Sent: Tuesday, May 31, 2005 6:42 PM
Subject: Re: [IOZ] COZA: FAIL: Nameserver information (FQDN/IP) mismatch

Hi Ian,

On 31 May 2005, at 17:49, iforbes@... wrote:
> Why don't you just undo what you've done. It will be take much less
> effort than explaining why you are supplying something to your
> customers that they do need and do not want.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael L Griffin | 1 Jun 2005 06:06
Picon
Gravatar

Re: COZA: FAIL: Nameserver information (FQDN/IP) mismatch

Greetings

  Simply laughing it off would be a bad thing to do as Uniforum does NOT own 
co.za - the administer it on behalf of the rest of South Africa.

  The reverse is not the problem, the dictatorial insistence that the 
registration point to the reverse as apposed to a more definition FQDN is 
the problem.

  Who would we complain to about Uniforum's handle of the CO.ZA name space? 
Seeing that it affects every single South African who has access to the 
internet and belongs to South Africa?  Who is the governing body and what 
are their guidelines for dispute resolution?

Regards
Michael
----- Original Message ----- 
From: "Charles Leaver" <charles@...>
To: <iforbes@...>
Cc: <ioz@...>
Sent: Tuesday, May 31, 2005 9:36 PM
Subject: Re: [IOZ] COZA: FAIL: Nameserver information (FQDN/IP) mismatch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

iforbes@... wrote:
> Why don't you just undo what you've done. It will be take much less
> effort than explaining why you are supplying something to your
> customers that they do need and do not want.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ant Brooks | 1 Jun 2005 08:14
Picon

Re: COZA: FAIL: Nameserver information (FQDN/IP) mismatch

Michael L Griffin wrote:
>   Who would we complain to about Uniforum's handle of the CO.ZA name space? 
> Seeing that it affects every single South African who has access to the 
> internet and belongs to South Africa?  Who is the governing body and what 
> are their guidelines for dispute resolution?

The ZA Domain Name Authority is, at least in theory, the authority
governing the .ZA ccTLD. In practice the ZADNA has not yet licensed
any registries or registrars, so their influence over UniForum SA
is, at least at this point in time, questionable.

Nonetheless, if anyone is unhappy with UniForum SA's handling of
this particular issue, I'd suggest visiting the ZADNA web site
and using the contact information there to lodge a complaint with
the authority: http://www.zadna.org.za/.

Ant.

--

-- 
Slettnut (n.): Something which goes round and round but won't come off.

=====================< IOZ >======================
 To unsubscribe, mail <majordomo@...>
with "unsubscribe ioz" in the body of your message
==================================================
Permalink | Reply | 0 comments |
headers
Keith Waters | 1 Jun 2005 08:54
Picon

Re: COZA: FAIL: Nameserver information (FQDN/IP) mismatch

> I stand corrected - Durban is a separate planet from the ZA internet, we 
> do not enjoy the benefits of taking part in such meetings. Looking at 

How about flying or driving to JHB for the meetings?    

Keith

=====================< IOZ >======================
 To unsubscribe, mail <majordomo@...>
with "unsubscribe ioz" in the body of your message
==================================================
Permalink | Reply | 1 comment |
headers
William Stucke | 1 Jun 2005 09:21
Picon

RE: COZA: FAIL: Nameserver information (FQDN/IP) mismatch

>> I stand corrected - Durban is a separate planet from the ZA internet, we
>> do not enjoy the benefits of taking part in such meetings. Looking at

> How about flying or driving to JHB for the meetings?

Subsidised by ISPA, BTW.

Kind regards,

William Stucke
ZAnet Internet Services (Pty) Ltd
+27 11 465 0700
William@...

-----Original Message-----
From: owner-ioz@...
[mailto:owner-ioz@...]On Behalf
Of Keith Waters
Sent: 01 June 2005 08:55
To: ioz@...
Subject: Re: [IOZ] COZA: FAIL: Nameserver information (FQDN/IP) mismatch

> I stand corrected - Durban is a separate planet from the ZA internet, we
> do not enjoy the benefits of taking part in such meetings. Looking at

How about flying or driving to JHB for the meetings?

Keith

=====================< IOZ >======================
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hendrik Visage | 1 Jun 2005 10:40
Picon

Re: COZA: FAIL: Nameserver information (FQDN/IP) mismatch

On 6/1/05, Russell Cloran <russell@...> wrote:
> Hi,
> 
> I'm not sure why you replied to this off-list...

Just call it GMAIL.
> 
> On Wed, 2005-06-01 at 00:51 +0200, Hendrik Visage wrote:
> > > The problem is well documented by Dan Bernstein at
> > > http://cr.yp.to/djbdns/notes.html
> >
> > Dan Bernstein have been tainting the real issues with his personal views  IMO.
> >
> > He might make valid points, but sometimes missing the plot :( His
> > explanation there I can at least give one example how with the right
> > implementation inside the  DNS servers, the damages will be near zero
> > with the glue records.
> 
> Please, do share your example?

Re valid points etc.: Refer to qmail's distribution license, and his
total ignorance of things like the Linux file layout/hierarchy
standard etc. not to mention overdesign/kill (IMO) of qmail, but again
that is subjective.

If you refered to DNS, the way DNS get's information regarding NS
record's A records and the whole cache poisoning, it all related to
how/when the dns server use and supply the glue record. If you receive
the glue record as part of a NS lookup/request, it should be marked
accordingly and only used for that domain it refers to. Memory abuse
(Continue reading)

Permalink | Reply | 1 comment |

Gmane