New SQL worm? getting multiple, continuous connections from random IP's for last 4 days

Our bandwidth usage tripled since this started happening. We get
about 1 new attack daily. To stop the attacks we either block the IPs
on the router or email the ISP to get the guy off the network. This
is happening to every SQL server on the network. Seems to be scanning
for open port 1433.
Example;
TCP 229.133.145.237:1433 65.203.118.170:36950 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:36975 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37028 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37058 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37101 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37112 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37182 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37204 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37255 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37282 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37326 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37357 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37409 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37438 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37484 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37519 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37567 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37579 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37640 TIME_WAIT
TCP 229.131.145.234:1433 65.203.118.170:37649 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37723 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37744 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37804 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37815 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37890 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37901 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37963 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:37971 TIME_WAIT
TCP 229.133.145.237:1433 65.203.118.170:38045 TIME_WAIT
TIA!It seems that you scan them... Please post more details
Bojidar Alexandrov

New SQL Replication implementation

Hello,

I'm just beginning my R&D on SQL Server Replication for a project and had some questions about what paths to pursue

We have multiple locations which we want to all work off the same set of data essentially, but the kicker is that many of the sites become disconnected for minutes or either days at a time due to their remote locations, so we cannot simply deploy a web application with one SQL backend because remote sites will be unable to work during service disruptions.

Ideally, what I'd like to be able to do is have multiple instances of the SQL server/web applications(one at each site..they all have their own internal network), but which replicates with the main site/all other sites whenever it can(i.e. the internet is available). So one site goes without internet for a few days, they have up to date data from the last replication and they can work off their own sql server/web application, and any updates they've made/or any updates from other sites they've missed during the disconnected period would be replicated when the opportunity arises(ie. the web connectivity comes back)

Is this scenario possible? and I am struggling to find the right strategy path for implementing something like this. Any guidance would be greatly appreciated.

Thanks,

Chris

Yes this is possible. What you want is Merge replication. That will allow updates on the subscribers and they will sync when they are online.

I would recommend making the client a click once .net application rather than a web app as the click once will also update when online however web app will work too on the local servers. You will just need a mechanism to update the pages.

Martin

sql

New SQL Replication implementation

Hello,

I'm just beginning my R&D on SQL Server Replication for a project and had some questions about what paths to pursue

We have multiple locations which we want to all work off the same set of data essentially, but the kicker is that many of the sites become disconnected for minutes or either days at a time due to their remote locations, so we cannot simply deploy a web application with one SQL backend because remote sites will be unable to work during service disruptions.

Ideally, what I'd like to be able to do is have multiple instances of the SQL server/web applications(one at each site..they all have their own internal network), but which replicates with the main site/all other sites whenever it can(i.e. the internet is available). So one site goes without internet for a few days, they have up to date data from the last replication and they can work off their own sql server/web application, and any updates they've made/or any updates from other sites they've missed during the disconnected period would be replicated when the opportunity arises(ie. the web connectivity comes back)

Is this scenario possible? and I am struggling to find the right strategy path for implementing something like this. Any guidance would be greatly appreciated.

Thanks,

Chris

Yes this is possible. What you want is Merge replication. That will allow updates on the subscribers and they will sync when they are online.

I would recommend making the client a click once .net application rather than a web app as the click once will also update when online however web app will work too on the local servers. You will just need a mechanism to update the pages.

Martin

new records aren't being added to ft catalog (sql 2005 ee)

Hi all,
I have multiple full-text catalogs on about 8 tables (sql server 2005 ee -
all varchar(max)).
A few days ago, they all went to an idle status and won't start picking up
any new changes - all catalogs are auto update.
when i say 'idle' - mean :
objectpropertyex ( [table object_id] , 'TableFulltextPopulateStatus' ) = 0
objectpropertyex ( [catalog_id] , PopulateStatus) = 0
and
objectpropertyex ( table object_id , 'TableFulltextItemCount' ) shows that
there are many rows missing from the table so there is much work to be done.
i have seen this once before and ended up doing a rebuild but I hope to
avoid that this time around as it takes several days to rebuild all catalogs.
Has anyone seen anything similar to this or have any suggestions for the
full-text catalog to start 'picking back up' the auto changes?
Many thanks,
Robert Towne
check the full text logs, they can be found in C:\Program Files\Microsoft
SQL Server\MSSQL.1\MSSQL\LOG and will look like SQLFT0005600015.log
http://www.zetainteractive.com - Shift Happens!
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"sql411@.nospam.com" <sql411nospamcom@.discussions.microsoft.com> wrote in
message news:D77BD52A-7107-4284-8522-60E95C45E15E@.microsoft.com...
> Hi all,
> I have multiple full-text catalogs on about 8 tables (sql server 2005 ee -
> all varchar(max)).
> A few days ago, they all went to an idle status and won't start picking up
> any new changes - all catalogs are auto update.
> when i say 'idle' - mean :
> objectpropertyex ( [table object_id] , 'TableFulltextPopulateStatus' ) = 0
> objectpropertyex ( [catalog_id] , PopulateStatus) = 0
> and
> objectpropertyex ( table object_id , 'TableFulltextItemCount' ) shows that
> there are many rows missing from the table so there is much work to be
> done.
> i have seen this once before and ended up doing a rebuild but I hope to
> avoid that this time around as it takes several days to rebuild all
> catalogs.
> Has anyone seen anything similar to this or have any suggestions for the
> full-text catalog to start 'picking back up' the auto changes?
> Many thanks,
> Robert Towne
|||Thanks, Hilary. I checked the logs initially and only saw a pause (from
backup) and resume (backup finished). it was weird because it happened
across all full-text catalogs - i could still do a contains search but they
just were idle as far as adding new records.
I did a reboot and that cleared it up. (I was hoping to avoid the reboot as
we are always doing business and it is difficult to get a maintenance period).
Thanks again,
robert