En nybörjarfråga angående dubbelbalanserade mk i serie på samma sektion.
Jag har 2 MK i serie på samma sektion. Ett 2.2k motstånd över resp MK. Ett 2.2k motstånd som slutmotstånd.
Konfat sektionen med DUB BAL 2k2 2k2.
Ger larm fint när jag öppnar respektive MK individuellt. Får dock "Out of bounds" (- [6.6kΩ]), med status Normal om jag öppnar båda MK samtidigt.
Något jag helt klart inte fattat.
Är det fel motstådskombination?
Eller skall det till någon annan konfiguration på sektionen (har inte hittat något jag förstår mig på i web-admin-ui't)?
Tacksam för tips!
Jag har 2 MK i serie på samma sektion. Ett 2.2k motstånd över resp MK. Ett 2.2k motstånd som slutmotstånd.
Konfat sektionen med DUB BAL 2k2 2k2.
Ger larm fint när jag öppnar respektive MK individuellt. Får dock "Out of bounds" (- [6.6kΩ]), med status Normal om jag öppnar båda MK samtidigt.
Något jag helt klart inte fattat.
Är det fel motstådskombination?
Eller skall det till någon annan konfiguration på sektionen (har inte hittat något jag förstår mig på i web-admin-ui't)?
Tacksam för tips!
Vi har fått en SPC4320 på jobbet och trots att det är nyligen uppdaterat till firmware 3.6.5 så kvarstår problemet att det kör SSL v3 och alltså inte funkar med Chrome eller Firefox utan man måste använda IE och dessutom specialinställningar. Är det verkligen sant att detta inte är fixat än eller har jag missuppfattat något?
@svartöra: Med firefox kan du återaktivera sslv3 på lätt.
https://www.bfccomputing.com/re-enable-sslv3-on-firefox-34/
https://www.bfccomputing.com/re-enable-sslv3-on-firefox-34/
Tack för tipset, det visste jag inte. Nu går det ju i det här fallet lika "bra" med IE11, men det känns inte bra att behöva skruva ner säkerheten i webläsaren bara för att Siemens inte orkat fixa detta. Hoppas de skärper sig.batteur skrev:
Nu vet jag inte hur det är i den senaste versionen men i 3.4.5 finns inget sätt att byta certifikat i SPC. Således är det svårt att få till en korrekt certifikatskedja mot SPC. Det jag vill komma till är att om du tvingas till att svara ja på ett felaktigt certifikat vid anslutning kan du lika gärna köra okrypterat, alltså HTTP. Det gäller SPC, och det gäller på Internet. Något många inte känner till eller tänker på.
@Pewh
Nu ska jag inte utge mig för att vara någon IT säkerhetsexpert, men visst är det så att cerifikatet endast talar om för webbläsaren att den kommit till en OK webbserver. Ett självsignerat certifikat behöver i sig inte vara osäkrare än ett riktigt utfärdat certifikat.
Krypteringen däremot är väl till för att försvåra tolkningen av informationen för de som lyckas avlyssna trafiken. Så jag tycker nog att man alltid ska köra krypterat även mot webbservrar med självsignerade certifikat.
Sen anser jag rent allmänt att man ska undvika alla molntjänster som "erbjuds" oss, men det är en annan diskussion.
//Göran
Nu ska jag inte utge mig för att vara någon IT säkerhetsexpert, men visst är det så att cerifikatet endast talar om för webbläsaren att den kommit till en OK webbserver. Ett självsignerat certifikat behöver i sig inte vara osäkrare än ett riktigt utfärdat certifikat.
Krypteringen däremot är väl till för att försvåra tolkningen av informationen för de som lyckas avlyssna trafiken. Så jag tycker nog att man alltid ska köra krypterat även mot webbservrar med självsignerade certifikat.
Sen anser jag rent allmänt att man ska undvika alla molntjänster som "erbjuds" oss, men det är en annan diskussion.
//Göran
@gol
Helt korrekt att certifikatet talar om för en klient att webbservern är ok, men allt bygger på förtroende. Förtroende för det certifikat webbservern visar upp. Surfar du till en webbsida som har ett självsignerat certifikat som du litar får du ingen certifikatsvarning och där är då säkerheten lika god som med vilket annat certifikat som helst. Precis som du skriver @gol. Problemet uppkommer när du tvingas svara ja på en certifikatsfråga för att komma vidare. Något i certet är då fel. Det kan vara tre saker, url, giltighetstid och/eller revokering. Kika på nedanstående video, där syns tydligt var jag menar. Användaren surfar till Gmail, svarar slentrianmässigt på en fråga om certfel och vips så är lösenord i fel händer.
https://www.youtube.com/watch?v=y-gF3iyscxc
I min central är certifikatet utfärdat till "spc". Jag anropar den med "spc.mydomain.com". Min webläsare kastar då ur sig ett fel eftersom URL:en på certet och det jag anropar inte stämmer. Nu kanske det går att ändra i SPC. Det är mer än jag vet och det är då en helt annan sak. Då kan jag lägga in certet i mitt Root-store och slippa varningen.
Helt korrekt att certifikatet talar om för en klient att webbservern är ok, men allt bygger på förtroende. Förtroende för det certifikat webbservern visar upp. Surfar du till en webbsida som har ett självsignerat certifikat som du litar får du ingen certifikatsvarning och där är då säkerheten lika god som med vilket annat certifikat som helst. Precis som du skriver @gol. Problemet uppkommer när du tvingas svara ja på en certifikatsfråga för att komma vidare. Något i certet är då fel. Det kan vara tre saker, url, giltighetstid och/eller revokering. Kika på nedanstående video, där syns tydligt var jag menar. Användaren surfar till Gmail, svarar slentrianmässigt på en fråga om certfel och vips så är lösenord i fel händer.
https://www.youtube.com/watch?v=y-gF3iyscxc
I min central är certifikatet utfärdat till "spc". Jag anropar den med "spc.mydomain.com". Min webläsare kastar då ur sig ett fel eftersom URL:en på certet och det jag anropar inte stämmer. Nu kanske det går att ändra i SPC. Det är mer än jag vet och det är då en helt annan sak. Då kan jag lägga in certet i mitt Root-store och slippa varningen.
@Pewh
Jo jag är bekant med Man In The Middle attacker. Men jag anser att du sänker säkerhetsnivån ytterligare genom att dessutom ta bort krypteringen.
Om du tar parallellen att din förbindelse mellan webbläsaren och webbservern skulle vara en slang, För att göra ett MITH angrepp så måste vederbörande i princip klippa sönder slangen och koppla in en förgrening till en sniffer. I det fallet håller jag med om att det antagligen inte har någon betydelse att förbindelsen är krypterad eftersom "Mannen i mitten" har lurat dig att använda sina krypteringsnycklar.
Men tar du dessutom allmänt bort krypteringen så blir dessutom hela slangen transparent för alla som vill titta på det du skickar i slangen. Vilket är ju ännu värre.
Jag håller självklart med dig om att det bör finnas både pålitliga certifikat och svårknäckt kryptering. Men bara för du saknar det ena så behöver du ju inte göra saken värre och ta bort det andra.
Jo jag är bekant med Man In The Middle attacker. Men jag anser att du sänker säkerhetsnivån ytterligare genom att dessutom ta bort krypteringen.
Om du tar parallellen att din förbindelse mellan webbläsaren och webbservern skulle vara en slang, För att göra ett MITH angrepp så måste vederbörande i princip klippa sönder slangen och koppla in en förgrening till en sniffer. I det fallet håller jag med om att det antagligen inte har någon betydelse att förbindelsen är krypterad eftersom "Mannen i mitten" har lurat dig att använda sina krypteringsnycklar.
Men tar du dessutom allmänt bort krypteringen så blir dessutom hela slangen transparent för alla som vill titta på det du skickar i slangen. Vilket är ju ännu värre.
Jag håller självklart med dig om att det bör finnas både pålitliga certifikat och svårknäckt kryptering. Men bara för du saknar det ena så behöver du ju inte göra saken värre och ta bort det andra.
Någon som hade en tanke ang detta?xCxJx skrev:
@xCxJx
Rent tekniskt kan du naturligtvis stänga av/på kamerorna när larmet deaktiveras/aktiveras. Du skulle ju t.ex kunna styra, direkt från en utgång från SPC-larmet, spänningsmatningen till kamerorna eller spänningsmatningen till en switch där kamerorna är anslutna. Detta känns dock som en onödigt tillkrånglad metod för att du ska känna dig trygg.
Till syven och sist är det ju ändå intrångsskyddet av ditt hemmanätverk som har störst betydelse för din trygghet. En "hackare" som är inne på ditt nätverk skulle ju i värsta fall kunna ta över ditt larm inklusive kameror.
Det finns ju mängder av riktlinjer hur man säkrar upp sitt nätverk. För att bara nämna några allmänna saker som kan vara bra att tänka på:
- Undvik helst helt eller säkra upp ditt WiFi med så stark kryptering som möjligt och svårknäckta lösenord på routrar.
- Alla enheter på ditt lokala nätverk (t.ex kamerorna) ska vara försedda med svårknäckta lösenord.
- Undvik alla typer av molntjänster. Helst även SPC Connect. Om du ändå vill använda SPC Connect så är det extra viktigt att du har svåra lösenord och stryper tjänsterna så långt som möjligt. Du behöver ju inte t.ex inte spegla över dina kameror eller tillåta några kommandon från SPC Connect.
- För fjärråtkomst sätt upp en egen VPN-server.
Sen är det ju ändå var och en som själv måste avväga mellan IT-säkerhet, användbarhet, kostnader och trygghet.
//Göran
Rent tekniskt kan du naturligtvis stänga av/på kamerorna när larmet deaktiveras/aktiveras. Du skulle ju t.ex kunna styra, direkt från en utgång från SPC-larmet, spänningsmatningen till kamerorna eller spänningsmatningen till en switch där kamerorna är anslutna. Detta känns dock som en onödigt tillkrånglad metod för att du ska känna dig trygg.
Till syven och sist är det ju ändå intrångsskyddet av ditt hemmanätverk som har störst betydelse för din trygghet. En "hackare" som är inne på ditt nätverk skulle ju i värsta fall kunna ta över ditt larm inklusive kameror.
Det finns ju mängder av riktlinjer hur man säkrar upp sitt nätverk. För att bara nämna några allmänna saker som kan vara bra att tänka på:
- Undvik helst helt eller säkra upp ditt WiFi med så stark kryptering som möjligt och svårknäckta lösenord på routrar.
- Alla enheter på ditt lokala nätverk (t.ex kamerorna) ska vara försedda med svårknäckta lösenord.
- Undvik alla typer av molntjänster. Helst även SPC Connect. Om du ändå vill använda SPC Connect så är det extra viktigt att du har svåra lösenord och stryper tjänsterna så långt som möjligt. Du behöver ju inte t.ex inte spegla över dina kameror eller tillåta några kommandon från SPC Connect.
- För fjärråtkomst sätt upp en egen VPN-server.
Sen är det ju ändå var och en som själv måste avväga mellan IT-säkerhet, användbarhet, kostnader och trygghet.
//Göran
Redigerat: