Ok, it may appear that I was advocating "security by obscurity", hence here's an example of a 'correct' way of doing things: =)
policy-options { /* Put your known IPs here to allow them through */ prefix-list management-ips { 1.2.3.4/32; 2.3.4.5/32; 3.4.5.6/32; } } firewall { family inet { filter protect-management { term allow-my-ips { from { source-prefix-list { management-ips; } protocol tcp; destination-port 22; tcp-initial; } then accept; } term deny-all-other-ips { from { protocol tcp; destination-port 22; tcp-initial; } then { discard; } } term allow-all-other-control-plane-traffic { then accept; } } } } interfaces { lo0 { unit 0 { family inet { filter { input protect-management; } address 4.3.2.1/32; } } } } Hope this helps - Chris. On 2011-04-04, at 7:02 AM, Stefan Fouant wrote: >> -----Original Message----- >> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- >> boun...@puck.nether.net] On Behalf Of Chris Kawchuk >> Sent: Sunday, April 03, 2011 4:48 PM >> >> P.S. the 'ssh' services port is defined in /etc/services. Unsure if you >> adjust the line, that it may move the listening port. Might be worth a >> try; but naturally this would be a Juniper-unsupported configuration >> and will probably be overwritten on a software upgrade. It may also >> affect your firewall filters in the [from] stanza. YMMV. > > I'm surprised by how many people on this list still think that 'Security > through Obscurity' is an effective means of securing devices. Nmap or any > other suitable scanner could isolate the SSH port in relatively no time at > all. > > As a matter of practice I think that isolating the allowed IPs which might > avail of the SSH port or any other management service for that matter is a > much better overall solution. > > Stefan Fouant, CISSP, JNCIEx2 > www.shortestpathfirst.net > GPG Key ID: 0xB4C956EC > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp