firewall pounding?

[TM]

seems my firewall has been taking a pounding from My_SQL, after logging into Uncle Bob's Picture Thread... not sure if this is normal or not, but it casued my firewall to lockout this site... just wanted to keep u in the loop on that...

[Johnny Revs]

that thread is evil :p :eek:

[mrbmc]

MySQL can't "pound" your server. That's not what it does. It's a database. When it does output data it's to another application running on the server, and it all stays within that machine. MySQL couldn't even send data to your firewall that'd trigger this problem 'cause MySQL runs on the wrong port.

Now... i'm not sure what's wrong with your shit, or why you even need a firewall in first place... or if you even know how to manage one... but i can assure you that it's not MySQL.



I hate when people say shit about technology they don't fully understand. The most dangerous thing is just a little bit of knowledge.




seems my firewall has been taking a pounding from My_SQL, after logging into Uncle Bob's Picture Thread... not sure if this is normal or not, but it casued my firewall to lockout this site... just wanted to keep u in the loop on that...

[Uncle Bobby]

MySQL can't "pound" your server. That's not what it does. It's a database. When it does output data it's to another application running on the server, and it all stays within that machine. MySQL couldn't even send data to your firewall that'd trigger this problem 'cause MySQL runs on the wrong port.

Now... i'm not sure what's wrong with your shit, or why you even need a firewall in first place... or if you even know how to manage one... but i can assure you that it's not MySQL.



I hate when people say shit about technology they don't fully understand. The most dangerous thing is just a little bit of knowledge.


:lol:

a simple "I'm not sure, man" woulda been fine. no need to get so testy bmc. chiiiiiiiiiiiiiiill. imo. :kiss:

[mrbmc]

Hey Bob. Your TV is causing interference with my mobile phone, and now i can't call my crack dealer. Just wanted to let you know that mmmkay?



:lol:

a simple "I'm not sure, man" woulda been fine. no need to get so testy bmc. chiiiiiiiiiiiiiiill. imo. :kiss:

[Uncle Bobby]

Hey Bob. Your TV is causing interference with my mobile phone, and now i can't call my crack dealer. Just wanted to let you know that mmmkay?


oh okay. I shut if off. you should be good to go now. sorry bout that. :)

[347]

Hey Bob. Your TV is causing interference with my mobile phone, and now i can't call my crack dealer. Just wanted to let you know that mmmkay?


i'll get some crack for you. how many rocks do you need?

[TM]

i'll send the firewall-log later on tonight over...

[ichi_gami]

i thought you'd enjoy getting a pounding in your firewall with MySQL. http://www.anotherdamnboard.com/forum/html/emoticons/noexpression.gif

[TM]

i thought you'd enjoy getting a pounding in your firewall with MySQL. http://www.anotherdamnboard.com/forum/html/emoticons/noexpression.gif


what are you doing thursday night? ;)

[ichi_gami]

what are you doing thursday night? ;)

fire department meeting, sorry.

i can pencil you in for the second tuesday of next week, how's that for you?

[TM]

copy of the log:

2004/04/26 15:55:29 I tcp 216.133.72.37 reserved.linuxwebnet.com 80 24.239.142.192 2148
2004/04/26 15:54:33 I tcp 24.201.61.223 1908 24.239.142.192 1025
2004/04/26 15:54:33 I tcp 24.201.61.223 1910 24.239.142.192 3127
2004/04/26 15:54:33 I tcp 24.201.61.223 1911 24.239.142.192 6129
2004/04/26 15:54:33 I tcp 24.201.61.223 1913 24.239.142.192 80
2004/04/26 15:54:33 I tcp 24.201.61.223 1904 24.239.142.192 2745
2004/04/26 15:54:27 I tcp 24.201.61.223 1911 24.239.142.192 6129
2004/04/26 15:54:27 I tcp 24.201.61.223 1910 24.239.142.192 3127
2004/04/26 15:54:27 I tcp 24.201.61.223 1908 24.239.142.192 1025
2004/04/26 15:54:27 I tcp 24.201.61.223 1904 24.239.142.192 2745
2004/04/26 15:54:25 I tcp 216.133.72.37 reserved.linuxwebnet.com 80 24.239.142.192 2148
2004/04/26 15:54:24 I tcp 24.201.61.223 1913 24.239.142.192 80
2004/04/26 15:54:24 I tcp 24.201.61.223 1911 24.239.142.192 6129
2004/04/26 15:54:24 I tcp 24.201.61.223 1910 24.239.142.192 3127
2004/04/26 15:54:24 I tcp 24.201.61.223 1908 24.239.142.192 1025
2004/04/26 15:54:24 I tcp 24.201.61.223 1904 24.239.142.192 2745
2004/04/26 15:53:21 I tcp 216.133.72.37 reserved.linuxwebnet.com 80 24.239.142.192 2148
2004/04/26 15:51:02 O tcp 216.133.72.37 www.rhythmism.com 80 192.168.1.107 2227

[mrbmc]

You have 4 transactions from this server, which i've highlighted for you. They're approximately 1 minute apart each, and they're on your http port (80), and they're 2K each, which is a pretty negligible packet size. That's hardly pounding.

How do you make the connection between that data and blaming MySQL on this server for a problem? i don't see the connection. Seriously, if there's an issue i'd like to narrow it down and resolve it.


copy of the log:
<span style="background:#FFC;">
2004/04/26 15:55:29 I tcp 216.133.72.37 reserved.linuxwebnet.com 80 24.239.142.192 2148 </span>
2004/04/26 15:54:33 I tcp 24.201.61.223 1908 24.239.142.192 1025
2004/04/26 15:54:33 I tcp 24.201.61.223 1910 24.239.142.192 3127
2004/04/26 15:54:33 I tcp 24.201.61.223 1911 24.239.142.192 6129
2004/04/26 15:54:33 I tcp 24.201.61.223 1913 24.239.142.192 80
2004/04/26 15:54:33 I tcp 24.201.61.223 1904 24.239.142.192 2745
2004/04/26 15:54:27 I tcp 24.201.61.223 1911 24.239.142.192 6129
2004/04/26 15:54:27 I tcp 24.201.61.223 1910 24.239.142.192 3127
2004/04/26 15:54:27 I tcp 24.201.61.223 1908 24.239.142.192 1025
2004/04/26 15:54:27 I tcp 24.201.61.223 1904 24.239.142.192 2745 <span style="background:#FFC;">
2004/04/26 15:54:25 I tcp 216.133.72.37 reserved.linuxwebnet.com 80 24.239.142.192 2148 </span>
2004/04/26 15:54:24 I tcp 24.201.61.223 1913 24.239.142.192 80
2004/04/26 15:54:24 I tcp 24.201.61.223 1911 24.239.142.192 6129
2004/04/26 15:54:24 I tcp 24.201.61.223 1910 24.239.142.192 3127
2004/04/26 15:54:24 I tcp 24.201.61.223 1908 24.239.142.192 1025
2004/04/26 15:54:24 I tcp 24.201.61.223 1904 24.239.142.192 2745<span style="background:#FFC;">
2004/04/26 15:53:21 I tcp 216.133.72.37 reserved.linuxwebnet.com 80 24.239.142.192 2148
2004/04/26 15:51:02 O tcp 216.133.72.37 www.rhythmism.com 80 192.168.1.107 2227</span>




p.t. HEY DON! I need a garbage bag of gear for my sawed off sparkplug pipe. can you hook a brother up?

[TM]

bri, I wish I could offer more information, but I really can't...
I'm only going by what my firewall said when it locked out the site... it said something to the effect that "Blocked: 216.133.72.37, MYSQL intrusion" I can't really offer any more info other then I was checking bob's picture thread at the time... If you want more of the log, or something just let me know...

[Sprocket]

You have 4 transactions from this server, which i've highlighted for you. They're approximately 1 minute apart each, and they're on your http port (80), and they're 2K each, which is a pretty negligible packet size. That's hardly pounding.

is there something weird on the board software that backchecks the source address port 80?

[Tally]

I've been watching this thread and would be interested to know the answer.... i am just learning PHP and SQL... so it's a "trial and error" thing for me.

Always interested in learning anything new.... even if it is just a firewall error, may help me in troubleshooting down the line.

=)

[mrbmc]

nope.
is there something weird on the board software that backchecks the source address port 80?

Ok ok ok - i'll take a shot in the dark at what i think the problem is.

Short answer: My first guess would be that the problem is probably a funky attachment somebody posted in Bob's thread that your firewall didn't like.

long geeky answer
vBulletin stores attachments as binary blob's in the DB. On retrieval, it returns the the data to PHP who then slaps the appropriate header on the output. It'd be logical for some image file to be garbled so PHP won't put on the file headers when it printed the attacment data and your firewall would pucker up tighter than a frog's ass as the undeclared data comes at it.

generally i'd say storing attachments as binary data in a DB is a really inneffecient way of managing images (considering unix file handling is 1000x faster). But the folks at vBulletin make a reasonably compelling case about blob's being more secure, so i left the default. Maybe this little issue is a good reason to move the attchments to local files. *shrug*





Then again i still haven't really looked into this problem, so i'm pretty much just pulling all this out of my ass. Until somebody else reports a similar problem, there's no way to know where to start narrowing down the problem.

[rod]

nope.
long geeky answer
vBulletin stores attachments as binary blob's in the DB. On retrieval, it returns the the data to PHP who then slaps the appropriate header on the output. It'd be logical for some image file to be garbled so PHP won't put on the file headers when it printed the attacment data and your firewall would pucker up tighter than a frog's ass as the undeclared data comes at it.




something tells me you like the long geeky answers

[cane]

feedback is the best forum in the house
:lol:
:smoke:

[Sprocket]

generally i'd say storing attachments as binary data in a DB is a really inneffecient way of managing images (considering unix file handling is 1000x faster). But the folks at vBulletin make a reasonably compelling case about blob's being more secure, so i left the default. Maybe this little issue is a good reason to move the attchments to local files. *shrug*

architecture wise, we had this argument many times at Princeton on the "Digital Document Archive" project I helped design. BLOB's are aweful in the database, chew up and fragment your tablespace, can allocate a huge abount of transient db server memory generating tons of paging, if your db access is over tcp, even loopback, fires off so much tcp stack code for no good reason, 2 read loops, 2 write loops minumum. Filesystem will be 1000x faster. Right code, can be moved from disk to tcp by the kernel. Linux, khttpd never even gets to user-space to serve static content. Secure? if the box is 0wn3d, the'll get in the db. Secure? from whom? what is the value of the content you are protecting? can that value be stolen?

upside on the db: single backup, clustering and fail-over. needed? we didn't. RAID, ext3fs, and replication to an off-site disk on a low thread priority queue on a second eth interface was fast and safe.

[mrbmc]

it's subterfuge.

it's not so much that i enjoy the geeky answers themselves, so much as i like the effect it has of placating irrate people - or at least confusing them long enough to shut the hell up.

something tells me you like the long geeky answers

[san]

it's subterfuge.

it's not so much that i enjoy the geeky answers themselves, so much as i like the effect it has of placating irrate people - or at least confusing them long enough to shut the hell up.

b, can you teach me all this stuff so i can get a job somewhere?