Network Engineering Question

noobie651

What are some r&s protocols you implement on your network? WAN? LAN?
I know that a good network engineer should always keep in mind things like reliability, scalability, redundancy, etc, but what are other good practices when designing a network?

skinsFan202

Have you heard of a book called Network Warrior? If I were you I would check that out. I think it has a lot of good real world tips in there that you might be looking for.

Network Warrior: Gary A. Donahue: 9781449387860: Amazon.com: Books

f0rgiv3n

Good recommendation right there. I second that.

cjthedj45

Thanks for that its just gone on my Xmas list

gbdavidx

it would be nice and interesting for some network engineers to answer this question

wes allen

I am a big fan of making things a simple as you can. No trying cool new features when the basics will work. I am fine with giving up a little bit of performance and redundancy in favor of stability. But, I mostly set up networks that are pretty straightforward and the sites usually don't have an onsite engineer or network tech. Nice layer three switch for the core, then some vlan tagging out when needed. Maybe a remote site or two on T1's but mostly fiber WAN. Static routes and/or RIP2.

I just saw this book the other day, and am going to try to pick it up - Juniper Networks Warrior - Juniper Networks

f0rgiv3n

gbdavidx wrote: »

it would be nice and interesting for some network engineers to answer this question

What do you think I am? *nudge*

JDMurray

Here's some security-minded design and implementation best practices:

Have every network host synced to the same timebase and use the same timezone (GMT best to get ride of DST, and if networked equipment is spread over multiple time zones).

Have all of your network hosts use syslog and SNMP to send event reporting messages to a central log collection server. Have the tools to review events as they are received and to review events after they are archived. A SIEM is better and faster at looking at event patterns than most humans.

Have sniffers running behind your firewall and IDS/IPS to record what is in/egressing from the Internet and your extranet. This information will come in handy for incident investigations.

Don't store sensitive information directly on the (bastion) hosts in your DMZ. Instead, store sensitive information on hosts in your private security zone and have the DMZ hosts request it via an application firewall/proxy. Trust your DMZ hosts only little more than you would any host on the public Internet.

Use load balancing to ensure network service availability and to dilute DoS attacks. Implement SSL certificates on your load balances to allow (HTTP) traffic at the servers to be sniffed.

Investigate all packets and connections being dropped by your firewalls. This is an indication of either missing FW rules or the presence of traffic that shouldn't be on your network.

Always DENY ALL by default on all firewalls with at least one untrusted boundary.

Segregate dissimilar network traffic using VLANs. Consider VLANs as much a security measure as an administrative one, but never rely on VLANs to provide any actual network security.

If you don't trust your IPS, run it "log only" until you get use to the traffic it flags as bad. Eventually, you will realize that just because your IPS vendor recommend a specific signature should "drop" connection doesn't mean you have to allow it to. Sometimes it's better to allow bad traffic than to risk unavailability of a network service due to a false positive.

DevilWAH

My view on designing a network is not what technologies are out there, and what the purpose of each one is.

It does not mean you need to know it all in great depth, to implement every feature possible. But it allows you to match the solutions to the problems.

And learn what it is that solution is meant to be addressing, and what is required.. Users are not network engineers, neither are most managers, and in many cases neither are server admins.

This is true what ever you are doing, network, sys admin, trouble shooting.. know what the problem is that you are trying to fix. Don't try to address the symptoms, address the problem. If you can define the problem you are half way to having a solution, and defiantly in a good place to start planing one.

And designing a network is fixing a problem, the symptoms of the problem are that the current network is broken/out of date or may be does not exist. The problem though is why do people think the network is out of date. To many times I have seen great fancy networks installed, that while secure and resilient, do not meet the needs of the business and users.

The primary goal is to benefit the business use of the network. the other bits like security, resilience and scalibility should be then built around that idea,

f0rgiv3n

This inspired me to also post the classic security triangle. This is applicable to all things when deploying with security in mind. It's a balance between security, functionality and ease of use. If it's out of wack at all, you'll run into problems. I mean, if it's locked down too much then it takes away from functionality and ease of use(also administration). If it's extremely easy to use, most likely it's not very secure. Those are a few examples.

phoeneous

f0rgiv3n wrote: »

This inspired me to also post the classic security triangle. This is applicable to all things when deploying with security in mind. It's a balance between security, functionality and ease of use. If it's out of wack at all, you'll run into problems. I mean, if it's locked down too much then it takes away from functionality and ease of use(also administration). If it's extremely easy to use, most likely it's not very secure. Those are a few examples.

Isn't the infosec triad: confidentiality, integrity, availability?

Excellent1

phoeneous wrote: »

Isn't the infosec triad: confidentiality, integrity, availability?

You're both right--the triangle that f0rgiv3n references is well known, as well as the one you pointed out, of course.