Fastwall: A Shorewall within 2 Minutes
Dynamic approach :
Mode of operation :
[mx1:root]:(~)# cat /etc/shorewall/rules.drakx ACCEPT net fw udp 53,110,1194 - ACCEPT net fw tcp 80,443,53,22,20,21,25,109,110,143,110 - [mail:root]:(~)#
Make sure that inside fastwall-on.sh (or fastwall) the values for IPTABLES, RULES and LOCALNET are adjusted to your own network setup, and ..
Check fastwall from the Internet :
[mx2:root]:(~)# nmap -v -sT -O mx1.foobar.org Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2008-07-16 20:25 CEST Host xdsl-64-238-254-71.dslprovider.net (126.96.36.199) appears to be up ... good. Initiating Connect() Scan against xdsl-64-238-254-71.dslprovider.net (188.8.131.52) a t 20:25 Adding open port 110/tcp Adding open port 8080/tcp Adding open port 443/tcp Adding open port 53/tcp Adding open port 21/tcp Adding open port 22/tcp Adding open port 80/tcp Adding open port 25/tcp The Connect() Scan took 7 seconds to scan 1660 ports. For OSScan assuming that port 21 is open and port 1 is closed and neither are fi rewalled For OSScan assuming that port 21 is open and port 1 is closed and neither are fi rewalled For OSScan assuming that port 21 is open and port 1 is closed and neither are fi rewalled Interesting ports on xdsl-64-238-254-71.dslprovider.net (184.108.40.206): (The 1651 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 110/tcp open pop3 443/tcp open https 1720/tcp filtered H.323/Q.931 8080/tcp open http-proxy No exact OS matches for host (If you know what OS is running on it, see http://w ww.insecure.org/cgi-bin/nmap-submit.cgi). TCP/IP fingerprint: SInfo(V=3.55%P=x86_64-mandrake-linux-gnu%D=7/16%Time=487E3D38%O=21%C=1) TSeq(Class=TR%IPID=Z%TS=1000HZ) T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T2(Resp=N) T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW) T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=Y%DF=N%TOS=0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E) Uptime 3.235 days (since Sun Jul 13 14:47:21 2008) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) IPID Sequence Generation: All zeros Nmap run completed -- 1 IP address (1 host up) scanned in 24.146 seconds [mx2:root]:(~)#
All i needed was to fill-out my outward accessible UDP and TCP ports inside /etc/shorewall/rules.drakx, and even my openvpn tunnel was working out of the box. A thing which shorewall and many other firewall scripts simply cannot do, and certainly not within 2 minutes.
The R Zone: Hardening a Linux Server in 10 Minutes
Wed Mar 1 16:14:18 CET 2006 (as copied from : http://rudd-o.com/archives/2006/02/27/hardening-a-linux-server-in-10-minutes/ ) Did you know that a freshly installed Linux server can be hardened in less than 10 minutes? Heres how! Print these instructions out, and keep them posted on a wall in your office or home. Before plugging a freshly installed network server, simply remember to follow these instructions. Make these instructions second nature to you. Youll need a bit of experience with the Linux command-line environment, as the following commands are usually issued in a terminal. You will need root access on your server as well. By the way, the following instructions apply to any LSB-compliant Linux distribution, but Ill use Fedora Core as an example. Step 1: turn all unneeded services off There are two kinds of network services: those that get started as init.d services those that get started by xinetd This distinction is important, as xinetd can start services on demand, while services started through init.d run all the time. Okay, time to start securing your server. On a terminal, as root (and, for the purposes of this tutorial, assume this from now on) run netstat -ltunp. You should see a listing like this one: [root@andrea rudd-o]# netstat -ltunp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:3493 0.0.0.0:* LISTEN 30562/upsd tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 12461/mysqld tcp 0 0 0.0.0.0:6543 0.0.0.0:* LISTEN 12490/mythbackend tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1771/portmap tcp 0 0 0.0.0.0:6544 0.0.0.0:* LISTEN 12490/mythbackend tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 31537/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2143/sendmail: acce tcp 0 0 :::80 :::* LISTEN 5024/httpd tcp 0 0 :::22 :::* LISTEN 2009/sshd tcp 0 0 0.0.0.0:19 0.0.0.0:* LISTEN 2019/xinetd Those are all processes listening to specific ports. As you can see, the PID (process ID) and the program name are displayed as well. Make two lists: - one for the services you absolutely need (which you should already know by heart), and - one for the services that are expendable or you can start manually when theyre needed (tip: each program name usually ships with a man page). Shutdown each service on the second list (except for xinetd) Thats a pretty straightforward task. Each one of those services are started by init.d. To find out the name of the service control script, just hop to /etc/rc.d/init.d and look for a file with a name similar to the program name. Example: suppose I dont need mythbackend. To stop it: /etc/rc.d/init.d/mythbackend stop (some distributions provide the service mythbackend stop command, which is easier on your fingers). Now, to disable it: chkconfig --del mythbackend. After doing this, you should check to see if the offending service went away, with the same netstat -ltunp command. That pesky xinetd Great. So you got rid of the unneeded services. But theres more. As we saw earlier, xinetd has its own ways. In practice, this means that some services will be started on demand thus, you wont see them under your netstat -ltunp listing. To find out which services xinetd manages, hop to /etc/xinetd.d and do a directory listing. You should see some service configuration files. Identify the ones you wont be using, and edit each one of them, adding a line that says disable = yes between the curly braces. Note that some services already ship with disable = yes, but some ship with disable = no. If one of the configuration files says disable = no, just change it to disable = yes. Now reload xinetd with the famous /etc/rc.d/init.d/xinetd reload, and run netstat -ltunp again, just to be sure. Thats step 1. With a bit of practice, you should be doing this in five minutes or less. Step 2: limit access to running services using iptables Great, our server now runs the absolutely required services, and no more. But some of those services arent meant to be accessed from everywhere, right? For example: I may have a MySQL database server running, but that doesnt mean MySQL should be accessible from any random IP address on the Internet, right? So, well use the firewall to stop evil at the door. Again, make a list of services. For each item on the list, identify which IP addresses should be able to reach the service. For each service on your list, write down the TCP/UDP port(s) they use. In my example, MySQL uses TCP port 3306, and should only be accessible by localhost (127.0.0.1). Time to compose and activate the iptables rules. Doing a quick check with iptables -L, I can see that my INPUT chain (the one Ill be working with, since I want to disallow INPUTs to my server) is empty: [root@andrea xinetd.d]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Your mileage may vary, because your distribution may already have set up some basic iptables rules; to make these instructions foolproof, I will be inserting rules at the beginning of the INPUT chain. In this case, I want to allow access to 127.0.0.1:3306, and deny access to everyone else on port 3306, in that order. So two rules are needed. Ill add the allow rule into position 1 (the very first): [root@andrea xinetd.d]# iptables -I INPUT 1 --protocol tcp --destination-port 3306 -s 127.0.0.1 -j ACCEPT [root@andrea xinetd.d]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- localhost.localdomain anywhere tcp dpt:mysql Great. Im telling the firewall to -j ACCEPT all --protocol tcp connections to --destination-port 3306 from the address -s 127.0.0.1. Now, Ill insert the deny rule into position 2: [root@andrea xinetd.d]# iptables -I INPUT 2 --protocol tcp --destination-port 3306 -j REJECT [root@andrea xinetd.d]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- localhost.localdomain anywhere tcp dpt:mysql REJECT tcp -- anywhere anywhere tcp dpt:mysql reject-with icmp-port-unreachable See how easy it is? Let me explain: rule 2 tells the firewall to -j REJECT all --protocol tcp connections to --destination-port 3306 from any address (since I omitted the address). Since rules are processed top-down (from 1 to n), the first one that matches an incoming connection is applied. If no rules match, then the default policy (which is normally ACCEPT) kicks in. Lather. Rinse. Repeat for every service that you want to secure. Finally, save the rules. For this, youll need to use your distributions tools. For Fedora Core, thats as easy as issuing the command service iptables save and ensuring that the iptables service runs at boot time: chkconfig --add iptables. Its worth noting that some people prefer to -j DROP instead of DENYing. DROP means that your server will ignore connection attempts (neither denying connections nor accepting them). I prefer DENY, because its easier to pinpoint a problem with iptables rules that way, and (most importantly) DROP rules make those ports appear as filtered to a hostile port scanner (which hints to the attacker that a service is running). So thats it, from insecure to secure in 10 minutes! If you have any suggestions or questions, please leave them as comments below. Happy hacking! If you found this useful, please leave a donation for the author. This entry was posted on Monday, February 27th, 2006 at 18:55 and is filed under Publicaciones, Software libre, Linux. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. You can also share and bookmark this article on the following services: . Except where expressly acknowledged, this work is distributed and licensed to you under the terms of this license. For other licenses, contact Rudd-O. No Responses to Hardening a Linux server in 10 minutes You can subscribe to the RSS feed for comments on this post. You can also reply to this post directly in your weblog, and take advantage of the TrackBack URI to record your reply in this post. Leave a comment Line and paragraph breaks automatic, e-mail address never displayed,
references : total 140 -rwxr-xr-x 1 root root 6414 Jul 16 01:04 fastwall -rwxr-xr-x 1 root root 1006 Jul 15 16:57 fastwall-off.sh -rwxr-xr-x 1 root root 2674 Jul 15 17:00 fastwall-on.sh -rw-r--r-- 1 root root 475 Jul 16 01:04 MD5SUM