Jeff:
Here are some tips that I think would be easier:
1. the ssh daemon configuration
First of all, whenever I install linux, one of the first things I do is
configure ssh to NOT allow root logins. It's not necessary for us to
ssh in as root anyway! You ssh in as a normal user, and then do 'su' to
become root.
So, to do this, edit the file /etc/ssh/sshd_config
Find this line:
# PermitRootLogin yes
Note that it will probably be commented out, and the default setting is
'yes'. So UN-comment that line (remove the #) and change the yes to no.
Save the file and then reboot or restart the ssh daemon with:
service sshd restart
After doing this, any attempts to ssh into the machine as root will be
immediately rejected.
2. tcp_wrappers configuration
The program tcp_wrappers is what sets up the files /etc/hosts.deny and
/etc/hosts.allow. Instead of constantly updating hosts.deny, what I
would recommend is this: Set hosts.deny to deny everthing; then set up
hosts.allow to allow only the domains you want. So in hosts.deny, you
put only this line:
ALL: ALL
In hosts.allow, you would have a line something like this:
ALL: 127.0.0.1, 149.236., .mit.edu
The first two entries are necessary for the Bruker console interaction
to work properly. The last would include the specific domains from
where you need to get to this machine.
3. (optional) Add a hardware router/firewall
On a couple of our NMR computers (one Solaris, one linux), I recently
purchased inexpensive Linksys routers (not a wireless router, just a
plain 4-port router: about $50). The router is plugged into the
internet wall port. The nmr computer is plugged into one of the four
ports of the router. I configured the routers like this:
I configure the router statically with the IP number, etc. of the nmr
computer. So when you try to communicate with the NMR computer, you are
actually initially "talking" to the router. Go to the Advanced section
of the router configuration and look for the "Port Forwarding" section.
Make sure all ports are disabled in the menu, but add one for SSH on
port 22. Send the port 22 activity to local IP: 192.168.1.2 (or
whatever you choose to use). You then need to reconfigure the network
on the nmr computer to use that local IP number. For example:
IP Address: 192.168.1.2
Net Mask: 255.255.255.0
Gateway: 192.168.1.1 (for linksys, anyway)
Keep your normal campus DNS entries.
This works beautifully! I ran the 'nmap' port-mapping utility from
another computer before and after setting this up, and it makes a huge
difference. Before setting it up, nmap reports a page full of open
ports. After the router setup, it only sees port 22.
The above is a rather cursory explanation of how this is done. Anyone
is welcome to email me if you have questions.
For non-nmr linux machines I normally just use the built-in iptables
firewall software, but sometimes you run into trouble with this in a
typical nmr setup. I had iptables working at one time with our Avance
system, but at some point we disabled it when we were troubleshooting
some problem. The hardware router solution eliminates that problem, and
the potential controversy with the Bruker people! ;-)
Cheers.
Jeff Simpson wrote:
> AMMRLers,
>
>
>
> If you have a Linux box on the net, this may be of interest to you.
>
>
>
> Having recently put a new Linux box online whose IP address is
> well-publicized, I thought it would be good to check the system file
> that logs hacker break-in attempts (at least some of them, anyways).
> Sure enough, /var/log/secure and its older editions (/var/log/secure.#
> where # s 1, 2, or 3) showed 14 machines had attacked using ssh in three
> weeks 19,946 times (!). Of those 19,946 separate attacks, many were
> targeted at the root account.
>
>
>
> To see if you have been getting attacked lately, open a terminal window
> on your Linux box, become the superuser and type:
>
>
>
> grep "Failed password for root" /var/log/secure* | more
>
>
>
> If your screen fills up with text, then you have been attacked on your
> root account (type q to end the output stream, space bar to view a
> screen at a time, or return to view line by line). You can also just
> search for “Failed password” and for “sftp” (using grep to find the
> incidences of sftp won’t tell you if those requests are ok or not) by
> substituting those search strings for “Failed password for root” in the
> example above.
>
>
>
> One way to minimize the vulnerability of a Linux box to attacks is to
> add offending IP addresses to /etc/hosts.deny, which, as the name
> implies, serves as a list of machines that are to be denied one or more
> services your Linux box may perform, like letting a hacker change around
> your operating system (generally considered a bad thing). I have
> written a piece of code that sifts through /var/log/secure[.?] files
> once an hour, adding offending IP addresses to /etc/hosts.deny in the
> following format:
>
>
>
> ALL:218.1.65.233 # nfail= 72 nrfail= 24 added Fri Dec 8 15:27:00
> 2006
>
> ALL:89.106.23.22 # nfail= 36 nrfail= 12 added Fri Dec 8 15:27:00
> 2006
>
> ALL:212.189.144.213 # nfail= 18 nrfail= 6 added Fri Dec 8 15:27:00
> 2006
>
> ALL:219.146.59.225 # nfail= 32 nrfail= 10 added Fri Dec 8 15:27:00
> 2006
>
> ALL:211.189.50.94 # nfail= 18 nrfail= 6 added Fri Dec 8 15:27:00
> 2006
>
> ALL:211.94.190.138 # nfail= 18 nrfail= 6 added Tue Dec 12 11:00:02
> 2006
>
> ALL:87.106.4.143 # nfail= 56 nrfail= 30 added Tue Dec 12 15:00:02
> 2006
>
> ALL:218.145.53.18 # nfail= 18 nrfail= 6 added Mon Dec 18 05:00:02
> 2006
>
> ALL:69.81.176.233 # nfail= 214 nrfail= 118 added Tue Dec 19 22:00:01
> 2006
>
>
>
> This is actual stuff from my /etc/hosts.deny file. To explain what it
> is, the “ALL” denotes deny all services, the colon (:) is a field
> separator, and then the IP address is listed. The pound sign (#)
> denotes the rest of the line is a comment, and the number of ssh
> failures is listed, then the number of failures to login to the root
> account. As you can see, a new entry was added at 10pm last night.
>
>
>
> As an aside, if somebody local is just bad at remembering their password
> and accidentally gets added, you can comment out their IP address in the
> /etc/hosts.deny file and it will not get added once it appears in there,
> even though it is commented out, e.g.
>
>
>
> #ALL: 18.60.0.1
>
>
>
> When I first got started on this little project, I tracked down some of
> the IP addresses by typing them into the following website:
>
>
>
> http://visualroute.visualware.com/
>
>
>
> The most recent attack traces to Atlanta, Georgia, USA. The IP tracer
> above is free to use (I had to load a plug-in to use it the first time),
> but it counts how many IPs you trace per unit time and stops working
> after a few traces, unless you delete your browser cookie (on MS-XP
> using Internet Explorer, click [tools] [internet options] [delete
> cookies] [ok]), then you can just keep going and going and going like
> the Energizer bunny.
>
>
>
> I was amazed to see where the logins attempts where coming from: France,
> Turkey, Spain, China, South Korea, Italy, and states a thousand miles
> away from Massachusetts whose computer users have no business on my machine.
>
>
>
> I can publish this code along with basic instructions on setting it to
> run as a cron job, if there is sufficient interest. If you want this
> information, send me an email and specify if you need a cron tutorial
> (try “man cron” first).
>
>
>
> Jeff
>
>
>
> Jeff Simpson, Director
>
> Department of Chemistry Instrumentation Facility
>
> Massachusetts Institute of Technology
>
> 77 Massachusetts Avenue, 18-0090
>
> Cambridge, MA, 02139
>
> 617-253-2016 (1806 lab)
>
>
>
--
-Bill-
---------------------------------
Bill Gurley, Technical Director
Department of Chemistry
Univ. of Tennessee, Knoxville
Received on Wed Dec 20 2006 - 23:56:39 MST