Juniper Tips 40: How to configure flow collector on MX480

1. configure forwarding-options sampling

 

# run show configuration forwarding-options sampling
input {
    rate 1024;
}
family inet {
    output {
        flow-server 192.x.x.113 {
            port 2055;
        }
        flow-server 192.x.x.117 {
            port 2055;
        }
    }
}

 

2. Configure service flow-monitoring

0# run show configuration services flow-monitoring
version9 {
    template TemplateV9 {
        flow-active-timeout 60;
        flow-inactive-timeout 60;
        ipv4-template;
    }
}

 

3. Verify from the flow colllector

#tcpdump -i  eth0 -n  udp port 2055

#nftool -b -vvv

 

Application Security: HTTP Chunked response body was incomplete

Chunked transfer encoding is a data transfer mechanism in version 1.1 of the Hypertext Transfer Protocol (HTTP) in which data is sent in a series of “chunks”. It uses the Transfer-Encoding HTTP header in place of the Content-Length header, which the earlier version of the protocol would otherwise require. Because the Content-Length header is not used, the sender does not need to know the length of the content before it starts transmitting a response to the receiver. Senders can begin transmitting dynamically-generated content before knowing the total size of that content.

The size of each chunk is sent right before the chunk itself so that the receiver can tell when it has finished receiving data for that chunk. The data transfer is terminated by a final chunk of length zero.

If a Transfer-Encoding field with a value of “chunked” is specified in an HTTP message (either a request sent by a client or the response from the server), the body of the message consists of an unspecified number of chunks, a terminating chunk, trailer, and a final CRLF sequence (i.e. carriage return followed by line feed).

In the following example, every second line is the start of a new chunk, with the chunk size as a hexadecimal number followed by \r\n as a line separator.

In the following example, every second line is the start of a new chunk, with the chunk size as a hexadecimal number followed by \r\n as a line separator.

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
 in\r\n\r\nchunks.\r\n
0\r\n
\r\n

 

Attack types:

Extremely Big Chunk Size

Transfer-Encoding: Chunked response did not terminate with proper zero-size drunk.

 

Application Security: HTTP persistent connection (Keep-alive)

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, added to an existing protocol. If the client supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is not dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

HTTP 1.1

In HTTP 1.1, all connections are considered persistent unless declared otherwise. The HTTP persistent connections do not use separate keepalive messages, they just allow multiple requests to use a single connection. However, the default connection timeout of Apache httpd 1.3 and 2.0 is as little as 15 seconds and just 5 seconds for Apache httpd 2.2 and above. The advantage of a short timeout is the ability to deliver multiple components of a web page quickly while not consuming resources to run multiple server processes or threads for too long.

Disadvantages

If the client does not close the connection when all of the data it needs has been received, the resources needed to keep the connection open on the server will be unavailable for other clients. How much this affects the server’s availability and how long the resources are unavailable depend on the server’s architecture and configuration. attacks like Slowloris etc, take advantage of this feature.

DELL Serial Console Access 2

1.  Modify the DELL PowerEdge Sever R320 BIOS setting

Under BIOS->Settings-> Serial Communication

To choose the following configuration, as shown in the picture, save and exit.

  1. Choose Serial Communication <On with Console Redirection via COM1>
  2. Serial Port Address <Serial Device1=Com2, Serial Device2=Com1>
  3. External Serial Connector <Serial Device 2>
  4. Failsafe Baud Rate <115200>
  5. Remote Terminal Type <ANSI>
  6. Redirection After Boot <Enable>

Note: Output to <Serial Device 2>, means using IDRAC (serial over LAN) to see the output, if choose <Serial Device 1>, it will still output to com1 (/dev/ttyS0) but iDRAC can not see as it becomes to (/dev/ttyS1). the good things is that you have two serial port to use.

2. On IDARC, Under IDRAC admin page,

a. iDRAC Settings->Network->Serial, make sure RAC Serial is enabled (which disabled IMPI at the same time) and Baud Rate is 115200, Timeout 300s and Buffersize 8192 by default.

b. iDRAC Settings->Network->Serial over LAN, enable Serial Over LAN has been selected, Baudrate 115.2Kbps, Priviledge level on administrator, Redirect Enabled been selected and Escape Key (^])

cfgSerialBaudRate=115200 cfgSerialConsoleEnable=1 cfgSerialTelnetEnable=1 cfgSerialSshEnable=1

 

3. Modify the /etc/grub.conf in order to see the output during the Redhat Linux upstart process,

#          initrd /initrd-[generic-]version.img
default=0
timeout=5
#splashimage=(hd0,0)/grub/splash.xpm.gz
serial –unit=1 –speed=57600 –word=8 –parity=no –stop=1
terminal –timeout=5 serail console
:hiddenmenu
title Red Hat Enterprise Linux (2.6.32-431.el6.x86_64) ttyS0
        root (hd0,0)
        kernel /vmlinuz-2.6.32-431.el6.x86_64 ro root=/dev/mapper/vg_proxyserverr
-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_proxyserver/lv_root rd_NO_MD rr
d_LVM_LV=vg_proxyserver/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBB
OARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb console=tty0 console=ttyS0,57600 quiet
initrd /initramfs-2.6.32-431.el6.x86_64.img
title Red Hat Enterprise Linux (2.6.32-431.el6.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.32-431.el6.x86_64 ro root=/dev/mapper/vg_proxyserverr
-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_proxyserver/lv_root rd_NO_MD rr
d_LVM_LV=vg_proxyserver/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBB
OARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

by adding that, you will be able to see the output from red hat linux startup,

before:

Disconnecting UEFI drivers. Please wait…

Scanning for devices.  Please wait, this may take several minutes…
ÿ
Red Hat Enterprise Linux Server release 6.5 (Santiago)
Kernel 2.6.32-431.el6.x86_64 on an x86_64

proxyserver login:

After:

Disconnecting UEFI drivers. Please wait…
ÿmegasas: INIT adapter done
                Welcome to Red Hat Enterprise Linux Server
Starting udev: [  OK  ]
Setting hostname proxyserver:  [  OK  ]
Setting up Logical Volume Management:   3 logical volume(s) in volume group “vg_proxyserver” now active
[  OK  ]
Checking filesystems
Checking all file systems…..

3. Need /etc/init/serial.override to work. otherwise you will see login prompt on /dev/ttyS0, but just can not login. even it’s like an empty file.

[root@server ~]# vi /etc/init/serial.override
start on runlevel [2345]
stop on runlevel [S016]
#instance ttyS0
#respawn
#pre-start exec /sbin/securetty ttyS0
#exec /sbin/agetty 57600 /dev/ttyS0 vt100
#instance ttyS1
#respawn
#pre-start exec /sbin/securetty ttyS1
#exec /sbin/agetty 57600 /dev/ttyS1 vt100

Before:

ttyS1 (/dev/ttyS1) start/running, process 997
readahead-disable-services stop/waiting
ttyS0 (/dev/ttyS0) start/running, process 1001
rcS-sulogin stop/waiting
serial (ttyS1) start/running, process 1007 <-it’s from the /etc/init/serial.override

# ps -ef | grep tty
root       997     1  0 11:49 ttyS1    00:00:00 /sbin/agetty /dev/ttyS1 57600 vt100 <-/etc/init/ttyS1.conf, it never been used.

root       997     1  0 11:49 ttyS1    00:00:00 /sbin/agetty /dev/ttyS0 57600 vt100 <-/etc/init/ttyS0.conf, once login via ttyS0, this line will disappear.

root      1007     1  0 11:49 ?        00:00:00 /sbin/agetty 57600 /dev/ttyS1 vt100 <-/etc/serial.override
root      1718     1  0 11:49 tty1     00:00:00 /sbin/mingetty /dev/tty1
root      1720     1  0 11:49 tty2     00:00:00 /sbin/mingetty /dev/tty2
root      1722     1  0 11:49 tty3     00:00:00 /sbin/mingetty /dev/tty3
root      1724     1  0 11:49 tty4     00:00:00 /sbin/mingetty /dev/tty4
root      1726     1  0 11:49 tty5     00:00:00 /sbin/mingetty /dev/tty5
root      1728     1  0 11:49 tty6     00:00:00 /sbin/mingetty /dev/tty6

 

3. Using /etc/init/ttyS0.conf as recommended from /etc/init/serinal.conf, 

more /etc/init/ttyS0.conf
start on runlevel [2345]
stop on runlevel [S016]
respawn
instance /dev/ttyS0
exec /sbin/agetty -h -L -w /dev/ttyS0 57600 vt100

4. The Maching speed is very important.

Over the cisco serial connection, otherwise it has trobe to display properly.

line 0/1/15
 privilege level 15
 terminal-type all
 no exec
 transport input telnet ssh
 autohangup
 stopbits 1
 speed 57600
 flowcontrol hardware

5. Access from idrc’s telnet/ssh console access,

  1. By typing “console com2” and press enter, it will show you the login prompt.
  2. To break out, press “Ctrl+]”.

6. The access from Idrac will take preceeding from the Serial port access. only one will display.