Candidates should be able to receive security alerts from various sources, install, configure and run intrusion detection systems and apply security patches and bugfixes.
Tools and utilities to scan and test ports on a server
Locations and organisations that report security alerts as Bugtraq, CERT, CIAC or other sources
Tools and utilities to implement an intrusion detection system (IDS)
Awareness of OpenVAS
Snort is a network intrusion detection system capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts and much more. Snort uses a flexible rules language to describe traffic that it should collect or pass, as well as a detection engine that utilizes a modular plugin architecture. Snort has a real-time alerting capability as well, incorporating alerting mechanisms for syslog, a user-specified file, a UNIX socket or WinPopup messages to Windows clients using Samba's smbclient.
Snort has three primary uses. It can be used as a straight packet-sniffer like tcpdump, a packet-logger (useful for network traffic debugging, etc), or as a full blown network-intrusion detection system.
Snort logs packets in either tcpdump binary format or in Snort's decoded ASCII format to logging directories that are named based on the IP address of the foreign host.
Available modes are:
basic port-bound TCP mode: PortSentry will check the config files and then bind to all TCP ports in the background. To check the init status, just look in the local syslog file to which messages are sent.
basic port-bound UDP mode: PortSentry will check the config files and then bind to all UDP ports in the background. If you want to check the init status you, just look in the local syslog to which messages are sent. UDP/Stealth scan warnings apply (read: README.stealth).
Stealth TCP scan detection: PortSentry will use a raw socket to monitor all incoming packets. If an incoming packet is destined for a monitored port it will react to block the host. This method will detect connect() scans, SYN/half-open scans and FIN scans. UDP/Stealth scan warnings apply (read: README.stealth).
Advanced TCP stealth scan detection: PortSentry will start by making a list of all the ports listening in the port area under the ADVANCED_PORTS_TCP option and will then create an exclusion list based on these ports. Any host connecting to *any port* in this range that is *not excluded* (i.e., not a listening network daemon [SMTP, HTTP, etc.]) is blocked. This has some very powerful implications that you should be aware of: (1) This mode is the most sensitive and the most effective of all the protection options. It reacts to port probes with lightning speed because you don't have to wait for them to hit a tripwired port. (2) Because it reacts so abruptly, you may cut off legitimate traffic. An FTP site may send an ident request to you. If you are monitoring the ident port (113 TCP) then you have just cut off the FTP site you were going to! As a result you should put in this list all ports that fall into this situation.
Advanced Logic Mode: PortSentry is intelligent about how it monitors ports. For some protocols such as FTP, the client actually opens up ports in the ephemeral range (1024-65535) and the server then connects *back* to you. This would normally cause the port scanner to activate. However, PortSentry will look at the incoming connection and determine if it is destined for one of these “temporary” bindings. If it is, then the connection is ignored for that one time. As soon as the connection is torn down the window closes and full protection is back again. This is, in fact, a rudimentary stateful inspection engine. UDP/Stealth scan warnings apply (read: README.stealth).
“Stealth” UDP scan detection: This operates in a manner similar to the TCP stealth mode above. UDP ports need to be listed and are then monitored. This does not bind any sockets, and while not really “stealth” scan detection (doesn't usually apply to UDP), it operates in a similar manner (reacts to *any* UDP packet). UDP/Stealth scan warnings apply (read: README.stealth).
Advanced “Stealth” UDP scan detection: This is the same as above except for the UDP protocol. This is a very advanced option and may cause false alarms. This is because PortSentry makes no distinction between broadcast and direct traffic. If you have a router on your local network putting out RIP broadcasts then there is a good chance you will block them. Use this option with extreme caution. You need to be sure to put exclusions into the ADVANCED_EXCLUDE_UDP line (e.g., 520 [RIP]) UDP/Stealth scan warnings apply (read: README.stealth).
Netcat (nc) is a very versatile network tool. Netcat is a computer networking service for reading from and writing to network connections using TCP or UDP. Netcat is designed to be a dependable "back-end" device that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and investigation tool. Netcat's features are numerous; Netcat can, for instance, be used as a proxy or portforwarder. It can use any local source port, or use loose source-routing. It is commonly referred to as the TCP/IP Swiss army knife.
Some of the major features of netcat are:
Outbound or inbound connections, TCP or UDP, to or from any ports
Full DNS forward/reverse checking, with appropriate warnings
Ability to use any local source port
Ability to use any locally-configured network source address
Built-in port-scanning capabilities, with randomizer
Built-in loose source-routing capability
Can read command line arguments from standard input
Slow-send mode, one line every N seconds
Hex dump of transmitted and received data
Optional ability to let another program service establish connections
Optional telnet-options responder
Because netcat does not make any assumptions about the protocol used across the link, it is better suited to debug connections than telnet.
With the -z option netcat will perform a portscan on the ports given on the command line. By default netcat will produce no output. When scanning only one port the exit status indicates the result of the scan, but with multiple ports the exit status will allways be "0" if one of the ports is listening. For this reason using the "verbose" option will be usefull to see the actual results:
# nc -vz localhost 75-85 nc: connect to localhost port 75 (tcp) failed: Connection refused nc: connect to localhost port 76 (tcp) failed: Connection refused nc: connect to localhost port 77 (tcp) failed: Connection refused nc: connect to localhost port 78 (tcp) failed: Connection refused Connection to localhost 79 port [tcp/finger] succeeded! Connection to localhost 80 port [tcp/http] succeeded! nc: connect to localhost port 81 (tcp) failed: Connection refused nc: connect to localhost port 82 (tcp) failed: Connection refused nc: connect to localhost port 83 (tcp) failed: Connection refused nc: connect to localhost port 84 (tcp) failed: Connection refused nc: connect to localhost port 85 (tcp) failed: Connection refused
The man page of netcat shows some more examples on how to use netcat.
Fail2ban scans log files like
/var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.
Fail2ban's main function is to block selected IP addresses that may belong to hosts that are trying to breach the system's security. It determines the hosts to be blocked by monitoring log files (e.g.
/var/log/auth.log, etc.) and bans any host IP that makes too many login attempts or performs any other unwanted action within a time frame defined by the administrator. Fail2ban is typically set up to unban a blocked host within a certain period, so as to not "lock out" any genuine connections that may have been temporarily misconfigured. However, an unban time of several minutes is usually enough to stop a network connection being flooded by malicious connections, as well as reducing the likelihood of a successful dictionary attack.
nmap supports a large number of scanning techniques such as: UDP, TCP connect(), TCP SYN (half open), ftp proxy (bounce attack), Reverse-ident, ICMP (ping sweep), FIN, ACK sweep, Xmas Tree, SYN sweep, IP Protocol and Null scan.
Assuming we have got a host fictitious.test and we want to see what tcp ports this host is listening to, this is done as follows:
# nmap -sT fictitious.test Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 Nmap run completed -- 1 IP address (0 hosts up) scanned in 30 seconds
# nmap -sT -P0 fictitious.test Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on fictitious.test (ip address): (The 1545 ports scanned but not shown below are in state: filtered) Port State Service 22/tcp open ssh 137/tcp closed netbios-ns 138/tcp closed netbios-dgm 139/tcp closed netbios-ssn Nmap run completed -- 1 IP address (1 host up) scanned in 304 seconds
After this command, the ports are only tested for accessibility by means of the TCP protocol. Let's try the same command on the Microsoft web-site:
# nmap -sT www.microsoft.com Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on microsoft.com (184.108.40.206): (The 1544 ports scanned but not shown below are in state: filtered) Port State Service 80/tcp open http 137/tcp closed netbios-ns 138/tcp closed netbios-dgm 139/tcp closed netbios-ssn 443/tcp open https Nmap run completed -- 1 IP address (1 host up) scanned in 383 seconds
Note the difference: the machine fictitious.test is not running a webserver and Microsoft is (ports 80 and 443).
The core of this SSL-secured service-oriented architecture is the OpenVAS Scanner. The scanner very efficiently executes the actual Network Vulnerability Tests (NVTs) which are served with daily updates via the OpenVAS NVT Feed or via a commercial feed service.
Detailed information about OpenVAS can be found at: Openvas - Open vulnerability assessment system community site.
Security alerts are warnings about vulnerabilities in certain pieces of software. Those vulnerabilities can result in a decrease of your service level because certain individuals are very good at misusing those vulnerabilities. This can result in your system being hacked or blown out of the water.
Most of the time there is already a solution for the problem or someone is already working on one, as will be described in the rest of this section.
BugTraq is a full disclosure moderated mailing-list at securityfocus.com for detailed discussion and announcement of computer security vulnerabilities: what they are, how to exploit them and how to fix them.
SecurityFocus there is a link to mailing lists, one of which is Bugtraq. There also is a Bugtraq FAQ.
The CERT Coordination Center (CERT/CC) is a center of Internet security expertise, at the Software Engineering Institute, a federally funded research and development center operated by Carnegie Mellon University. They study Internet security vulnerabilities, handle computer security incidents, publish security alerts, research long-term changes in networked systems and develop information and training to help you improve security at your site.
CERT maintains a website called The CERT Coordination Center.
See the us-cert.gov signup page to sign up for the CERT Advisory mailing list or the RSS feeds issued on diverse NCAS publications.
CIAC is the U.S. Department of Energy's Computer Incident Advisory Capability. Established in 1989, shortly after the Internet Worm, CIAC provides various computer security services free of charge to employees and contractors of the DOE, such as: Incident Handling consulting, Computer Security Information, On-site Workshops, White-hat Audits.
There is a CIAC Website.
The mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of the mailing lists, send requests of the following form: subscribe list-name LastName, FirstName, PhoneNumber as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for “list-name” and valid information for “LastName” “FirstName” and “PhoneNumber.” Send to: firstname.lastname@example.org.
You will receive an acknowledgment containing address and initial PIN, and information on how to change either of them, cancel your subscription or get help.
An open mail relay is a mail server that accepts SMTP connections from anywhere and will forward emails to any domain. This means that everyone can connect to port 25 on that mail server and send mail to whomever they want. A s a result your server's IP might end up on anti-spam blacklists.
Testing a mail relay can be done by delivering an email for a recipient to a server that's not supposed to any relaying for the recipients domain. If the server accepts AND delivers the email it is an open relay.
charon:~# telnet mail.home.nl 25 Trying 220.127.116.11... Connected to mail.home.nl. Escape character is '^]'. 220 mail2.home.nl ESMTP server (InterMail vM.4.01.03.00 201-229-121) ready Fri, 11 Jan 2002 17:19:14 +0100 HELO 250 mail2.home.nl MAIL FROM: email@example.com 250 Sender <firstname.lastname@example.org> Ok RCPT TO: email@example.com 250 Recipient <firstname.lastname@example.org> Ok DATA 354 Ok Send data ending with <CRLF>.<CRLF> FROM: email@example.com TO: firstname.lastname@example.org Hahaha, open mail relay test . 250 Message received: 20020111162325.GOJI8897.email@example.com QUIT 221 mail2.home.nl ESMTP server closing connection Connection closed by foreign host.
This worked because this is my ISP and I _do_ belong to the right domain. I tried it from a wrong domain, and I got no response whatsoever. You could use IPCHAINS, IPTABLES or some other sort of firewall software to tell your firewall to only forward the SMTP protocol packets to your mail server if they are coming from a certain range of IP addresses (for instance, the dynamic ones you have reserved for your PPP users). Also, most mail servers allow configuration settings to avoid acting as an open relay. Nowadays, this is the default behaviour for most mail server implementations.