I am not able to connect to vulnserver using netcat.
I type this to connect
nc -nv 192.168.70.130 9999
(UNKNOWN) [192.168.70.130] 9999 (?) open
and it says this forever and doesn't happen anything
I have disabled real time protection, allowed in firewall and also VM is set to NAT mode.
Is there any other way to connect or what might be the possible issue.
I have also encountered the same issue. I thought it was my VM acting up, so I restarted the network access. I tried allowing vulnserver.exe through my windows firewall. Neither of them solved the issue. Finally, I disabled windows defender firewall and now it works like a charm. But before doing this, try to ping the windows machine from the linux box. If there's a response it should work. If there is no response however, try enabling file and printer sharing in windows. For more info, read this...https://superuser.com/questions/1137912/ping-to-windows-10-not-working-if-file-and-printer-sharing-is-turned-off
Immunity Debugger and vulnserver has to run as administrator, then Immunity Debugger can see vulnserver, otherwise Im..Deb can't see because of less privileged then vulnserver.
Also we need run Immunity Debugger
That's mean port 9999 has already been opened which is expected if you're already executed vulnserver
wolf#linux:~$ nc -nv 127.0.0.1 9999
(UNKNOWN) [127.0.0.1] 9999 (?) open
Welcome to Vulnerable Server! Enter HELP for help.
It also means that you've already connected to the server. Go ahead and type HELP to see more info.
Try to setup using different network mode such as internal or host-only mode.
I just had a similar issue - I'm not sure if you are using it in conjunction with Immunity Debugger like me (as part of an ethical hacking course) but I kept getting that situation because I forgot to hit 'play' on the debugger.
Related
I am trying to ssh into a ubuntu machine from my mac
but I am getting
setsockopt SO_KEEPALIVE: Invalid argument
write: Broken pipe
as soon as I type in ssh address
and changing ssh_config including TCPKeepAlive, ServerAliveInterval do not fix my issue.
Does anyone know what might be happening?
Server is running on ubuntu
I found that server and client are on different network
Therefore my machine was unable to find the target server machine of the given ip address.
(ya I know.. such failure should be more descriptive)
I hope this answer helps the other people experiencing similar issue
I saw this when the connection was dropped straight away (a firewall it seems).
Presumably it ends up calling setsockopt() on a socket that just closed.
I am using Putty to ssh into some of the servers that I work on. I am able to connect all others except the one. Although I was able to connect to it before. Whenever I try connecting to it, it always give me error:
Unable to open connection on myhost: Host does not exist
My firewall is off and I have even re-installed putty but that did not fix it. When I tried connecting to the same server using putty on some other windows system, I was able to do so. I searched regarding this on Internet but did not find much relevant.
I am running putty on Windows 7.
What can be the possible issue?
As I understand you have three computers involved. At the same time one connection is working and the other one fails. So we can exclude that the ssh daemon on your linux box is hanging.
In lack of knowing their real names I will call your computers linuxbox (this is the computer you want to ssh into), win7ok (that is the computer that you are able to ssh from using putty) and win7fail (that obviously is the computer you can't connect from).
Please do a tracert from both Win7 computers:
tracert linuxbox.your.domain
tracert linuxbox
Add the results to your question as it will help us find out what is happening.
Perhaps it is also a good idea to determine the ip address of the linuxbox from win7ok:
ping linuxbox
or
nslookup linuxbox
Then try to connect from win7fail by using the ip address of the target computer, perhaps it is only a DNS problem (which might be as nmap is failing too).
To make all of this easier to understand for us please provide the real names of the computers as you use them in putty.
For me the problem was with the Url of the reposity. Check remote URL. It must start with git#github.com, not https://.
I used nslookup and then used the ip address it gave me to connect and it worked
I had a similar problem with GitExtensions. The solution was to remove the https url and replace it with git#gitlab....
WRONG:
GOOD:
I just went through this. I have a Cisco VPN I need to use to get through to the Linux machine I wanted to login to and check.
No Putty session would get through using the machines name.
An nslookup on the windows machine yielded the correct address.
I too connected right in via the ip address.
I tried to Google the error and it failed, so I suspected the wireless.
Disconnected and reconnected my WiFi and all was good.
I did it fast enough that open connections stayed open.
And new connections refering to DNS names worked fine.
Seems like maybe some cached DNS addresses were stale.
Your DNS cache stores the locations (IP addresses) of web servers that contain web pages which you have recently viewed. If the location of the web server changes before the entry in your DNS cache updates, you can no longer access the site.
Following CLI command will do the trick:
ipconfig /flushdns
Very new to the Self Host WebApi, but I am very impressed with its ease of use and extendability. At least through this tutorial. Everything I've done so far works on my development machine whether I use localhost, 127.0.0.1, or my LAN Ip (192.168.0.x) but I am baffled why I can't access the service from any other computer even others in the same subnet.
In short after going through the tutorial on the machine where it is running:
Browsing to
localhost:3636/api/products/
results in the expected xml return.
On another machine on the LAN browsing to:
192.168.0.x:3636/api/products/
results in a timeout
Data points for those who might know how this all interacts:
1.) My dev machine(192.168.0.x, server, host whatever you want to call it) has IIS on it; I was so paranoid it was in the way that I stopped it via the Administration GUI
2.) I have reserved the URL/Port with the following command line executions:
>netsh http add urlacl url=http://+:3636/ user=DOMAIN\USER listen=yes delegate=yes
>netsh http add urlacl url=http://192.168.0.x:3636/ user=DOMAIN\USER listen=yes delegate=yes
2.b) I've tried both of those together and individually, and tried changing the user to "everyone" to no avail
3.) I have tried to change the code in the tutorial to set the
config.HostNameComparisonMode = HostNameComparisonMode.Exact //default is Strong Wildcard
4.) I can successfully ping and tracert to 192.168.0.x from other machines on the LAN
5.) A friend recommended I setup a TCPListener and ensure I could telnet to that to eliminate the firewall as a possibility. If that logic is sound, the firewall isn't the problem
EDIT: Thanks for your help, here's another data point that I believe confirms it's not a firewall issue. I previously posted this connection when behind a rather obtuse (at least to a non Certified guy like me) Juniper Firewall/Router. I have since redone the tutorial on another machine (without IIS) on my home network and still cannot publish the service to other computers within my LAN. Any ideas?
Well it wasn't the hardware firewall, it was the windows firewall! yikes i wasted a bunch of time on that. Once I turned off the windows firewall (the code runs in an intranet anyway) everything worked.
Anyone know of a good site that explains how firewalls and wireshark interact; or i suppose that just has to be one's first test.
I would try a couple things:
First off, get rid of the HostNameComparisonMode line. That might actually disable requests coming from other machines.
If things still don't work, try getting rid of the URL ACLs and run your application as an administrator and see if that works. If that works, you may be able to add the URL ACL back on and not have to run as an administrator. You should only need the one with '+' as the hostname.
I faced the same problem when i tried to self host using OWIN. What worked for me was -
Run Visual Studio as an Admin
Remove any and all netsh urlacl port registrations that I had added while debugging this issue
Add a inbound rule to my windows firewall
I followed the instructions on this link
https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/firewall-instructions
Check out the section - To enable a port range in advance
That's it! I was able to call my api from other computers on the network.
Hope this helps...
I am facing same problem to the thread. I've gone through all the suggestions provided in the solution. I've searched all possible solution but nothing gonna workout.
"http://stackoverflow.com/questions/817745/localhost-not-working-on-xampp-both-service-apache-mysql-are-fine"
I've ensured :
1. Xampp is successfully started (in log) but it is not receiving any request(checked access.log).
also ensured that it is running on port 80 in config file.
confirmed status of application using netstat
C:\Documents and Settings\user>netstat -aon | grep 80
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 3524
Checked host file in /windows/system32/drivers/etc/hosts and has only one entry
127.0.0.1 localhost
skype teamviewer or other application are closed and configured not to use port 80.
ensured that windows firewall allows http process to use port 80.
pinged localhost, 127.0.0.1 and my ip (192.168.1.2). localhost resolves to 127.0.0.1
tried different urls http:// localhost http:// localhost:80 http:// 127.0.0.1 http:// laptop-name but nothing works. browser just waits for response (spaces after http to allow links in this post)
ensured that there is no loop in index.php(it is untouched) and also has index.html. also tried diffent paths
nothing gonnna work out. I am irritated and I dont want to format my machine. please help....
when this happens to me it is usually Skype taking over the default localhost address
Check on command prompt
netstat -a -b
And close any other application like skype etc using 80 port.
Try stopping IIS. It worked for me.
Select Start, then type IIS in the search box
select Internet Information Services Manager
In the manager on the right under "Manage server"select "stop"
I was having an issue with Last.fm that is very similar to yours, and I found that it was a software conflict.
The Last FM scrobbler application would not finish installing on my new build because it couldn't login or authenticate my username. I tried the regular scrobbler application and then tried the beta desktop program on Windows 7 64 bit. I suspected Skype or TeamViewer, but even after stopping or exiting those programs, neither versions of the installation would log in to the services.
The beta desktop application actually authenticated on 127.0.0.1 (random port) through my internet browser, but my browser would time out trying to send data over the port.
I checked and edited my HOSTS file in Windows, but that didn't fix the issue either.
Pinging 127.0.0.1 worked, but pinging any variation of the port would time out.
Finally, I decided to uninstall the Windows 7 Firewall Control program made by Sphinx Software. Mind you, I had set the firewall to be disabled at start up (clean start-up - all startup programs disabled through MSConfig).
I made sure that the firewall program was not running at all in my services. However, after uninstalling the software, even without restarting my computer, 127.0.0.1 opened up on all ports and my Last.fm scrobbler finally connected and finished installation.
So, it may be a hidden setting that can only be undone by uninstalling programs (even programs that aren't running).
For me localhost was not the correct address.
Type into cmd "hostname" and use that as the url.
CMD -> hostname
If that doesn't work try just the ip address of the server (or computer)
I stored my website folder in xamp/htdocs (windows machine). Then I started apache on the XAMP control panel. My pages rendered successfully when I called http://localhost/mysite/index.html.
I hope this is helpful.
We have oracle 10g running on windows server 2003. A machine which runs an application using that database has as of a few weeks ago suddenly started having connectivity problems. Today we ran the automatic updates for windows server and the problem has only gotten worse. I realize this isn't enough information for anyone to diagnose the problem but perhaps you can get me pointed in the right direction with the following more specific scenario:
From this machine we can ping the server with absolutely no problem and, being physically close and on an intranet the return is very fast.
However, when we run tnsping I have seen 3 different results within a few minutes of each other.
tnsping returns just fine and in a reasonable amount of time
tnsping returns but only after a real long time (several seconds)
tnsping results in an ora-12560 protocol adapter error
At the same time I can tnsping the server from my machine with no problem.
Can anyone point me in the right direction?
I'd try to check the following:
do traceroute from the app server and from your machine check for anything abnormal
check tnsping from various other machine and try to identify a pattern
try a tcp/ip sniffer to see what is going on at both ends of the connection
get oracle support involved
To help eliminate DNS issues from the equation, specify the host's IP address in the TNSNAMES.ora file for your connection instead of a hostname. Are you using DHCP?
Have you eliminated hardware as the problem - have you tried a different NIC?
Before calling Oracle, I would create a trace file for a Fail case.
TNSPING.TRACE_LEVEL
Purpose
Use the parameter TNSPING.TRACE_LEVEL to turn TNSPING utility tracing on, at a specific level, or off.
Default
off
Values
* off: for no trace output
* user: for user trace information
* admin: for administration trace information
* support: for Oracle Support Services trace information
Example
TNSPING.TRACE_LEVEL=admin
Before involving oracle in this issue, get some help from your network administrator for the following test. First enable verbose logging on the database in the listener. Enable logging on the client via sqlnet. Go to the machine that is having trouble with tnsping, have the network administrator run a network tool to trace tcp packets from there. Perform the tnsping and see if what packet are being sent, what dns lookup are being made, what route is being taken. On the database see if the listener actually receives a ping from the client. If not then see where along the network to the database the problem is. Is it nameserver resolution? Is it a bad network cable, bad switch port, etc. Your network admin is your best friend for this problem. Do the same test via sqlplus with a simple connection and see what the client is logging.
Make sure there is no other machine on the network with the same IP address. A method would be unplug your machine from the network and see if you can still ping it. If you can then this is the problem.
If the server doesn't have a domain-name setup at a dns server, then add it's ip address and name to the host file on the server; this (the server not being able to find itself in dns) has been known to cause tns timeouts.