Tag Info

New answers tagged

1

If the computer you are forwarding to is secure, then no, there isn't a risk, however if that computer gets compromised and it is inside the network, the attacker will then have access to anything that computer has access to. It is generally best to place an additional firewall between any computers answering requests from the Internet from the rest of your ...


2

All computers. Say whatever service is running on that port (e.g., web server, database server, etc) is found to be vulnerable to an attack that allows the attacker to execute any code of his choosing on the server (typically we call this a remote code execution attack). The attacker could leverage this to then begin attacking other computers on the ...


2

ISP will routinely do the following for their customers: Block incoming connections on some well-known ports (e.g. port 139, the classic port for Windows file sharing). Block spam, virus and other malware sent over email. "Block" some sites by removing the DNS mappings (the customer can still access them, but the ISP DNS server will not resolve the names). ...


11

From the access logs of a service (nginx, Dovecot, etc.), you cannot see whether you were affected or not. Unless you have previously captured all SSL traffic, you cannot see whether you got attacked in the past either. The pattern to match in a packet capture is very simple: A malicious Heartbeat request is sent. An overly long Heartbeat response is ...


0

(Disclaimer: I'm a "security student" myself, so I'm not 100% sure if this is correct.) I don't understand why you would want to keep private keys on the server after they are transferred to the user. There is no use for them. If they are lost - create new ones. Keys have a public and a private part. The public part can really be public and may be ...


2

When AD Certificate Services starts up, it insists on validating its own certificate (the subordinate CA certificate). This entails verifying that the CA certificate has not been revoked, by obtaining the CRL referenced from the CRL Distribution Points extension found in that certificate. If the CRL have been moved, and not up-to-date CRL can be found at ...


1

In addition, I would add that most attackers don't directly log in via the console or ssh, but instead use bugs in other software in order to break out into a root shell or elevate their privileges. Adding 2-factor authentication or other mechanisms will definitely improve your security posture, but must be viewed as part of a larger overall hardening ...


0

This is called two-factor authentication. It already exists, though it may not be trivial to implement in all cases.


2

The only way that I'm aware of for you to prove this "beyond any doubt" would be to have your client audit the servers themselves, or to have them audited by a 3rd party (e.g. consultant) that you both trust to do the work. Network scanning isn't likely to be sufficient on it's own as that wouldn't cover disabling services or the possibility that a firewall ...


2

Do a full scan of the target machine's IP address with Nmap from LAN or Internet: nmap -p- 12.34.56.78 If you've closed all the unused ports, then you'll see that in the scan result. Edit: It would look like this: Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-29 11:26 CET Nmap scan report for abc.com (12.34.56.78) Host is up (0.030s latency). Not ...



Top 50 recent answers are included