CapnPugwash
Members-
Posts
334 -
Joined
-
Last visited
Content Type
Forums
News
20th
EduGeek EDIT Conference
Blogs
Everything posted by CapnPugwash
-
Ubuntu 12.04 LTS , GeoIP, IPTables & UFW
CapnPugwash replied to CapnPugwash's topic in Internet Related/Filtering/Firewall
Hi folks - thanks for the tips. I've actually got the iptables rules working fine. I'm blocking a number of countries and it's definitely made managing the server easier. Obviously IP blocking isn't the solution but it does give me a bit of breathing space. I've inherited an old Joomla website (LOTS of extensions) - holes aplenty. Now I've got things under control I can start planning migrating the site over to the latest Joomla (with as few extensions as possible!) -
Hi, I'm running Ubuntu 12.04 as a webserver. I'm trying to restrict access to a folder by adding a rule to httpd.conf The only users I want to be able to access this folder are on the local LAN, where all IP addresses begin with 123.456 Order Allow,Deny Allow from 123.456 From what I understand, access should be denied by default & only IP addresses that start with '123.456' should be allowed This isn't working. The rule blocks everything. if I change the Allow rule to a full IP address it's still the same... I'm all ears for ideas!!
-
Ubuntu 12.04 LTS , GeoIP, IPTables & UFW
CapnPugwash replied to CapnPugwash's topic in Internet Related/Filtering/Firewall
Ah... well after some digging it seemed that having rules in iptables and UFW was causing a conflict, so I disabled UFW, flushed the iptables rules and started again. Blocking traffic from everywhere but the UK slowed my webserver to a crawl so now I'm just blocking countries were I'm getting a high volume of suspect traffic. Seems OK now. -
Hi, My Ubuntu webserver is getting lots of unwanted attention. I enabled UFW and started blocking individual IP addresses, this was OK for a while but soon became a chore & wasn't really working. Looking for something better, I installed the xtables-addons / GeoIP databases. It all installed fine. To block all traffic from outside of the UK (I know this seems extreme but it's where I want to start) I ran this command: iptables -A INPUT -m geoip ! --src-cc GB -j DROP Running iptables -L , it definitely looks like the rules are being applied but I'm not 100% sure. Looking at my Apache logs it looks like I'm still getting traffic from Iran/China/Russia etc. Is there anyway to test this? (I thought about asking my boss to fly somewhere but I don't think he'd be agreeable) - I haven't touched UFW, could it's rules conflict with the iptables rules? I'd be grateful for any pointers...
-
Quick update for anyone watching... On one of the client machines that wouldn't connect to the network, I set a static IP - was able to join the domain without any issues!!! It looks like the problem is DHCP. This is a legacy network, not one I built. The paperwork left me by the previous fella says DHCP should be running on another server separate to the DC's... and it isn't. The DHCP service is disabled and it looks like DHCP is dead on the machine... Oh well, at least I think I'm getting somewhere!
-
Oh... the network clients are all physical boxes
-
Not sure if this is the right place for this but here goes... I have a number of (VMWare) virtual servers (including a DC) and a physical DC. Both DC's are Windows server 2008 R2. Last night there was a power outage in our area. Our UPS boxes kicked in and everything shut down gracefully. The VMWare HA shuffled all the VM's over onto one host but I restarted the machines and put them back as they were. After the restart some machines (400 machines, mainly Windows 7 but some XP) either couldn't connect to the network OR connected but couldn't see a variety of network resources. Restarting the machines had no effect. If I take a machine off the network and try to rejoin it I get this error: "an attempt to resolve the dns name of the domain controller in the domain being joined has failed. Please verify this client is configured to reach a DNS server that can resolve DNS names in the target domain" I have restarted both DC's (these are also the DNS servers) I can ping both DC's by IP address and name I can run nslookup up on both DC's and find the correct IP's and names for machines on the network (including ones that can't connect to the domain) If I ren repadmin /showreps on both machines it shows succesful replications I can open AD on one DC and create / delete a user and the changes are replicated I'm really stuck now, any ideas?
-
Veeam : VSS Error 8194 on server
CapnPugwash replied to CapnPugwash's topic in Thin Client and Virtual Machines
Yep - "You can get this granted by launching dcomcnfg.exe, browsing to to Component Services, Computers, and right clicking on your Computer. Get to the COM security tab, and grant Network Service" resolved the issue Cheers! -
Veeam : VSS Error 8194 on server
CapnPugwash replied to CapnPugwash's topic in Thin Client and Virtual Machines
Thanks for that - I doubt I'll get chance to try it out until Early next week but once I do I'll post back & let you know whether it resolved the issue -
Veeam : VSS Error 8194 on server
CapnPugwash replied to CapnPugwash's topic in Thin Client and Virtual Machines
Hi, The server is a DC / DNS server. It runs the management services for our MFD's / printers (which are not in use at night) and also hosts some shared files. No we never renewed the service contract (or with VMware either). We are a school and the attitude to spending money is quite often "let's wait until everything has fallen to bits"! -
Veeam : VSS Error 8194 on server
CapnPugwash replied to CapnPugwash's topic in Thin Client and Virtual Machines
No we use Symantec -
Veeam : VSS Error 8194 on server
CapnPugwash replied to CapnPugwash's topic in Thin Client and Virtual Machines
Hi, Thanks for the speedy reply! On Veeam, in the job properties, it's set to run under the network admin account - the credentials must be correct otherwise I'd see the VSS error on other servers? -
Not sure if this should be posted here or in the Server 2008 section... I use Veeam 5.0 to back up my VMware virtual machines. In the events logs of one of my Windows 2008 servers I regularly see this error: ID 8194 Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. . This is often caused by incorrect security settings in either the writer or requestor process. The roor occurs twice during the Veeam backup session - once near the start & once near the end. The backup completes successfully. Opening a CMD prompt and running 'vssadmin list writers' returns a list of vss writers with no errors... I don't see this error on other servers...
-
Active Directory Certificate Services / CA
CapnPugwash replied to CapnPugwash's topic in Windows Server 2008 R2
I managed to resolve this myself. I set up ADCS & CA on a test server. Once set up I ran MMC and added the Certificates snap in for the computer account. I deleted the Root Cert from Personal/Certificates & restarted the machine - it recreated the root cert. I tried this on the problem server and it didn't work as ADCS service still wouldn't start, so I went to Server Manager and removed the ADSC role, restarted the machine and then re-added the role. Restarted. Everything fixed! Luckily my servers are virtual so it was easy to make a snapshot in case things went awry... -
I have a Windows server 2008 Domain Controller that is running Active Directory Certificate Services. I have two certificates that I can view by loading the Certificates Snap in. The templates they point to are 'domain controller' & 'Root template' The certificates expired last month. They are self cert so I cannot renew them. Active Directory Certificate Services will no longer start (throwing errors 100 & 42) - I presume these things are related. How can I rebuild these certs and get Active Directory Certificate Services working again? Obviously I don't expect anyone to have a magic wand but if someone could point me in the right direction that would be much appreciated! **Note** The main use of the certs is to enable a separate TS server to authenticate user log-ons
-
Moodle 2.4 & Windows Share Web Client
CapnPugwash replied to CapnPugwash's topic in Virtual Learning Platforms
Weird, I thought I'd updated this ages ago... Yes the problem was SSL - as it's a test site (only available on our local network) and at the moment only a handful of people have access to it, I haven't installed an SSL cert. From my original post : "I've got the 'Windows Share Web Client' block on my front page and it looks nice but when I click on a link to a Windows share it opens a blank web page (Internet Explorer cannot display the webpage)" The url points to a https page, changing it to http and reloading = success! Obviously I will install the SSL cert before the site goes live. -
Moodle 2.4 & Windows Share Web Client
CapnPugwash replied to CapnPugwash's topic in Virtual Learning Platforms
Here's some more info. The Ubuntu server isn't 'live' - it's on our local network & only a few people can access it for testing purposes. The Ubuntu Server has a static IP address. Moodle sits in the var/www/moodle folder. We have domain names / public IP addresses/ SSL certs in hand, we just want to be sure that everything is working correctly before we make it available to our users. We access Moodle from Windows machines by opening a browser and typing /moodle As said previously, clicking on a directory link in the 'Windows Network Share Block' pulls up a blank web page (Internet Explorer cannot display the webpage) If I try this in FireFox I get a blank page with the message 'Unable to Connect - FireFox cannot establish a connection to server . Is the extra '.' on the end of the IP address significant? Ive checked the 'Windows Network Share Block' settings and it appears to be pointing to the correct location of the Samba smbclient... -
Hi, I have a fresh build of Moodle 2.4 running on Ubuntu 12.04.1 LTS On ubuntu I've installed the Samba SMB Client, I can test this by opening a terminal and typing smbclient \\\\SERVER-NAME\\HOMEDIR$ -U USER I can access the directory and use 'get' & 'put' etc On Moodle I've enstalled the latest 'LDAP Capture Authentication Plug-in' , changed the DB to use this method for authentication, works fine. I've also installed the 'Windows Share Web Client' so that users can access Windows shares via Moodle. I've entered the locations of my file servers into the moodle config page & checked I can ping the addresses from within Ubuntu. I've got the 'Windows Share Web Client' block on my front page and it looks nice but when I click on a link to a Windows share it opens a blank web page (Internet Explorer cannot display the webpage) I've had a look at the web hoping to find some info but I haven't found much - can anyone suggest anything? Any logs I could look at to try and pin it down etc.
-
Hi All, Anyone using Moodle 2 in Staffordshire? We are looking at upgrading from 1.9 & would like to visit Schools who are using 2 in anger. (We are a large secondary)
-
We've still got the same issue. We've talked to Pearson support, they've sent an engineer out and they have also taken one of a machines (A Dell 380) away for testing - they couldn't replicate the error. I think it is the 'sound enhancements' problem and user profiles. Our staff profile is tied down and they cannot access the 'sound enhancements' controls. We turn off 'Sound enhancements' when we are building a clean machine but I don't believe the setting propagates to all users.
-
yes. I'll be doing that today. After a week of battling with this it's looking a bit grim - I just can't find the backdoor! It looks like I'm going to have to rebuild the server which is a major pain because (a) I don't really know that much about Ubuntu / Joomla / Moodle / Apache and (b) I will copy to take the content (moodledata & website) off the infected server WITHOUT copying over the infection. Great. I'll enjoy it on one level because it is interesting but... this isn't the kind of situation where you can tinker away and enjoy it - I need to resolve it ASAP.
-
OK, well, as predicted I'n ot out of the woods. Here's where I am Looking in my Apache logs I can see that the file .cache_sjouns123.php was posted into /images/banners (which sits in my web directory) this file and another file in the same location - .cache_yf7ihj123.php originate from the IP address 46.183.218.163 - it is these files that are generating the dodgy .htaccess files. The .htaccess end up being in the root of EVERY folder in my web directory. I can delete all the .htaccess files and the two .php files and everything seems to me ok for a couple of hours, then it all starts again. There is obviously a backdoor somewhere... I've been looking at a website that suggests running the grep command and looking for any of these words: passthru shell_exec system phpinfo base64_decode edoced_46esab (base64_decode used backwards to avoid detection by string searches like this) chmod mkdir `` (backticks with an operating system command between them) fopen fclose readfile And the checking the files and using my judgement on whether to remove. The .htaccess files are owned by the www-data user, a poster on this forum suggested using chmod on the web folders, restricting the www-data user so that they couldn't write to / create .htaccess files ... that's definately something I'm going to be looking into.
-
There ended up being a LOT of .htaccess files & a couple of dodgy PHP files. I've cleaned up and made sure Ubuntu / Apache is fully up to date with patches etc. The .htaccess files were being written by the www-data user, so that's something I need to look at. I don't think I'm out of the woods yet but it's looking a lot better than it did on Monday. As I said before, the Ubuntu / web server was put together by someone else and they left a while a go. Having to dig into it has been an experience. Not an unpleasant one but sometimes finding a 'definative' answer regarding command line stuff has been a bit frustrating. If anyone comes to this thread with the same problem, I'm happy to talk you though my mistakes!
-
AH... I'm starting to get a grip of this now. The problem was/is partly .htaccess files. The reason I wasn't finding anything nasty in them is because I was looking in the wrong place! I've been looking at htaccess files and NOT .htaccess files. I didn't realise that the '.' signifies the '.htaccess' file is hidden. Once I had this error pointed out to me, and started looking properly using 'ls -a' from the command prompt I found the dodgy .htaccess files straight away and deleted them. So I'm starting to chip away at this but I've got another problem. The .htaccess files I have deleted keep coming back! I'm fairly sure they are being regenerated by one or more PHP files. I've found two likely candidates, both of them have 1969 as the last modified date!
-
The 'sudo' bit is the only bit I know!
