Marzo 25

Squid content filtering: Block / download of music MP3, mpg, mpeg, exec files

Q. For security and to save bandwidth I would like to configure Squid proxy server such way that I do not want my users to download all of the following files:
MP3
MPEG
MPG
AVG
AVI
EXE

How do I configure squid content filtering?

A. You can use squid ACL (access control list) to block all these files easily.

How do I block music files using squid content filtering ACL?

First open squid.conf file /etc/squid/squid.conf:

# vi /etc/squid/squid.conf
Now add following lines to your squid ACL section:

acl blockfiles urlpath_regex "/etc/squid/blocks.files.acl"
You want display custom error message when a file is blocked:
# Deny all blocked extension
deny_info ERR_BLOCKED_FILES blockfiles
http_access deny blockfiles

Save and close the file.

Create custom error message HTML file called ERR_BLOCKED_FILES in /etc/squid/error/ directory or /usr/share/squid/errors/English directory.
# vi ERR_BLOCKED_FILES
Append following content:

<tt>&lt;HTML&gt;
&lt;HEAD&gt;
&lt;TITLE&gt;ERROR: Blocked file content&lt;/TITLE&gt;
&lt;/HEAD&gt;
&lt;BODY&gt;
&lt;H1&gt;File is blocked due to new IT policy&lt;/H1&gt;
&lt;p&gt;Please contact helpdesk for more information:&lt;/p&gt;
Phone: 555-12435 (ext 44)&lt;br&gt;
Email: helpdesk@yourcorp.com&lt;br&gt;
</tt>

Caution: Do not include HTML close tags </HTML> </BODY> as it will be closed by squid.
Now create /etc/squid/blocks.files.acl file:
# vi /etc/squid/blocks.files.acl
Append following text:
\.[Ee][Xx][Ee]$
\.[Aa][Vv][Ii]$
\.[Mm][Pp][Gg]$
\.[Mm][Pp][Ee][Gg]$
\.[Mm][Pp]3$

Save and close the file. Restart Squid:
# /etc/init.d/squid restart

Squid in action:

Squid content filtering howto

Category: NETWORKING, PROXY | Los comentarios están deshabilitados en Squid content filtering: Block / download of music MP3, mpg, mpeg, exec files
Marzo 25

How to kill a tty connection

1. Check who is connected to the tty

#who
srv-srv1:~/test# w
08:50:26 up 152 days, 15:53,  2 users,  load average: 0.00, 0.02, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    wks1 08:27    0.00s  0.04s  0.00s w
root     pts/2    wks1 Mon09   15:41m  0.17s  0.17s -bash

2. Verify its PID
ps -u root |grep -i pts/2

3. kill the connection
# kill -9 <PID>

Category: DEBIAN | Los comentarios están deshabilitados en How to kill a tty connection
Marzo 16

Securing RouterOs Router (MKTK)

We’ve set up an x86 Mikrotik router in a virtual lab, with one interface for WAN (ether1, 192.168.88.214), another for the Management LAN (ether2, 10.1.157.1/24), and a third for normal LAN clients (ether3, 192.168.0.1/24). The first step we’ll take is disabling any physical network interfaces that aren’t in use, denying an intruder access to the device if they somehow got into the wiring closet or server room. To plug into the router they’d have to disconnect a live connection and draw attention.

First list all the interfaces, making note of the numbers associated with each interface:

/interface print

Then shut off all the interfaces that aren’t live so they can’t be used to access the device. In our case interfaces 0, 1, and 2 are in use, and we’re not using interfaces 3 and 4:

/interface set 3,4 disabled=yes

Next we’ll do an “intense”-level NMAP scan of the stock router from the WAN side to get a baseline of open ports and services. This will our starting point, shown below:

While we’re at it we’ll also do a very cursory network scan using Nessus, which is a fantastic tool for scanning and auditing networks, and will enumerate vulnerabilities on pretty much all routing platforms including Mikrotik. Here’s what Nessus finds for vulnerabilities:

Nessus scan of Mikrotik before securing the device

Both Nmap and Nessus have found a number of issues, and it’s very clear we have some work to do. The router is running multiple unencrypted protocols, and services that aren’t necessary at all. The FTP service also gives an attacker doing reconnaissance the exact version of RouterOS that’s running. We also see the result of using the factory default credentials. If this router was connected to the Internet just like it is right now, it would almost certainly be exploited shortly after coming online.

Like in most production networks, we assume the router will only be administered through SSH and Secure-mode Winbox. Both SSH and Winbox sessions are encrypted, so we don’t have to worry about plaintext information leaking. First, let’s shut off all services except SSH and Winbox, then scan again. The following commands turn off Telnet, FTP, HTTP, and SOCKS services, and the bandwidth test server that is enabled by default, as well as disabling remote DNS requests relayed through the router:

/ip service disable 0,1,2,4,5,7
/tool bandwidth-server set enabled=no
/ip dns set allow-remote-requests=no
/ip socks set enabled=no

Stronger crypto for SSH is available as of RouterOS 6.30, so we’ll enable that. SSH clients like Putty that can utilize the stronger crypto will default to that, and leave the weaker algorithms unused. As of RouterOS v6.32 there is still no way to disable the weaker crypto algorithms in the Mikrotik for purposes of SSH. Turn on the SSH strong crypt:

/ip ssh set strong-crypto=yes

We’ll also shut off the MAC Telnet and MAC Winbox servers. These are used to give administrators access to a router without an IP address assigned, but by default are turned on and running on ALL interfaces – even WAN interfaces. A user inside your LAN could connect to the device via one of the MAC services, and that access needs to be restricted both from internal and external networks. We’ll disable these services entirely, and it’s suggested re-enabling them only on dedicated management interfaces.

tool mac-server set [find] disabled=yes
tool mac-server mac-winbox set [find] disabled=yes
tool mac-server ping set enabled=no

Verify that the basic services have been disabled (shown with an “X” by the service name) by running the following:

/ip service print
/tool mac-server print
/tool mac-server mac-winbox print
/tool mac-server ping print 

We’ll also disable the new RoMON feature, assuming that you aren’t using it. If you’re using RoMON for device management then leave it on, but if you aren’t using it then disable the service to reduce the attack surface:

/tool romon set enabled=no

Now scan again…

Things are looking better, but an attacker could still attempt to login with the default Mikrotik admin credentials across the Internet using SSH or Winbox and would succeed. Let’s disable access (input) from the WAN side by adding some basic firewall rules, then scan again. First though we’re going to create a firewall address list for blocking Bogons.

Bogons are network addresses that have no business being routed over the Internet, and normally they aren’t unless someone is trying to spoof traffic and make it appear as though it came from your own network. Team Cymru maintains a really fantastic list of Bogons that you should be blocking.

Here’s an abbreviated address list:

/ip firewall address-list
add address=192.168.0.0/16 list=Bogon
add address=10.0.0.0/8 list=Bogon
add address=172.16.0.0/12 list=Bogon
add address=127.0.0.0/8 list=Bogon
add address=0.0.0.0/8 list=Bogon
add address=169.254.0.0/16 list=Bogon

Now, the firewall rules:

/ip firewall filter
add chain=input comment="Accept Established / Related Input" \
    connection-state=established,related
add chain=input comment="Allow Management Input" src-address=10.1.157.0/24
add action=drop chain=input comment="Drop Input" log=yes log-prefix=\
    "Input Drop"
add action=fasttrack-connection chain=forward comment=\
    "Fast Track Established / Related Forward" connection-state=\
    established,related
add chain=forward comment="Accept Established / Related Forward" \
    connection-state=established,related
add chain=forward comment="Allow client LAN traffic out WAN" out-interface=\
    ether1-gateway src-address=192.168.0.0/24
add action=drop chain=forward comment="Drop Bogon Forward -> Ether1" \
    in-interface=ether1-gateway log=yes log-prefix="Bogon Forward Drop" \
    src-address-list=Bogon
add action=drop chain=forward comment="Drop All Forward"

You probably noticed logging is turned on for a couple rules: Drop Input and the Drop Bogon Forward. If someone is trying to get in repeatedly we want the source logged so investigation and remediation can happen.

Input is allowed to the router from the management subnet, and everything else should be dropped on the Input chain. The only people who should be trying to access the router directly, instead of just forwarding traffic across it, should be the network admins whose workstations are on the management subnet. If this router was taking part in GRE, EoIP, or IPSEC tunnels then additional input rules would need to be added to allow those tunnels to be established, but that’s covered in other articles.

Now on scanning again from the WAN side:

This is a much better result than what we started with, and all we had to do was run basic commands. NMAP is aware that something is there, but it’s unable to identify any running services or ports to fingerprint.

Now that we’re (relatively) secure from the outside let’s secure a couple things inside the router. First, let’s set a password on the default admin user, then change the admin username to something other than the factory default “admin”. Just like most people rename the Administrator user on Windows servers, it’s a good idea to rename the Mikrotik admin user to something other than a known default:

/user set 0 password=mygreatpassword
/user set 0 name=tikadmin

All router administrators should have their own logins for the purpose of non-repudation, and only use those logins to administer the device. The user we just renamed should only be used for backup purposes if other credentials somehow were lost or forgotten. This also allows another administrator to quickly disable an individual administrator’s access if they leave.

Another best practice is to disable neighbor discovery, which will stop the router from being discovered by other devices running Mikrotik’s Neighbor Discovery Protocol (MNDP) or Cisco’s Discovery Protocol (CDP), or programs capable of snooping on discovery traffic. First we’ll turn it off by default for IPv4, so when new interfaces come online they won’t participate, and we’ll disabled it for IPv6:

 /ip neighbor discovery settings set default=no default-for-dynamic=no
/ipv6 nd set [find] disabled=yes

Then we’ll shut it off on each individual IPv4 interface that’s already running, because out of the box it’s enabled on interfaces by default (even the WAN):

/ip neighbor discovery set [find] discover=no

All other ports are turned off, so no discovery is going to happen there. Once that’s done if you have an interface on a management subnet / VLAN it wouldn’t hurt to allow discovery protocols to run just on that interface.

We’ll also turn on Reverse Path Filtering (RPF). This feature drops packet traffic that appears to be spoofed, i.e. a packet coming from an internal LAN subnet heading outbound but with a different source IP address than your LAN’s. This is very common when a workstation has been infected with a virus and is now participating in a DDoS attack. We’ll turn on RPF in the IP > Settings menu:

/ip settings set rp-filter=strict

It has been noted the the Reverse Path Filter feature can cause issues if a router is multi-homed. Unfortunately Mikrotik’s implementation of this feature doesn’t allow Reverse Path Filtering to be enabled on specific interfaces, only for the entire device, so watch out for that if your device is multi-homed. Assuming you can implement RPF please do so – it’s considered part of being a good Internet citizen. This kind of filtering is also documented as Best Common Practice (BCP) #38, as well as RFC #2827.

We should also set a login banner, which is displayed when someone logs into the router, and is required by a number of compliance standards, Depending on the country and jurisdiction this banner statement may or may not be legally relevant, but it certainly doesn’t hurt to have a banner displayed on login. First, set the banner to be displayed at login:

/system note set show-at-login=yes

Then set the contents of the banner message. This should be something that clearly states that access to the router is for authorized administrators only, and that access is monitored.

/system note set note="Authorized administrators only. Access to this device is monitored."

Now when an administrator (or anyone else) logs into the router remotely via SSH or Telnet this banner will appear. It will also appear if a terminal is opened in Winbox.

Last but certainly not least, we’ll create a backup copy of the new config that can be downloaded from the router and stored with other backups in case the router fails and needs to be replaced:

export compact file=backup_config_router01

Long-term device security and risk management means not only putting these settings in place, but also monitoring your devices and auditing the settings that are in place regularly.

Category: MIKROTIK | Los comentarios están deshabilitados en Securing RouterOs Router (MKTK)