Re: Comments on: draft-ietf-opsec-current-practices-03.txt

[Warren Kumari <warren@kumari.net>]

On Jun 14, 2006, at 10:37 AM, Merike Kaeo wrote:

> Thanks and yes, if you have time to continue I'd appreciate it.   
> All comments are welcome and you are finding quite a few things I  
> should fix.  The more complete and the less spelling errors the  
> better  for this next version :)  (here's hoping you have another  
> boring meeting soon)

Nice to see that someone profits from my pain.... :-)

Here are some more thoughts / comments....

-----------------------------------------------------------------------
Notes on: draft-ietf-opsec-current-practices-03.txt (Part 2)

General:

I may have missed it, but I saw no mention of route databases (eg  
RADB) -- some people use this for building filters.

I may have missed it, but perhaps mention could be made that ISPs  
have no desire to be the great Internet firewall -- if a worm comes  
out that runs over port X, the correct response is NOT to filter X --  
if a specific customer requests filters, their connection can be  
filtered, but applying L4 filters on a backbone is not (nor should  
be) an ISPs job.


Section 2.2.2:
"In some deployments, The AAA servers used for in-band management" --  
spelling: the

Section 2.2.4:
"Some providers feel that this operational impact exceeds the  
security necessary and instead use Telnet from trusted inside
   hosts (called 'jumphosts') to manage those devices." -- "or  
bastion hosts". Possibly also mention that this is inherently less  
secure (snooping is not possible). Many providers also only allow SSH  
from bastions.

Section 2.3.2:
"Dial-in access is deployed as a backup if the network
   is not available." -- this is often a weak point in security --  
many providers use dial-back, encrypting and / or OTP modems.

Section 2.4.2:
"Most ISPs consider layer 4 filtering useful but it is only
   implemented if there is no performance limitations on the  
devices." -- this is very vague -- most ISPs will only deploy layer 4  
filtering if no other options exists (it is a admin nightmare). Also,  
perhaps "if there is no performance limitations on the devices" can  
be reworded to "if possible" (nit-picking here, but if a device can  
L4 filter @ 100Mbps but the traffic is only 1Mbps, the device has  
"performance limitations", but they are not applicable!) Perhaps  
could be modified to "if performance limitations allow"."

Section 2.4.4:
"Rate limiting is used by some ISPs although other ISPs believe it is
   not really useful since attackers are not well behaved and it  
doesn't
   provide any operational benefit over the complexity." -- rate- 
limiting can also make an attacker's job easier. I have seen GE links  
that have 20Mbps rate-limits "for security" -- now the attacker only  
has to generate 1/50th as much traffic to starve legitimate traffic....

Section 2.6.7:
"All TFTP and SCP access is
   username/password authenticated and in most environments scripts are
   used for maintaining a large number of routers." -- unfortunately  
there is no username or password for TFTP.

Section 2.8.2:
"This type of traffic is currently filtered per interface" -- some  
devices support a receive ACL or loopback interface ACL, so the  
management filters are applied to the device instead of per interface.

Section 2.8.3.  Routing Control Plane Filtering
"Any announcement received
   that is longer than a /48 for IPv6 routing and a /24 for IPv4  
routing
   is discarded on EBGP." -- 2 points:
a: "discarded on EBGP" doesn't sound right -- "discarded by eBGP"?,  
"filtered out of eBGP"?
b: Most ISPs will accept ANY length prefix from customers. (Many will  
accept ANY PREFIX as well, but that it an unrelated issue!)
Possibly mention could be made that ISPs only accept agreed upon  
prefixes (I thought I saw this somewhere in the doc, but have now  
lost it.)

Section 2.9:
"At last count the number of hosts making up large distributed DoS  
BOTnets exceeded 1 million hosts." -- spelling: botnets


Section 2.9.1.  Sink Hole Routing
"redirected to a valid subnet or specific IP address where it can be
   analyzed." -- possibly change to device or system. Also, some  
ISPs provide services to try scrub attack traffic out of attacks.


Section 2.9.2.  Black-Hole Triggered Routing
Can you cite something here?
Also, BHTR doesn't really propagate static routes (well, kinda!)
Could you flush this section out more?

Section 2.9.4:
"Although this technique does not stop an
  attack, it can lessen the damage and impact on a specific  
service." -- it can also make the impact much worse (if my device can  
suck up 500k SYNs per second and a ratelimit is put in to limit SYNs  
to 100kpps, an attacker now has a much easier job (ratelimits throw  
away the good with the bad.)) While this should be obvious, I have  
seen many cases where people get DoSed and make the problem worse by  
ratelimiting legitimate traffic!



> - merike
>
> On Jun 14, 2006, at 9:52 AM, Warren Kumari wrote:
>
> > Hi,
> >
> > I have some feedback on the draft. It is looking really good, most  
> > of the comments are for really minor items....
> >
> > Warren.
> >
> >
> > -------------------------------------------------------------------
> > Notes on: draft-ietf-opsec-current-practices-03.txt
> >
> > Section 1.2:
> > "Man-In-The-Middle: An attack where a malicious user impersonates
> > either the sender or recipient of a communication stream." -- To  
> > my mind a MIM attack is more of an active attack where the  
> > malicious user impersonates party A to B (and possibly B to A)  
> > while inserting, modifying or dropping certain traffic. The  
> > original definition also covers things like phishing, session  
> > hijacks, etc (unless this class of attacks is excluded by the use  
> > of the phrase "communication stream"?).
> >
> > Section 2.1:
> > "Message Insertion: This can be a valid message (which could be a
> > reply attack,, which is a scenario where a message is captured and
> > resent at later time)." -- double commas.
> >
> > Section 2.1:
> > "A denial of service is a consequence of an attack and
> > can be the result of too much traffic (i.e. flooding), or exploting
> > protocol expoitation or inserting/ deleting/ diverting/ midifying
> > messages." -- spelling: exploiting, exploitation, modifying.
> >
> > Section 2.1.4.  Additional Considerations
> > "The physical and logical authentication and logging systems  
> > should be
> > run independently of each other and reside in different physical
> > locations." -- possibly you could mention that these systems also  
> > need to be secured. I have seen cases where the proximity card  
> > admin system is unsecured (it was in an unlocked closet off the  
> > lobby!)
> >
> > Section 2.2.1.5.  Man-In-The-Middle
> > Yay! That description explains MIM better than the definition in  
> > 1.2 :-)
> >
> > Section 2.2.2.
> > "If SNMP is used for in-band management, it is for read queries only
> > and restricted to specific hosts." -- if possible the view is also  
> > restricted to only what the management station needs (some devices  
> > will expose their config file with the read-only SNMP community --  
> > views can limit what they will send).
> >
> > Section 2.2.3:
> > "Using SSH for device access ensures that noone can spoof the  
> > traffic during the SSH session." -- spelling: no one (or no-one)
> >
> >
> > Section 2.2.3:
> > Perhaps you could mention something about securing access to the  
> > AAA server. I have seen 2 cases where this bit someone:
> > 1: The AAA server was compromised and a slew of things happened --  
> > dictionary attacks were carried out against the password file, an  
> > existing username was changed and the a new user was added.
> >
> > 2: An individual was let go and his TACACS account was yanked, but  
> > the TACACS shared secret was not changed. He was able to get  
> > access to a workstation on the network, spin up a TACACS server  
> > (with himself as the only account and using the unchanged shared  
> > secret) on that workstation. He then announced a /32 (using zebra)  
> > for the primary TACACS server into network and was able to access  
> > devices.
> >
> >
> > Section 2.5.8:
> > "Data Origin Authentication - By using MD5 authentication and/or
> > the TTL-hack a routing peer can be reasonably certain that traffic
> > originated from a valid peer."  -- cite the TTL Security hack.
> >
> > Section 2.5.9:
> > "Although MD-5 routing protocol
> > extensions have been implemented which can provide both services,
> > they are not consistently deployed amongst ISPs." -- Spelling: MD5
> >
> >
> > Thats all I have for now (AKA: My boring meeting has just ended --  
> > let me know if you want any more feedback.)
> >
> > Warren.