Re: Linksys 4-port Router NAT/Firewall

[Dragos Ruiu <dr () DURSEC COM>]

Mine do not have the same ports open.

Two comments.... when you open a hole for TCP on these you also open UDP.
So if you have any holes configured in your firewall it will positive here.
And the UDP packets do get let through on the other side (verified).
Likely that's why your port 1080 is open where as on mine it's not.

In all the cases below, so far I have been unsucessful in getting
packets to navigate across the firewall unless an explicit hole
was opened in the configuration. (good)

Outside TCP ports open with no holes configured in the firewall:
} #nmap -sS -p1-65535 outside
} Starting nmap
} Interesting ports on Linksys(outside):
} Port    State       Protocol  Service
} 68      filtered    tcp       bootpc
} 80      filtered    tcp       http
} 137     filtered    tcp       netbios-ns
} 138     filtered    tcp       netbios-dgm
} 139     filtered    tcp       netbios-ssn
} 520     filtered    tcp       efs
}
} Nmap run completed -- 1 IP address (1 host up) scanned in 203 seconds

Doing a TCP scan on the inside:
} #nmap -sS -p1-65535 inside
} Starting nmap
} Interesting ports on  Linksys(inside):
} Port       State       Service
} 80/tcp     open        http
}
} Nmap run completed -- 1 IP address (1 host up) scanned in 284 seconds

Now for UDP.....
} #nmap -sU -p1-65535 outside
} Starting nmap
} Interesting ports on Linksys(outside):
} Port    State       Protocol  Service
} 67      open        udp       bootps
} 68      open        udp       bootpc
} 69      open        udp       tftp
} 137     open        udp       netbios-ns
} 138     open        udp       netbios-dgm
} 139     open        udp       netbios-ssn
} 520     open        udp       route
} 3093    open        udp       unknown
}
} Nmap run completed -- 1 IP address (1 host up) scanned in 344 seconds

Note that I was not able to sucessfully navigate packets to the inside unless
I had opened up that port through the mgmt web interface for UDP too.

Inside open UDP Ports on them with no holes configured:
} # nmap -sU -p1-65535 inside
} Starting nmap
} Interesting ports on Linksys(inside):
} Port       State       Service
} 67/udp     open        bootps
} 69/udp     open        tftp
} 520/udp    open        route
} 3093/udp   open        unknown
}
} Nmap run completed -- 1 IP address (1 host up) scanned in 260 seconds

Complaints about the unit:
-To enble specific port blocks, you have to disable the dhcp server. (huh?)
-There is no real data about what application level proxying happens if any
  so I have to go run some ugly test myself to identify this. The manual is,
  well, cursory as far as technical details and aimed at a non-technical user.
  A brief search of their web site turned up no more significant details.

Positives:
-fragmented packets do not get to bypass anything
-trying all kinds of cgi tests and other mucking with the web interface
  trying to overflow it passed all the simple tests.  A more thorough
  poking here will prove it conclusively, but good initial results.

unknowns still:
-DoS survivability, jolt2 and friends, etc...

Someone also asked a question about whether the NAT affects performance.
The answer is NO.  My home/office is configured a little differently (!) than
your typical network, in that there are 5-8 subnets, with some internal
firewalls between subnets.... I have two of these Linksyses doing internal
duty between local segments and routinely make transfers at rates in excess
of T3 line rates.... so I'm pretty confident that these will do just fine on
cablemodem or ADSL duty.  I've done specific transfer tests, and going
through three levels of NAT (of different types) I do not see any or negligible
levels of slowdown compared to a direct connection. Bedsides which, if
you can afford the bandwidth charges for links faster than that, then what
are you doing using a dinky little fw/router like this?

Disagreeing with the poster below, I see no issue with the unit not throttling
ICMP. I would like my firewall to be as un-noticeable as possible to
traffic that i *do* want in and out.  And since my work makes nmap
and ICMP packets a big part of my traffic, the fact that it _doesn't_
muck with my ICMP is a plus not a minus.

I'll continue to run some more tests later.. But I just noticed something
interesting... When you change configuration on the router web interface
and you commit the changes, it triggers a broadcast snmp alert on the
internal interface that looks like:

} Frame 1 (148 on wire, 148 captured)
} Arrival Time: Aug 25, 2000 17:45:41.8243
} Time delta from previous packet: 30.759234 seconds
} Frame Number: 2
} Packet Length: 148 bytes
} Capture Length: 148 bytes
} Ethernet II
} Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
} Source: x:x:x:x:x:x (x:x:x:x:x:x)
} Type: IP (0x0800)
} Internet Protocol
} Version: 4
} Header length: 20 bytes
} Differentiated Services Field: 0x00 (DSCP 0x00: Default)
} 0000 00.. = Differentiated Services Codepoint: Default (0x00)
} .... ..00 = Currently Unused: 0
} Total Length: 134
} Identification: 0x0000
} Flags: 0x00
} .0.. = Don't fragment: Not set
} ..0. = More fragments: Not set
} Fragment offset: 0
} Time to live: 64
} Protocol: UDP (0x11)
} Header checksum: 0x655c (correct)
} Source: x (x.x.x.x)
} Destination: 255.255.255.255 (255.255.255.255)
} User Datagram Protocol
} Source port: 1026 (1026)
} Destination port: snmp-trap (162)
} Length: 114
} Checksum: 0x95c6
} Simple Network Management Protocol
} Version: 1
} Community: public
} PDU type: TRAP-V1
} Enterprise: 1.3.6.1.4.1.3093.2.2.1
} Agent address: x.x.x.x
} Trap type: ENTERPRISE SPECIFIC
} Specific trap type: 1 (0x1)
} Timestamp: 148834
} Object identifier 1: 1.3.6.1.4.1.3093.1.1.0
} Value: OCTET STRING: refresh_NV(206), startip=x.x.x
}
} Frame 2 (148 on wire, 148 captured)
} Arrival Time: Aug 25, 2000 17:45:41.8249
} Time delta from previous packet: 0.000548 seconds
} Frame Number: 3
} Packet Length: 148 bytes
} Capture Length: 148 bytes
} Ethernet II
} Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
} Source: x:x:x:x:x:x (x:x:x:x:x:x)
} Type: IP (0x0800)
} Internet Protocol
} Version: 4
} Header length: 20 bytes
} Differentiated Services Field: 0x00 (DSCP 0x00: Default)
} 0000 00.. = Differentiated Services Codepoint: Default (0x00)
} .... ..00 = Currently Unused: 0
} Total Length: 134
} Identification: 0x0000
} Flags: 0x00
} .0.. = Don't fragment: Not set
} ..0. = More fragments: Not set
} Fragment offset: 0
} Time to live: 64
} Protocol: UDP (0x11)
} Header checksum: 0x655c (correct)
} Source: x (x.x.x.x)
} Destination: 255.255.255.255 (255.255.255.255)
} User Datagram Protocol
} Source port: 1027 (1027)
} Destination port: snmp-trap (162)
} Length: 114
} Checksum: 0x614d
} Simple Network Management Protocol
} Version: 1
} Community: public
} PDU type: TRAP-V1
} Enterprise: 1.3.6.1.4.1.3093.2.2.1
} Agent address: x.x.x.x
} Trap type: ENTERPRISE SPECIFIC
} Specific trap type: 1 (0x1)
} Timestamp: 148834
} Object identifier 1: 1.3.6.1.4.1.3093.1.1.0
} Value: OCTET STRING: http.c(719) updata_NV=1, reboot=1

I don't see snmp(161) open... but these make me suspect that
I may get a response from snmp sent to one of these other
mysterious open ports. If someone does do this test...  please
let me know how it goes.

Hope that more detail helps....

cheers,
--dr

On Fri, 25 Aug 2000, you wrote:
> I have a friend using the Linksys router for RAS/PPOE on a bell atlantic DSL
> connection. I scanned his with nmap and all tcp ports where closed and in
> 'stealth mode' so that no reponses where sent about closed ports. UDP was
> another story. I was able to quickly scan the first 1448 ports with nmap and
> got the following:
>
> Interesting ports on  (X.X.X.X):
> (The 1442 ports scanned but not shown below are in state: closed)
> Port       State       Service
> 67/udp     open        bootps
> 69/udp     open        tftp
> 520/udp    open        route
> 1080/udp   open        socks <---- hmmm....
> 1083/udp   open        ansoft-lm-1
> 1084/udp   open        ansoft-lm-2
>
>
> It didn't even throttle the ICMP port closed packets the way Solaris and
> other unices do so nicely.
>
> I'm not sure what's exploitable here and if anything really is listening..
> It's so hard to tell with UDP. I tried using netcat to connect to each port
> but could net get it to send me back any data. It could be that it just
> doesn't send an ICMP port unreachble for these ports.
>
>
>
> > -----Original Message-----
> > From: Michael Wojcik [mailto:Michael.Wojcik () MERANT COM]
> > Sent: Friday, August 25, 2000 11:56 AM
> > To: VULN-DEV () SECURITYFOCUS COM
> > Subject: Re: Linksys 4-port Router NAT/Firewall
> >
> >
> > > -----Original Message-----
> > > From: Larry D'Anna [mailto:larry () pink dhs org]
> > > Sent: Thursday, August 24, 2000 7:32 PM
> >
> > > * Litscher, Steven (Steven.Litscher () OJA STATE WI US) [000824 20:08]:
> > > > [using Linksys home router / NATting firewall w/ ZoneAlarm]
> >
> > > As Bruce Schneier would say, security is a process, not a product.
> >
> > One of the implications of this statement is that security aspects -
> > including risks - change over time.
> >
> > > A firewall is one way to make life more difficult for an
> > attacker, but it
> > > doesn't guarantee security by any means.  What does the linksys do?
> > > What does ZoneAlarm do?  If they are doing basicly the same things
> > > (and I suspect they are) and neither of them has known
> > vulnerabilities
> > > then it probably doesn't matter which you use.
> >
> > I humbly submit that new vulnerabilities may be found in the
> > future in one
> > or the other product; hence it is probably best to continue using both.
> > Checking for known vulnerabilities is a good idea, but a lack of them
> > shouldn't be taken as evidence that no vulnerabilities exist.
> >
> > Of course, it's always possible that two security products in
> > combination
> > may be weaker than only one.  (Indeed, it's not even
> > particularly unlikely.)
> > My sense, from evaluating the particular combination I have,
> > is that the
> > whole set is stronger than any proper subset under my threat
> > model, and that
> > similarly Steven would be better off keeping ZoneAlarm, since
> > he apparently
> > already has it installed and working.
> >
> > > All I'm trying to say is that you shouldn't think of a
> > firewall as being
> > > "safe" or "unsafe" or "safe enough".  You should think of it in terms
> > > the specific functionality it provides.
> >
> > True, but you should also consider whether overlapping
> > functionality may
> > help one product cover unexpected deficiencies in another, and
> > whether their
> > combination may produce an unexpected deficiency that does not
> > exist in one
> > or the other used separately.
> >
> > In general, I wouldn't advise retiring a level of protection
> > merely because
> > it seems redundant.  Just because I have a NATting firewall
> > router doesn't
> > mean I don't want to use tcp_wrappers to restrict incoming
> > connections to my
> > LAN.
> >
> > >  See the recent thread in
> > > bugtraq about using brownorrifice to totally bypass almost any
> > > firewall that lets web traffic through.
> >
> > This is an instance where a connection-monitoring utility like
> > ZA might (I
> > haven't tested it, nor researched the behavior of ZA and BrO
> > sufficiently to
> > make an educated guess) provide protection against an exploit
> > that a NATting
> > router would not handle.  Connector monitors are generally
> > fairly good at
> > detecting network activity by trojans; external firewalls
> > cannot do this,
> > except in the cases where trojan activity has a detectable
> > signature in the
> > traffic itself, which are relatively rare and easy for trojan
> > authors to
> > avoid.
> >
> > Michael Wojcik             michael.wojcik () merant com
> > MERANT
> > Department of English, Miami University
--
dursec.com ltd. / kyx.net - we're from the future
pgp fingerprint: 18C7 E37C 2F94 E251 F18E  B7DC 2B71 A73E D2E8 A56D
pgp key: http://www.dursec.com/drkey.asc