Block MySQL (port 3306) connects from the outside?

johnpoz

Yeah dok yet another one thinking connections are piggy backing in his outbound connection and talking to his sql server..

MMacD

@doktornotor:

What's this thing? Another tinfoil hat thread? ::) >:(

Nope. It started out as me trying to determine whether MariaDB listening on 3306 was enough to bypass the default block on the WAN port and allow some random chancer to connect from the inet.

Since when I connect to some site A there certainly are ports being attached by unrelated sites B, C, and D in apparent defiance of the same-origin policy that is supposed to prevent cross-site scripting attacks, the question seemed like an important one.

A partial selection from netstat -ao generated by exactly TWO intentional connects: this site and truth-out.org:

TCP slowcat:2890 edge-star-shv-01-lga1.facebook.com:https ESTABLISHED
TCP slowcat:2891 a23-33-44-73.deploy.static.akamaitechnologies.com:http TI
0
TCP slowcat:2892 edge-star-shv-01-lga1.facebook.com:https ESTABLISHED
TCP slowcat:2893 ec2-54-88-159-215.compute-1.amazonaws.com:http ESTABLISHE

TCP slowcat:2894 165.254.0.16:http TIME_WAIT 0
TCP slowcat:2896 ec2-54-88-159-215.compute-1.amazonaws.com:http TIME_WAIT
TCP slowcat:2897 ec2-54-88-159-215.compute-1.amazonaws.com:http TIME_WAIT
TCP slowcat:2898 165.254.0.16:http TIME_WAIT 0
TCP slowcat:2900 ec2-54-88-159-215.compute-1.amazonaws.com:http TIME_WAIT
TCP slowcat:2901 199.16.157.105:https ESTABLISHED 2624
TCP slowcat:2902 ec2-54-84-234-32.compute-1.amazonaws.com:http ESTABLISHED
TCP slowcat:2903 199.16.157.105:https ESTABLISHED 2624
TCP slowcat:2904 ec2-54-84-234-32.compute-1.amazonaws.com:http TIME_WAIT
TCP slowcat:2905 lga15s42-in-f30.1e100.net:http ESTABLISHED 2624
TCP slowcat:2906 165.254.0.11:http ESTABLISHED 2624
TCP slowcat:2907 165.254.0.11:http ESTABLISHED 2624
TCP slowcat:2908 lga15s42-in-f30.1e100.net:http TIME_WAIT 0
TCP slowcat:2909 lga15s42-in-f30.1e100.net:http TIME_WAIT 0
TCP slowcat:2910 165.254.0.11:http TIME_WAIT 0
TCP slowcat:2911 165.254.0.26:http TIME_WAIT 0
TCP slowcat:2912 165.254.0.11:http TIME_WAIT 0
TCP slowcat:2913 lga15s42-in-f30.1e100.net:http TIME_WAIT 0
TCP slowcat:2914 165.254.0.26:http TIME_WAIT 0
TCP slowcat:2915 map-e.pipelane.net:http TIME_WAIT 0
TCP slowcat:2916 70.42.33.241:http TIME_WAIT 0
TCP slowcat:2917 ec2-52-1-141-196.compute-1.amazonaws.com:http ESTABLISHED
TCP slowcat:2918 ec2-54-210-200-97.compute-1.amazonaws.com:http ESTABLISHED

Why isn't the default block scraping them off? Because they came through on truthout's tuppence? Anything, no matter what the origin, can get past the global block and establish a persistent connection even when the "official" connect is the stateless http? That just doesn't feel appropriate to me.

johnpoz

dude what part do you not understand about your machine making connections??? You think those are inbound connections to your machine?? To those random ports? You really just don't even understand basic tcp do you??

Oh my gawd I am being hacked

TCP 192.168.9.100:1057 162.222.41.239:443 ESTABLISHED
TCP 192.168.9.100:1058 209.191.165.124:5938 ESTABLISHED
TCP 192.168.9.100:1061 216.17.8.48:443 ESTABLISHED
TCP 192.168.9.100:1062 192.168.9.8:445 ESTABLISHED
TCP 192.168.9.100:1068 173.194.192.125:443 ESTABLISHED
TCP 192.168.9.100:1075 17.143.162.211:5223 ESTABLISHED
TCP 192.168.9.100:1077 172.226.82.30:443 CLOSE_WAIT
TCP 192.168.9.100:1126 108.161.147.131:993 ESTABLISHED
TCP 192.168.9.100:1450 128.121.22.176:443 CLOSE_WAIT
TCP 192.168.9.100:1458 192.241.165.183:443 CLOSE_WAIT
TCP 192.168.9.100:1459 128.121.22.176:443 CLOSE_WAIT
TCP 192.168.9.100:1504 192.241.165.183:443 CLOSE_WAIT
TCP 192.168.9.100:1617 192.241.165.183:443 CLOSE_WAIT
TCP 192.168.9.100:1626 192.241.165.183:443 CLOSE_WAIT
TCP 192.168.9.100:1635 128.121.22.176:443 CLOSE_WAIT
TCP 192.168.9.100:1720 128.121.22.176:443 CLOSE_WAIT
TCP 192.168.9.100:5400 45.58.74.129:443 CLOSE_WAIT
TCP 192.168.9.100:5835 192.241.165.183:443 ESTABLISHED
TCP 192.168.9.100:6026 108.160.165.33:443 ESTABLISHED
TCP 192.168.9.100:6536 107.20.249.126:443 CLOSE_WAIT
TCP 192.168.9.100:6565 198.41.206.204:443 ESTABLISHED
TCP 192.168.9.100:6569 17.151.226.69:443 CLOSE_WAIT
TCP 192.168.9.100:6572 54.230.88.117:443 CLOSE_WAIT
TCP 192.168.9.100:6599 37.48.81.86:443 ESTABLISHED
TCP 192.168.9.100:6600 208.123.73.18:443 ESTABLISHED
TCP 192.168.9.100:6601 208.123.73.18:443 ESTABLISHED
TCP 192.168.9.100:6602 208.123.73.18:443 ESTABLISHED
TCP 192.168.9.100:6604 37.48.81.86:443 ESTABLISHED

Why don't you sniff on your machine and watch it create all the connections!!

So for example this
199.16.157.105

if you hit via https like you are, its a twitter ssl cert

The certificate is only valid for the following names: syndication.twitter.com, cdn.syndication.twitter.com, syndication-o.twitter.com, syndication.twimg.com, cdn.syndication.twimg.com, syndication-o.twimg.com

So you think twitter connecting to you from source port of 443 to your 2903, or did your machine make that connection?? ;) If I go to truth-out.org guess what it goes to twitter!!

truthtwitter.png_thumb

Guest

Hmm I really tried up to follow this thread fully but I can´t! Sorry for that.

If the Maria DB is behind NAT and no ports are opened and forwarded to the Maria DB, so they cannot
be connected from the outside.

And by the way placing all in one LAN is the really danger here as I see it right.
Please create a DMZ for the Apache Webserver to get in contact with the Internet
and place the Maria DB in the LAN what should be saved.

It is like a bit with your PC or Laptop, on this software firewalls also ports are open
and they connect from time to time the Internet for updates, but they are not reachable
from the Internet because they are behind NAT!

MMacD

@johnpoz:

dude what part do you not understand about your machine making connections??? You think those are inbound connections to your machine?? To those random ports? You really just don't even understand basic tcp do you??

This is starting to become funny, in a kind of unfunny way. You're saying that my machine is making those connects? Spontaneously? No outside motivation?! Just the machine itself is taking the decision to connect? I hope you're not, because my machine isn't that autonomous.

What should be happening is that I call the browser's HTTP GET routine, which SYN/ACK handshakes with some site foo.org and then sends the actual page request. Foo.org provides the page I requested, and since HTTP is stateless, drops the connect and forgets about me. Any time I want another page, the browser has to go through the same process again. (I did a quick check and HTTP still appears to be a stateless protocol)

Nowhere in that process is a request directed to bar.com for a persistent connect. My browser doesn't even know bar.com exists. So who's doing it? Is foo.org saying "here's the page you wanted and oh by the way here's a SYN on behalf of bar.com so please ACK/SYN it and let bar.com set up a persistent connect"? If that's what's happening, I'd say the firewall isn't looking carefully enough at what's going on.

johnpoz

Yes dude why don't you look at the what happens when you open a browser page.. yes going to truth-out.org tells your machine to go to twitter stuff and facebook stuff. What do you not understand about this??

Depending on the site and ads you could end up with hundreds of connections.. To who knows where..

Your browser reads the code in a page, and follows it - if the code says hey open this up.. Guess what it tells your machine to open that up.. Pfsense just says hey your sending syn to this, rules allow it - there you go..

You really should look at the source of the sites you go to, or open use say web developer in browser like I posted and it shows you all the stuff it does a GET for, etc.. Or just fire up wireshark on yoru machine and watch where the syn's come from.

MMacD

@BlueKobold:

Hmm I really tried up to follow this thread fully but I can´t! Sorry for that.

If the Maria DB is behind NAT and no ports are opened and forwarded to the Maria DB, so they cannot be connected from the outside.

That's how the whole thread got started – MariaDB is listening on 3306, and since the firewall box is the designated gateway, it's the 3306 on that box that's being listened on (actually, I hope that by having done bind-address=127.0.0.1 I've forced it to only play with the loopback, but that came later)

And by the way placing all in one LAN is the really danger here as I see it right. Please create a DMZ for the Apache Webserver to get in contact with the Internet and place the Maria DB in the LAN what should be saved.

This is a dev machine, so I don't really want Apache to talk to the inet either. It's only supposed to serve the lan, and I think I've got the permits set for that even though their documentation for the new v2.4 scheme isn't the best.

johnpoz

"MariaDB is listening on 3306, and since the firewall box is the designated gateway, it's the 3306 on that box that's being listened on"

What??? NO pfsense is not listening on 3306 because some box behind it is?? Did you forward port 3306??

MMacD

@johnpoz:

What do you not understand about this??

I don't understand why the firewall isn't interfering with such piggybacking.

johnpoz

there is NO PIGGY BACKING!!! dude you open up a web page it tells your machine to open up other stuff! Period END of story.. What do you not understand?? Really open up that site and look at the source code, fire up wireshark and what what happens.. Where do the Syns come from.. Use something like web developer in fire fox that shows what your browser is doing where its going, what the GETS are, etc..

so you understand what an iframe is?? So for example on your truth site


<iframe src="//www.facebook.com/plugins/like.php?href=http%3A%2F%2Fwww.facebook.com%2FTruthout.org&amp;send=false&amp;layout=button_count&amp;width=120&amp;show_faces=false&amp;action=like&amp;colorscheme=light&amp;font&amp;height=21&amp;appId=174773479325394" frameborder="0" scrolling="no" width="150px" height="21px" allowtransparency="true" style="border: none; overflow: hidden; width: 150px; height: 21px;"></iframe>

What does that tell your browser to do? what do you think this code does

Which is loaded from platform.twitter.com – guess your browser is going to go there as well.. So the firewall will allow it because your rules do.. There is no Piggy backing..

If you have connections on your machine that you don not understand, then I suggest you investigate -- but it sure its not pfsense letting connections in via other connections.. Your box started the connection, or you forwarded the traffic in.. This is how a firewall works. If your seeing connections to stuff you do not understand then why don't you investigate that - run wireshark on your machine.. What all the connections it makes when your not doing stuff ;) You will see in my listing of netstat connections from teamviewer, connection from meraki cisco client on this machine. dropbox checks in with home all the time.. Yes pfsense allows these connections because of your rules on your lan - which out of the box is any any!

Guest

That's how the whole thread got started – MariaDB is listening on 3306, and since the firewall box is the designated gateway, it's the 3306 on that box that's being listened on

This is rubbish! Sorry but if I have a server or a program that is listening on one or more
ports, but it is behind a lazy consumer router doing SPI/NAT, there is no was from the outside
to connect to that program or such a server! Point.

So if I will get your IP address, I can not do anything with it if all ports on your firewall or router are closed
an they will be doing SPI/NAT. Only if I am opening at the WAN Interface (WAN Port) ports and forward them
to the internal private IP address of the Maria DB host it will work that the Maria DB is able to connect from
the outside.

MMacD

I need to suspend this conversation awhile. I'll be back.

doktornotor

@MMacD:

I'll be back.

No need really for this conversation to continue. Negative net value in this thread.

johnpoz

Yeah do a little reading on how tcp works and what a stateful firewall is and how web pages work ;)