<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Spherical Chicken &#187; networking</title>
	<atom:link href="http://www.scriptkiddie.org/blog/category/networking/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.scriptkiddie.org/blog</link>
	<description>Climate, Technical Diving, Economics, System Engineering, IT Security</description>
	<lastBuildDate>Wed, 25 Jan 2012 20:36:47 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>The Heretical Sysadmin: Outbound ACLs need to die</title>
		<link>http://www.scriptkiddie.org/blog/2011/02/25/the-heretical-sysadmin-outbound-acls-need-to-die/</link>
		<comments>http://www.scriptkiddie.org/blog/2011/02/25/the-heretical-sysadmin-outbound-acls-need-to-die/#comments</comments>
		<pubDate>Fri, 25 Feb 2011 17:45:25 +0000</pubDate>
		<dc:creator>Lamont Granquist</dc:creator>
				<category><![CDATA[networking]]></category>
		<category><![CDATA[sysadmin]]></category>

		<guid isPermaLink="false">http://www.scriptkiddie.org/blog/?p=594</guid>
		<description><![CDATA[Its time. The idea that all your servers need to be by default ACL&#8217;d so that they can&#8217;t talk to the internet is an idea that is dying and needs to be put out of its misery. First of all, outbound ACLs create constant rollout failures of software. Unless you&#8217;ve got really excellent process around [...]]]></description>
			<content:encoded><![CDATA[<p>Its time.  The idea that all your servers need to be by default ACL&#8217;d so that they can&#8217;t talk to the internet is an idea that is dying and needs to be put out of its misery.</p>
<p><span id="more-594"></span></p>
<p>First of all, outbound ACLs create constant rollout failures of software.  Unless you&#8217;ve got really excellent process around replicating the ACLs in pre-production and tracking the ACLs as part of rollout procedures you will inevitably wind up with rollout/deployment failures in production.  I&#8217;ve been on way too many post mortems of software deployments where the failure to track production outbound ACLs has been the cause.  I&#8217;ll say what doesn&#8217;t get said at these meetings, which is that the outbound ACLs themselves are the cause of the problem.</p>
<p>Second of all, with all the cloud services now the outbound ACLs are only going to cause more and more problems.  All my servers now talk to chef servers &#8220;in the cloud&#8221; run externally by opscode.  All my Dell servers pull OMSA and firmware directly from Dell.  The software dev teams are using github more and more and pulling directly from those servers &#8220;in the cloud&#8221;.  As more and more external platform dependencies are built it becomes impossible to deal with them all, particularly as the platform vendors change their own IPs around on their own schedule.  Opscode migrated from Amazon EC2 to rackspace and I never knew about that &#8212; if we had outbound ACLs everything would have broken, or it would have been a huge firedrill.  In the past 9 months I&#8217;ve gone from having basically no external dependencies on &#8220;the cloud&#8221; and burning tons of time carefully mirroring all my CentOS and RHEL RPMs, to having 3 major external dependencies to &#8220;the cloud&#8221;, and I&#8217;ve gotten more done and slept fine at night.</p>
<p>Sure, you can say that we should minimize all of this.  Replicate the dell stuff with in-house mirrors, stop using github and run our internal git servers, setup chef servers internally and host it ourselves.   But you just cut three big checks on our time, and we&#8217;re simply not staffed to handle that.  Even if we were staffed to handle it, if you stack rank what I care about none of that comes close to the top of the list of stuff that I would do if we had 2 more headcount.  I&#8217;ve given up thinking that its an appropriate job for a system admin to in-house everything that can just be outsourced to &#8220;the cloud&#8221; in order to remove external dependencies of the enterprise.</p>
<p>Sure this increases risk, but the job of the system admin is not to decrease every single risk that they find.  Everything needs to be stack ranked and needs to be assessed in terms of its importance.  I still have huge issues with account management and our deployment process is crap and we need to patch our servers and I don&#8217;t have enough time to do any of that.  How much time do I have to worry that my servers point directly at Dell&#8217;s repo for OMSA?  I don&#8217;t have time to care about that.  There&#8217;s much riskier things in my infrastructure that if I ignore them I will get hacked or will definitely cause me downtime.</p>
<p>And sure, outbound ACLs help after you do get hacked.  I&#8217;d argue, however, that the cost of the outbound ACLs is starting to greatly exceed the level that they help.  I&#8217;d also argue that you need to focus on preventing the attacks from being successful in the first place.  The use of outbound ACLs is lazy security engineering and damages the rest of the business.  Become pro-active and scan your network for open proxies and close them, don&#8217;t rely on outbound ACLs so that you can have open proxies available to the internet, but its okay (because nobody can use them to bounce into the internet and suck up your bandwidth &#8212; they can only scan your whole internal network &#8212; its okay!).  Tighten up your border security and if you must install &#8220;detect&#8221; controls instead of &#8220;prevent&#8221; controls.  Log when you see anomalous behavior.</p>
<p>There also will still be PCI-DSS to deal with, and every security best practices document out there probably start approaching the network from the perspective of locking everything down and then poking tiny little holes in it &#8212; writing checks on your time to manage all of that.  The people who wrote those docs don&#8217;t have to manage your network and it only took them a few minutes to draft that policy, while you&#8217;re stuck with the fallout from the policies for the rest of your career.  You don&#8217;t have to follow them if they&#8217;re no longer working.  Except for VISA, you have to follow that, but VISA would prefer that your servers all crash rather than having you violate their standard.  So, wall off the PCI-DSS environment and get used to managing the outbound firewall ACLs there and suck it up as a cost to the business.  But do not make the mistake of thinking that what you do for PCI-DSS is necessarily a best practice and that it should be applied to the rest of your Enterprise.</p>
<p>Also, certain outbound ACLs are fine.  None of your production servers should probably be making IRC connections.  By all means block that port and have any outbound connection to IRC servers set off security alarms that wake up your security engineers and put them to work.  Similarly, you can probably engineer your SMTP sending infrastructure so that most leaf nodes forward to dedicated SMTP internal relays and only those servers are allowed to send outgoing SMTP.  On a case-by-case basis that is fine.  But port 80 and port 443 to the internet are going to need to be wide open in the future.</p>
<p>Get used to it.  At some point, you will not be able to keep up and &#8220;the cloud&#8221; will solve too many problems to be able to continue to burn time replicating internet resources in-house, and the ACL management will become a nightmare and more of a risk to uptime to manage badly than to simply open it up.</p>
<p>Its time to stop considering outbound ACLs a &#8220;best practice&#8221; and start considering it something that bad SEs and NEs do who are just control freaks that haven&#8217;t evolved out of the late 90s best practices.  We have passed an inflection point where this practice is no longer net positive to the Enterprise and it is net negative in terms of management and availability.  Stop thinking that its part of doing a good job to block everything from being able to talk to the Internet.  You are in the way of the business.  You are an impediment to getting things done.  Servers, both inside your company and outside, desperately want to talk to each other to get work done, stop getting in the way.</p>
<p><a class="a2a_dd a2a_target addtoany_share_save" href="http://www.addtoany.com/share_save#url=http%3A%2F%2Fwww.scriptkiddie.org%2Fblog%2F2011%2F02%2F25%2Fthe-heretical-sysadmin-outbound-acls-need-to-die%2F&amp;title=The%20Heretical%20Sysadmin%3A%20Outbound%20ACLs%20need%20to%20die" id="wpa2a_2"><img src="http://www.scriptkiddie.org/blog/wp-content/plugins/add-to-any/share_save_171_16.png" width="171" height="16" alt="Share"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://www.scriptkiddie.org/blog/2011/02/25/the-heretical-sysadmin-outbound-acls-need-to-die/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Cisco IOS Router Setup</title>
		<link>http://www.scriptkiddie.org/blog/2010/02/14/cisco-ios-router-setup/</link>
		<comments>http://www.scriptkiddie.org/blog/2010/02/14/cisco-ios-router-setup/#comments</comments>
		<pubDate>Sun, 14 Feb 2010 17:56:22 +0000</pubDate>
		<dc:creator>Lamont Granquist</dc:creator>
				<category><![CDATA[networking]]></category>
		<category><![CDATA[cisco]]></category>

		<guid isPermaLink="false">http://www.scriptkiddie.org/blog/?p=81</guid>
		<description><![CDATA[I&#8217;ve been a Unix SA/SE for about 16 years and my hands-on knowledge of IOS has always been limited due to limited console time on Cisco routers. However, now I&#8217;m studying to get a CCNA. Certificates are kinda lame, but I&#8217;ve run into times when it would be useful. This is going to be a [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve been a Unix SA/SE for about 16 years and my hands-on knowledge of IOS has always been limited due to limited console time on Cisco routers.   However, now I&#8217;m studying to get a CCNA.  Certificates are kinda lame, but I&#8217;ve run into times when it would be useful.</p>
<p>This is going to be a growing list of all the global configuration commands that I come up with that are useful for setting up a router/switch first-time (or for enforcing policy on all routers/switches).  It is going to start out fairly sparse.</p>
<p><strong>Basic</strong></p>
<blockquote>
<pre>
hostname &lt;routername&gt;
ip domain-name &lt;dns name&gt;
</pre>
</blockquote>
<p>Sets the hostname and domainname.</p>
<p><strong>Convenience</strong></p>
<blockquote>
<pre>
line console 0
  logging synchronous
</pre>
</blockquote>
<p>Sets synchronous output on the console.</p>
<p><strong>Security</strong></p>
<blockquote>
<pre>
enable password foo
enable secret bar
</pre>
</blockquote>
<p>Sets the enable password, only &#8220;enable secret&#8221; should be used since it encrypts the password in the config.</p>
<blockquote>
<pre>
service password-encryption
</pre>
</blockquote>
<p>Sets up weak password encryption to obscure passwords in router config.</p>
<blockquote>
<pre>
line vty 0 4
  login
  password foo
  logging synchronous
</pre>
</blockquote>
<p>Set synchronous output on the first 5 telnet vtys and sets a login password for the terminal.</p>
<blockquote>
<pre>
banner login #

    Authorized uses only.  All activity may be monitored and reported.

#
</pre>
</blockquote>
<p>Set a multi-line banner displayed before the password prompt for telnet.</p>
<blockquote>
<pre>
banner motd #

    Authorized uses only.  All activity may be monitored and reported.

#
</pre>
</blockquote>
<p>Set a multi-line banner displayed before the password prompt for telnet *and* on console login (better).</p>
<p><strong>Logging</strong></p>
<blockquote>
<pre>
archive
  log config
    logging enable
    logging size 200
    notify syslog contenttype plaintext
    hidekeys
</pre>
</blockquote>
<p>Sets an archive history of router configuration commands</p>
<p><strong>Time</strong></p>
<blockquote>
<pre>
clock timezone UTC 0
</pre>
</blockquote>
<p>Set the timezone of the router manually.</p>
<blockquote>
<pre>
clock set 02:11:25 Feb 15 2010
clock update-calendar
</pre>
</blockquote>
<p>This is not entered in configuration mode, and sets the software clock and then writes to the hardware clock.</p>
<blockquote>
<pre>
ntp server 10.1.1.1
ntp server 10.1.1.2 prefer
ntp server 10.1.1.3
ntp update-calendar
</pre>
</blockquote>
<p>Set the router to be an NTP client, and use NTP to sync the hardware clock.</p>
<p><strong>DNS</strong></p>
<blockquote>
<pre>
ip nameserver 10.1.1.1
ip nameserver 10.1.1.2
</pre>
</blockquote>
<p>Sets nameservers for DNS queries</p>
<blockquote>
<pre>
ip domain-lookup
</pre>
</blockquote>
<p>Enable DNS lookups.  This may be disabled by NEs to avoid command typos from being looked up in DNS, but it globally disables DNS lookups inside commands as well.</p>
<p><strong>Spanning Tree</strong></p>
<blockquote>
<pre>
spanning-tree mode rapid-pvst
</pre>
</blockquote>
<p>Use Rapid-PVST by default everywhere.</p>
<p><strong>SNMP</strong><br />
<strong>TACACS</strong></p>
<p><strong>MISC</strong></p>
<blockquote>
<pre>
ip subnet-zero
</pre>
</blockquote>
<p>Allow subnet zero ip addresses.</p>
<blockquote>
<pre>
system mtu jumbo 9000
</pre>
</blockquote>
<p>Set jumbo frames on 3750/3560/49xx switches.</p>
<p><a class="a2a_dd a2a_target addtoany_share_save" href="http://www.addtoany.com/share_save#url=http%3A%2F%2Fwww.scriptkiddie.org%2Fblog%2F2010%2F02%2F14%2Fcisco-ios-router-setup%2F&amp;title=Cisco%20IOS%20Router%20Setup" id="wpa2a_4"><img src="http://www.scriptkiddie.org/blog/wp-content/plugins/add-to-any/share_save_171_16.png" width="171" height="16" alt="Share"/></a></p>]]></content:encoded>
			<wfw:commentRss>http://www.scriptkiddie.org/blog/2010/02/14/cisco-ios-router-setup/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

