Difference between revisions of "Firewall"
|Line 55:||Line 55:|
Revision as of 23:56, 10 July 2007
Here be dragons
Summary: Don't change the firewall configuation. It's not for changing.
In all seriousness, the firewall is pretty much the only bit of Tardis that absolutely has to be in good working order, for the sake of the project. If you feel the need to make changes, discuss it with everyone, especially the people who understand the ramifications (particularly in regards to the relationship the project has with the powers that be (ie, Informatics)).
However, if you were (theoretically) going to change it, the instructions would look roughly as follows...
Changing the Tardis Firewall
co -l tardis-firewall
The tardis-firewall script is quite complex so take a good look over it first, it is fairly well documented. Try to make your edits in an appropriate place.
When you're done, you can deploy your changes by running:
A bunch of stuff will scroll past, ending in something similar to:
+ echo 'Setting up fail-safe mechanism. Use '\''atrm <job id>'\'' to stop it.' Setting up fail-safe mechanism. Use 'atrm <job id>' to stop it. + at now + 2 minutes warning: commands will be executed using /bin/sh job 321 at 2006-08-20 12:48 davison:~#
Pay close attention to the last two lines! The tardis-firewall script has a failsafe mechanism. You have two minutes to test that your new configuration is sane. At the very least you should test that:
- You can ssh into davison from the outside world..
- You can ssh into gallifrey from the outside world.
If you're satisfied that you haven't broken anything, do:
atrm <job given from script (eg 321 from the above example)>
to disable the failsafe.
If you fail to atrm the job in time, the firewall ruleset will be flushed, and routing will be disabled. You will have to log into davison externally, fix the firewall script, and re-run it.
If you're satisfied your edits do what you want, you can commit(unlock) the changes in RCS with
ci -u tardis-firewall
Tardis's firewall is reasonably restrictive on outbound connections. Some of the restricted services are as follows:
Outbound ssh access was previously disallowed. This was presumably for security reasons, although the original rationale is not exactly known. Certainly there was some justification in the arguement that, if you can ssh to tardis, you can ssh to other hosts directly. This restriction was found to occasionally be irritating, and there were genuine use cases for allowing outbound ssh (svn+ssh being a good example). The current tardis admins decided at a meeting to remove the restriction.
All http requests should go via the university's proxy servers. This is as much to enforce common sense. It may also have been the case that previously the university had this as an official requirement. At one point of time, the university was being billed separately for intercontinental traffic, and made some explicit policies relating to http cache usage.
IRC access from tardis is still currently forbidden. IRC clients can attract DDoS attacks against their source IP, and informatics did at one point ban outbound IRC from their networks (this may still be in force). This was following a number of notorious incidents.
- Be careful!