IDS systems catch some things, so why not keep them. I never argued you should not have one.
Having said that, I would not choose an IDS as my first, second, or third line of defense against a Trojan that had successfully planted itself on one of my Internet facing servers. A sophisticated intruder won't be deterred by that.
Nope, it just takes longer since you need to configure each host.
Nope, ILO, ILOM etc. provides a shell as well as a remote console, I don't even have to touch the machine physically. Almost every server has something like that, I believe Dell has a card called RAC. But it's a long time ago since I dealt with Dell. Anyway in case you didn't know that, you may should consider it.
cheers
Fully agree. It's more an addition, but almost all I have seen so far working sometimes a little, lets say weird on IP.
cheers
Depends on the implentation within the OS/Kernel/driver/firmware. Have never seen something like that.
No, you can create serveral zones on a firewall, assuming the firewall supports that. Juniper does.
Not on portbased vlans.
That is a reason for access lists, problem solved.
Nope, thats why you plan the network layout and access permissions before you implement it.
You would need a couple services such as DNS or smtp, thats a good point to 'leave' the machine and try to get access to another part of the network. cheers
So neither additional time nor additional effort requirements (you have to somehow access the hosts you want to configure) qualify as "significantly harder" in your book? Somehow I don't subscribe to that.
Most servers do. Most clients don't. Most hosts configured via DHCP are clients. Please try reading what I write before responding. Thank you.
I am very well aware of these things, thank you very much.
cu
59cobalt
That's evidence of my point. You configure some things in the firewall, and you configure some separate things in the switch, and the security design of the firewall depends on configuration you did on a separate device. It's not integrated into a single place.
If I have a 24 port switch and the first four ports are in a separate VLAN, why don't I have to label those four ports?
If I have a 24 port switch and the first port by itself is a separate VLAN, why don't I have to label that one port?
More configuration. More policy hidden from the firewall. More hassle.
More configuration. More policy hidden from the firewall. More hassle.
You like to work hard. I admire your work ethic. :)
Better to expose just DNS client and SMTP outbound only than to allow unlimited access out to the Internet.
Because, like I've seen hundreds of times, even if you have a document on the network that tells tech's what ports are on what vlan's, they will never look at/for the document and connect devices and then spend hours trying to determine why it's not working.
We simply use color stickers to denote vlan membership in VLAN's, even if the switch is a DUMB switch on VLAN-X, the switch gets the color assigned to X so that there is no confusion.
In a one-man-show you might be able to get away with no markings, or in a place where you never move/connect cables, but not in most cases.
Exactely, therefore if somebody gets access to the switch he can't bypass the firewall and vice versa.
If somebody plays around either on the switch or on the firewall setting up rules which are not fitting to the security concept, nothing on his end will be working.
If you are using 802.1g you just bundle those ports, there is no lable required. If you'd like to carry seperate networks on the same wire you usually use 802.1q, then you must apply for each network a ID, only the endpoints with the ID have access on the switch but they can't see the other networks since the label is different. Almost similar with MPLS.
Depending on your upstream connection, you don't have to do that since ther is only one host connected to that port which can send traffic, in case the host has multiple networks (e.g. virtual interfaces), you can apply an access list, on the other hand if he just has the access to the upstream firewall, there is only one gateway IP which needs to be in the same net, all other traffic (depends on the config) is disabled since this would be a spoofed address space.
Ack, the firewall is supposed to be a filter, the more you can filter on the source (in this case switch), the less has the firewall to do.
Why should I allow 'foreign' networks on a switch. I configure it usually with an access list wth the network which is allowed to pass the switchport, if somebody thinks he needs another one on his host, his port gets automatically disabled and the switch send me a snmp trap. Until I enable the port again, he is pretty much offline.
It's not hard at all, I just plan a network layout and implement it, after that there is usually nothing more to do, except somebody uses the scenario above, but this is something you need to investigate every time. Only defined traffic is allowed to flow, any violation of these rules send me a notification anyway, a quick lookup in the database and I know the source host, takes roughly 5 seconds.
But unfortunately, almost every network has been configured like that. Usually they used it to receive updates etc., since I'm not responsible for that I don't care but I was able to break out of their DMZ easily and found a nice buggy host to elevate my permissions, avter that the project was done, unfortunately.
cheers
cheers
I would never allow those people to even touch the switch :). But you're right I have it seen too, even if you hand out the documentation as a paper, it only gets used to avoid the coffee stains on their tables.
I started to use different colors for the cabeling, but guess what if somebody doesn't know how to use a crimp tool they just use another cable to avoid crimping. After that the cabinet looks like a barbwired closet.
Yes, there are difficulties with that philosphy but the people need to be trained and if they a re willing to understand that, they find out that they can do their work much faster and keep the network environment safe, the time they safed working on a case can be spend then for the documentation :).
cheers
This is why I wrote in SOHO environments DHCP is fine, but not necessary, so please read my posts as well.
cheers
You are making my point for me. A color sticker is a label.
I was agreeing with you completely, maybe you read the thread out of order?
I don't just assume that someone will know that the first four ports are part of a vlan, in fact, if we don't see any color/label on ports we assume that the switch is not part of/ not configured for VLAN's.
This is getting ridiculous. It doesn't matter if you're looking at home, small, or any other office. The majority of hosts (particularly the majority of hosts configured via DHCP) in virtually any kind of environment are clients. Which rarely come with remote management interfaces. Sorry to burst your bubble.
cu
59cobalt
It does.
Nope, you should go into a datacenter and check it out there, the server are just clients as well.
It's not a bubble, if you don't have any experience in 'bigger' networks you can't know it better.
cheers
Nope.
Offices of any kind rarely reside in datacenters. Unless you're talking about VDI environments. Where clients are accessible through the hypervisor, but still don't have remote management interfaces.
We're running our own datacenter, so I think I might know just a tiny little bit about this stuff.
cu
59cobalt
I wrote in my previous posts that DHCP is fine for office environments but not in every case necessary/useful, nothing else.
The server with the hypervisor is a server or have you the hypervisor running on every client?
Obviously not. I built 3 and operate them, but that doesn't matter since it doesn't say anything.
cheers
You specifically wrote SOHO, which is a very limited subset of offices. I objected to that limitation.
Also, while DHCP certainly isn't necessary in every case (strictly speaking, it isn't necessary in any case, only IP configuration management becomes a major PITA without it) I have yet to see a single case where DHCP wouldn't be useful. Of course there are technical limitations (DHCP servers obviously need static addresses) and security considerations that rule out DHCP in some scenarious, but that doesn't mean that otherwise DHCP wouldn't be darn handy even there.
Do you even know what the term "hypervisor" means?
With your bare hands, I presume ...
cu
59cobalt
I never complained about that, did I?
Yes, I do. Are you just trying to troll a little or what is the reason you get so rude?
I guess it doesn't make any sense since you can't understand that there are people out there with different opinions and experience, so do whatever you think it's right, I'm fine with that.
cheers
Perhaps surprisingly, I'm assuming that anyone who knows what a hypervisor is wouldn't bring up something like "hypervisor running on every client". Particularly not when we were talking about a VDI environment where "hypervisor on a client" doesn't make any sense at all.
cu
59cobalt
Also in this case it depends on your goals, google for the OS of Anna Rutkowska as well as it is possible to share a workstation with multiple users and if you don't like to rely on user sessions a hypervisor and a virtualized OS on that machine makes sense. Nut I suppose since you're living in your own world and just try to find something to argue without any interrest in discusing things, it doesn't make sense to discuss any topic with you further.
R.I.P.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.