zahni

Ist auf PC1 eine Firewall an? Dann wird u.U. ICMP blockiert.

Nun überlege noch mal. PC1 hat die Adresse 192.1.0.1 im Subnet 255.255.0.0 Du pingst 192.1.1.2 an. Diese Ping wird nicht über den Router geschickt, da der PC entscheidet, dass es sein lokales Netz ist. Der PC hinter einem Router, also in einem anderen Layer2-Netz, kann mit dieser Adresse niemals erreicht werden. Es würde z.B. funktionieren, wenn der die Adresse 192.2.1.2 hätte. Bei beide am gleichen Layer2-Netz hängen, sieht die Sache ein wenig anders aus. Dass wollte ich damit schreiben.

Der Client entscheidet in beiden Fällen, dass eine Zieladresse sich in seinem Netz befindet und er die Router in Ruhe gelassen werden kann. Dann kommt für Ziel-MAC-Adresse ARP ins Spiel. Hier fühlen sich dann auch alle passenden Geräte, völlig Subnet-Frei, angesprochen. . Probiere mal folgendes aus: 2 PC's, einer mit der IP-Adresse 192.1.1.1 und einer mit der Adresse 192.1.1.2 . Nun trägst Du auf beiden Geräten eine wahlfreie unterschiedliche Subnet-Mask ein. Das Default-GW bleibt leer (!). Können sich beide Geräte "Pingen"? Nun gibt Du beiden Geräten völlig unterschiedliche Adressen. Wieder ohne Default-GW. Können beide Geräte sich anpingen? Nun installierst Du mal Netmon oder Wiresharkk und verfolgst das ARP-Protokoll.

Wenn bei dem 1. Netz der Netz-Teil der Adresse 192.1. lautet, kann es dann eine Adresse 192.1.1.1 geben ? Kann es im Netz 192.1.1 eine Adresse 192.1.1.1 ? Wenn Du jetzt 2x ja ankreuzt, hast Du gewonnen ;). Netz-Maske ist nur dem jeweiligen Netzwerkgerät bekannt und dient nur dem korrekten Routing. Will sagen: Der Windows-PC entscheidet anhand der Netzmaske und seiner Routing-Table wohin er ein Pakt schickt. Und die Router machen das Gleiche.

Solche Lösungen werden in großen Unternehmen eingesetzt. Sicher kann man es nicht verhindern. Man kann es den Usern aber erschweren. Damit es immer wieder in Bewusstsein kommt, was man als User darf und was nicht. Sehr oft ist keine böse Absicht in der dem Tun der User, sondern eher Unwissenheit oder es ihnen egal. Gern werden von Usern so "Verfahren" erdacht, bei dem der IT-Abteilung die Fußnägel hochrollen - wenn sie davon wüsste. Bekannte Cloud-Dienste lassen sich über einen Proxy schon blockieren.

Der Proxy untersucht auch gepackte Dateien, keine Sorge. Verschlüsselte Archive lassen sich auch blockieren. Die Einschränkung ist HTTPS. Hier lassen sich nur ganze Hosts blockieren. Oder man lässt den HTTPS-Tunnel am Proxy enden und verwendet intern ein eigenes Zertifikat. Ist aber sehr problematisch und sollte eher nicht gemacht werden. Für den Rest hilft die SRP (sieh weiter oben). Malware wird eher selten über HTTPS mit gültigen Zertifikaten verteilt.

Zu 2. Einen Proxy mit Filter einsetzen. Es gibt Produkte, die solche Listen regelmäßig aktualisieren. Generell kann man mit einem Proxy den größten Teil der binären Downloads (EXE, JAR, etc) blockieren. Ein Produkt wäre http://www.mcafee.com/de/products/web-gateway.aspx

Click & Run streamt APP-V Pakete. Das wird mit dem WSUS nicht. Man kann die aber wohl Offline bereitstellen. Oder man installiert Office 2013 "richtig".

Eventuell filtert das VPN-Gateway ein paar Ports oder Protokolle.

Das ist nun wirklich vom System abhängig. Frage doch mal den Hersteller.

Dann macht ein WSUS Sinn. Und Du hast mehr Kontrolle über die Updates. Man könnte sie z.B. vorher testen ;)

Wenn Du einen WSUS-Server verwendest, bekommst Du alle Updates.

Wenn die Daten im AD gepflegt sind, würde ich mal prüfen, ob die die anderen Anwendungen an das AD anbinden lassen. Im einfachsten Fall geht das über LDAP. U.U. kann man dann in Kombination auch ein SSO-Verfahren über NTLM oder Kerberos einführen. PS: Als Referenz: http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-71/112880-cucm-8x-ldap.html

Schau mal hier: http://de.wikipedia.org/wiki/File_Transfer_Protocol Speziell die Unterschiede "Aktiv" und "Passiv" Bei Passiven FTP muss der Server dem Client die richtige (öffentliche) IP-Adresse übermitteln und nicht seine NAT-Adresse.

Ich verstehe immer nicht, warum Du den aktuellen Benutzernamen von der Datenbank wissen willst. Wenn Deine Web-Anwendung im Browser SSO macht (aktuell wage ich das zu bezweifeln), bekommt Deine Anwendung die Daten vom jeweiligen Webserver. Den SQL-Server kannst Du damit in Ruhe lassen. Es gibt in PHP auch irgendeine Funktion, mit der man alle Server-Variablen dumpen kann.

Manchmal stimmt die Kodierung bestimmter Sonderzeichen nicht, wenn man etwas per Copy&Paste von einer Webseite kopiert. Das sieht dann optisch korrekt aus. Es ist aber ein Unterschied, ob man ' , ` oder ´ benutzt ;)

Das sehe ich ein wenig anders. Bei BCS meldet man sich optimaler weise mit einem im Secure Store hinterlegten Konto bei einer externen Datenquelle an. Die Zugriffsrechte auf diesen BCS kann man dann im BCS konfigurieren. Bei einem Webservice mag das im Speziellen anders sein. Bei Datenbanken sollte man das aber eher vermeiden. Direkt durchgereichte Datenbank-Anmeldungen wurden schon oft zum Hacken von (DB)-Servern verwendet.

Auch wenn die Anwendung sich per Browser-SSO anmeldet, sollt diese Anmeldung nicht an den SQL-Server durchgereicht werden. Nur als Beispiel: SharePoint macht das auch nicht. So etwas kann eine erhebliche Sicherheitslücke öffnen. Speziell wenn die Anwendung auch eine alternative Anmeldemöglichkeit bietet. Sie Anwendung selbst kenne ich nicht. Normalerweise kann man aber bei Web-Anwendungen via SSO den Usernamen aus den Servervariablen extrahieren. Bei ASP (vbscript) wäre dies Request.ServerVariables("AUTH_USER")

Ich kann hier nur allgemein antworten: Bei PHP gehe ich mal von einer Web-Anwendung aus. Es ist ein ganz schlechtes Design, wenn ein User sich über ein Web-Frontend direkt auf einen Datenbankserver anmeldet. Hier sollte nach Möglichkeit immer mit technischen Usern gearbeitet werden, deren Konten nicht weiter bekannt sind. Zum Session-Sharing zwischen anderen Anwendungen gibt es genügend Lösungen. Man schreibt die (User).Daten aber nicht ein Cookie. Selbstverständlich ist das auch Abhängig von der konkreten Anwendung.

Hier kann er doch weiterhüpfen: ;)

Am Einfachsten in der windowsupdate.log

So ist es immer: Von den Kunden werden die Informationen geglaubt, die am Besten in den Kram passen. Die sind dann auch "richtig" ;)

Welche Edition willst Du denn haben? PS: Für Foundation: http://www.microsoft.com/de-de/download/details.aspx?id=42039

Für 2012 R2 benötigst Du SP2013 SP1 . Ich wüsste nicht, dass man AppFabric händig konfigurieren müsste oder sollte. Die Prerequisites lässt Du man Besten vom Installer herunterladen und installieren Für den SQL-Server solltest Du einen Alias konfigurieren. Den Native Client für SQL 2012 kannst Du ebenfalls installieren.

Wenn Du NAT dazwischen hast, brauchst Du einen Tunnel: Also VPN.